fix(semantic): match a pattern subtree only against a call subtree with the same delimiters

[orizi]

The MacroElement::Subtree matching arm never compared the delimiter kind of the pattern subtree
against the input subtree, so a rule ([$x:ident]) matched the call m!({a}). Compare the
delimiter kinds, treating a mismatch as a rule-match failure so a later rule may still match, as
rustc does.

Also resolves the adjacent TODO(Dean) about bracket terminal consistency: a pattern subtree
cannot have inconsistent delimiters in the AST, and a pattern missing a closing delimiter is
reported by the parser and its rule is already dropped - so no declaration time check is needed.

[reviewable-StarkWare]

This change is 

[orizi]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• fix(semantic): reject a + expansion repetition over zero groups #10315
• doc(semantic): document the macro expansion error arms as defensive #10314
• fix(semantic): reject a trailing macro repetition separator like rustc #10313
• feat(semantic): match and emit non-comma macro repetition separators #10312
• feat(parser): accept any single-token macro repetition separator #10311
• refactor(syntax): generalize the macro repetition separator node #10310
• fix(semantic): parenthesize an expression capture spliced into an expansion #10309
• fix(semantic): keep the trailing trivia of an expansion's placeholders and blocks #10308
• fix(semantic): capture an expr placeholder by what the parser consumed #10307
• test(semantic): pin the macro matcher behaviors that already agree with rustc #10306
• fix(semantic): reject a pattern that follows an expr placeholder with a token it would swallow #10305
• fix(semantic): reject the malformed macro rule declarations that silently do nothing #10304
• fix(semantic): match a pattern subtree only against a call subtree with the same delimiters #10303 👈 (View in Graphite)
• fix(semantic): reject a macro rule pattern that reuses a placeholder name #10302
• fix(semantic): expand a macro repetition over its own group of captures #10301
• test(semantic): pin the macro repetition operator and trailing separator behaviors #10300
• refactor(semantic): build a nested capture tree alongside the flat macro captures #10299
• fix(semantic): reject a macro expansion block with nothing repeating at its depth #10298
• fix(formatter): stop adding trailing separators in macro call token trees #10354
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cursor]

PR Summary

Medium Risk
Changes core macro rule matching semantics; behavior fixes may break macros that relied on cross-delimiter subtree matching, though that was unintended.

Overview
User-defined inline macro pattern matching now treats subtree delimiters ((), [], {}) as part of the rule, aligned with rustc: a pattern like ([$x:ident]) no longer matches a braced or parenthesized call subtree, and a delimiter mismatch fails that rule so a later rule can still apply.

In is_macro_rule_match_ex, the MacroElement::Subtree arm pairs pattern and input WrappedMacro / WrappedTokenTree kinds before recursing; non-subtree tokens at that position still fail the match. The declaration-time TODO about bracket-terminal consistency is removed—mismatched open/close delimiters are parser errors and unparsed rules are already skipped.

New expansion and diagnostic tests cover multi-rule fallback, nested inner subtrees, non-first subtree elements, empty braced subtrees, lone-rule E2158, and malformed pattern delimiters.

^{Reviewed by Cursor Bugbot for commit 74aada1. Bugbot is set up for automated code reviews on this repo. Configure here.}

[eytan-starkware]

@eytan-starkware+AGNT made 3 comments.
Reviewable status: 0 of 3 files reviewed, 2 unresolved discussions (waiting on eytan-starkware, orizi, and TomerStarkware).

---

a discussion (no related file):
Note: the comments below are from an automatic orizi-review run (Claude agents reviewing in Ori's style, findings adversarially verified before posting). Treat with the usual bot skepticism.

---

crates/cairo-lang-semantic/src/items/macro_declaration.rs line 672 at r1 (raw file):

                // whose delimiters are of another kind does not match, so the rule does not - it
                // is not an error, as another rule may match the call.
                let (inner_elements, inner_input_tokens) =

the three arms re-implement get_macro_elements inline. match only on what you actually need to compare/extract from the input, and keep the single extractor for the pattern side:

                let matcher_subtree = matcher_subtree.subtree(db);
                let inner_input_tokens = match (&matcher_subtree, input_subtree.subtree(db)) {
                    (
                        ast::WrappedMacro::Parenthesized(_),
                        ast::WrappedTokenTree::Parenthesized(input),
                    ) => input.tokens(db),
                    (ast::WrappedMacro::Braced(_), ast::WrappedTokenTree::Braced(input)) => {
                        input.tokens(db)
                    }
                    (ast::WrappedMacro::Bracketed(_), ast::WrappedTokenTree::Bracketed(input)) => {
                        input.tokens(db)
                    }
                    _ => return None,
                };
                let inner_elements = get_macro_elements(db, matcher_subtree);

note the _ arm also means a future WrappedMacro variant compiles fine and just never matches, instead of erroring here.

---

crates/cairo-lang-semantic/src/expr/test_data/inline_macros line 3181 at r1 (raw file):

//! > ==========================================================================

//! > Test a lone rule whose subtree delimiter matches the call's (valid).

the macro isn't wrong_delim in this one - the delimiters match. and the test adds nothing: pick!([a]) in the expansion data already covers a matching delimiter and additionally checks what it expands to, so this is strictly weaker. drop it. same for the nested / empty cases below - they repeat the expansion-data tests with one rule instead of two, and the "no matching rule" diagnostic is already pinned by the first test here.

[orizi]

@orizi+AGNT made 2 comments and resolved 2 discussions.
Reviewable status: 0 of 3 files reviewed, all discussions resolved (waiting on TomerStarkware).

---

crates/cairo-lang-semantic/src/expr/test_data/inline_macros line 3181 at r1 (raw file):

Previously, eytan-starkware+AGNT (Agent AGNT for eytan-starkware) wrote…

the macro isn't wrong_delim in this one - the delimiters match. and the test adds nothing: pick!([a]) in the expansion data already covers a matching delimiter and additionally checks what it expands to, so this is strictly weaker. drop it. same for the nested / empty cases below - they repeat the expansion-data tests with one rule instead of two, and the "no matching rule" diagnostic is already pinned by the first test here.

Dropped all three.

---

crates/cairo-lang-semantic/src/items/macro_declaration.rs line 672 at r1 (raw file):

Previously, eytan-starkware+AGNT (Agent AGNT for eytan-starkware) wrote…

the three arms re-implement get_macro_elements inline. match only on what you actually need to compare/extract from the input, and keep the single extractor for the pattern side:

                let matcher_subtree = matcher_subtree.subtree(db);
                let inner_input_tokens = match (&matcher_subtree, input_subtree.subtree(db)) {
                    (
                        ast::WrappedMacro::Parenthesized(_),
                        ast::WrappedTokenTree::Parenthesized(input),
                    ) => input.tokens(db),
                    (ast::WrappedMacro::Braced(_), ast::WrappedTokenTree::Braced(input)) => {
                        input.tokens(db)
                    }
                    (ast::WrappedMacro::Bracketed(_), ast::WrappedTokenTree::Bracketed(input)) => {
                        input.tokens(db)
                    }
                    _ => return None,
                };
                let inner_elements = get_macro_elements(db, matcher_subtree);

note the _ arm also means a future WrappedMacro variant compiles fine and just never matches, instead of erroring here.

Done, as suggested - input tokens matched positionally, the pattern side through get_macro_elements, and a future WrappedMacro variant just never matches.