fix(syntax): include TokenMissing in generated is_missing() generate_kinds_code built the missing-kinds set only from enum missing_variant nodes, so SyntaxKind::TokenMissing was excluded and is_missing() returned false for it. The inline-macro expan - #10020
Conversation
generate_kinds_code built the missing-kinds set only from enum `missing_variant` nodes, so SyntaxKind::TokenMissing was excluded and is_missing() returned false for it. The inline-macro expansion guards that skip expansion when the call has a parse error (via is_missing()) therefore missed errors manifesting solely as a missing token, and tried to expand broken input. Emit the Token "Missing" node alongside the enum *Missing variants and regenerate kind.rs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This change is |
PR SummaryLow Risk Overview With that fix, inline macro expansion can detect parse-recovery placeholders in the macro call’s syntax tree and bail out instead of expanding on broken input—so callers only see the original parse diagnostic (e.g. missing An expansion test asserts that Reviewed by Cursor Bugbot for commit fe2a1ff. Bugbot is set up for automated code reviews on this repo. Configure here. |
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 3 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).
Summary
TokenMissingis now included in theis_missingclassification forSyntaxKind, and macro calls that contain a missing token (i.e., a parse error) are no longer expanded — the parse error diagnostic is considered sufficient. A test case is added to confirm that an incomplete macro invocation likearray![1, 2produces only the missing token parse error and is left unexpanded.Type of change
Please check one:
Why is this change needed?
When a macro call contained a missing token due to a parse error, the macro expander would still attempt to expand it, potentially producing confusing or redundant diagnostics. The root cause was that
TokenMissingwas not recognized as a "missing" kind inSyntaxKind::is_missing, so the expander had no way to detect this condition and bail out early.What was the behavior or documentation before?
TokenMissingwas not included inSyntaxKind::is_missing, so macro calls with missing tokens (e.g., an unclosed bracket) could still be passed to the macro expander, leading to expansion attempts on malformed syntax.What is the behavior or documentation after?
TokenMissingis now recognized bySyntaxKind::is_missing. Macro calls that contain a missing token are skipped during expansion, and only the original parse error diagnostic (e.g.,Missing token ']') is reported.Related issue or discussion (if any)
N/A
Additional context
The code generation for
missing_kindsingenerator.rswas also updated to includeTokenMissingalongside enum missing variants, ensuring the generated kind classification stays consistent with the new behavior.