Filter keywords from zlup identifier proptests and fix the unreachable orelse keyword alternative - #537
Merged
Merged
Conversation
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
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.
Closes #419.
The reported bug
valid_identifiers_acceptedgenerated raw[a-zA-Z_][a-zA-Z0-9_]*strings, so proptest eventually produces a keyword (minimal inputfn), which the parser correctly refuses — the property asserted something false.parser_valid_functionhad the same latent defect in its function-name strategy (a generated name likeifortruemakes the source unparseable); the three remaining identifier-generating properties are guarded byif let Okand merely skip keyword inputs, so they are left as-is.Fix
The grammar is now the single source of truth for what counts as a keyword:
zlup::parser::is_keywordmatches a candidate against the grammar's ownkeywordrule (exact-length match), and both asserting propertiesprop_assume!keywords away through it. No keyword list is duplicated into the tests.A real grammar bug this surfaced
Pinning
is_keyworddeterministically exposed that thekeywordrule could never matchorelse: pest's ordered choice matched the"or"alternative first, the trailing!(ASCII_ALPHANUMERIC | "_")lookahead then failed one, and PEG parsing does not backtrack into a matched alternative. Becauseidentifieris defined as!keyword ~ ..., the parser acceptedorelse := 42;as an ordinary identifier assignment. The rule now lists"orelse"before"or". An audit of the full keyword list found no other prefix-shadowed pair (errdefer/error,union/unit, andtry/trueall diverge before either token ends). No example or test program usedorelseas an identifier, and all fiveorelse-operator tests still pass.keywords_are_rejected_as_identifierspins the behavior in both directions: representative keywords (includingorelse) are recognized and refused as identifiers, while near-keywords such asfnord,iffy, andreturnedremain valid.Verification
Full
cargo test -p zlup(666 unit + 175 proptest + CLI suites) green;cargo fmt --check, coldcargo clippy --locked -p zlup --all-targets -- -D warnings, andpre-commit run --all-filesclean. The new pin test demonstrably fails against the unfixed grammar (that is how theorelsedefect was found) and passes after the reorder.