test: [expected failures] parameter-type fixtures needing implementation fixes - #166
Draft
leongdl wants to merge 1 commit into
Draft
Conversation
Five parked fixtures across two proposed/ dirs: LIST[INT] and LIST[LIST[INT]] element 2^63 acceptance (both implementations - the known int64 bug one container deeper), the openjd-rs 2^62 endpoint cap on RANGE_EXPR defaults, task-parameter type case-insensitivity unimplemented in both, and the base lowercase type-name acceptance in openjd-rs (Python correctly rejects). Per-fixture details in each proposed/README.md. Companion to conformance-param-types-gaps. Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Important
Expected-failure fixtures — do not expect these to pass. Spec-correct fixtures that FAIL against at least one current implementation, parked across two
proposed/directories (EXPR and base) that the runner does not discover, so merging keeps the suite green. Per-fixture output, spec citation, and classification in eachproposed/README.md. Promote each fixture unchanged when its fix lands.Contents (5 fixtures, dual-implementation verified)
2.13--list-int-item-int64-overflow.invalidand2.16--list-list-int-inner-item-int64-overflow.invalid— aLIST[INT]element /LIST[LIST[INT]]inner element of 2^63 accepted atcheckby BOTH implementations. The known int64 acceptance bug, one container deeper: both validate int64 bounds for expression literals but not for values arriving as YAML data in list defaults.2.10--range-expr-endpoint-int64-max— openjd-rs FALSELY REJECTS a RANGE_EXPR default with endpoints near int64 max; probing shows an undocumented 2^62 endpoint cap. Python accepts. The spec grammar admits any int64 endpoint. Rust-side bug. (Side effect: the live companion negative at 2^63 currently rejects for the wrong reason.)3.4.1--task-param-type-case-insensitive— schema §2 says job AND task parameter type names become case-insensitive with EXPR; BOTH implementations reject mixed-case task parameter types ("unknown variantint") while accepting them for job parameters. Both-implementation gap.base/.../2--type-lowercase-string.invalid—type: stringin base (no extensions) must be rejected; openjd-rs accepts (unconditional case-insensitivity), Python correctly rejects. Rust-side bug; base is case-sensitive by spec.Companion to the green-fixture PR from branch
conformance-param-types-gaps.