fix(semantic): reject a + expansion repetition over zero groups

[orizi]

A $( ... )+ block in a macro expansion promises at least one
repetition, but a call matching zero groups silently expanded it to
nothing. Report the new E2210 instead, as rustc does ("this must repeat
at least once"). * and ? blocks over zero groups stay valid.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com

[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 👈 (View in Graphite)
• 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
• 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 user-defined macro expansion semantics and may break macros that silently expanded invalid +/? blocks; diagnostics are localized to the semantic macro expander.

Overview
Macro expansion now enforces the repetition operator on $(...) blocks in a rule’s expansion, not just how many groups the call captured. A + block must expand at least once (zero matching groups → E2210), and a ? block may expand at most once (more than one group → E2210). * behavior is unchanged.

MacroExpansionError is split into declaration/expansion failures vs. repetition-count mismatch; mismatch diagnostics are anchored on the macro call site (callers pass call_ptr from expr expansion and macro_call). Messages and error code E2210 are wired in SemanticDiagnosticKind.

Tests are updated so a ? expansion under a * pattern errors on multi-argument calls, plus new cases for +/*/? over zero or multiple groups.

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

[orizi]

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

---

crates/cairo-lang-semantic/src/diagnostic.rs line 1568 at r4 (raw file):

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

_ hands E2202 to whatever variant gets added next, silently. also this is the only arm in the whole error_code match that looks inside a kind - everywhere else is one code per kind. at minimum list them:

                MacroExpansionFailure::MissingRepetitionDriver
                | MacroExpansionFailure::ConflictingRepetitionDrivers
                | MacroExpansionFailure::MissingCapture(_) => error_code!(E2202),

Gone with the redesign - MacroExpansionFailed(_) is one code again and the new kind carries its own.

---

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

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

expansion_test_data/inline_macros:363 still pins "The operator of an expansion repetition is ignored" as the rule. it isn't, as of this PR. update that comment (and its test name) while the + case is being carved out, otherwise the two files document opposite invariants.

Updated - the golden is now "Test an expansion repetition whose operator differs from the pattern's, within its count." and its comment states the enforced promise and the rustc decl-time divergence.

---

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

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

"reachable by design" is exactly why it doesn't belong in this enum. MacroExpansionFailure is documented as the defensive backstop for things no program reaches; putting the one user-facing failure in it is what forces this doc caveat and the nested match in error_code. give it its own SemanticDiagnosticKind and have MacroExpansionError::report map to it - then this paragraph and the _ => arm both go away.

Done - the variant left MacroExpansionFailure entirely. The reachable failure is its own SemanticDiagnosticKind::MacroExpansionRepetitionCountMismatch (covering both ends of the operator's promise), constructed as its own MacroExpansionError variant and mapped by report; the caveat paragraph and the nested error_code match are both gone.

---

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

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

the ? half of this is still silently wrong. ? promises at most once, and nothing here caps the loop - ($($x:ident),*) => { $($x + )? 0 } on m!(a, b) expands to a + b + 0 with no diagnostic (verified against expand_inline_macros). and a ? block can't carry a separator, so the extra groups are emitted glued. if the operator's promise is enforced, enforce both ends here:

        let group_count = self.group_count(repetition)?;
        let valid = match repetition.operator(db) {
            ast::MacroRepetitionOperator::OneOrMore(_) => group_count >= 1,
            ast::MacroRepetitionOperator::ZeroOrOne(_) => group_count <= 1,
            _ => true,
        };
        if !valid {

or say why ? is deliberately left alone.

Enforced on both ends as suggested - + requires at least one group, ? allows at most one - and the mixed-operator golden now pins all three counts, with mixed_op!(1, 2) rejected at the call.

---

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

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

this is the first MacroExpansionFailure a user can actually hit, and it reports on the declaration only. a call to a macro declared in another file puts the error in that file, with nothing at the call and no hint which call triggered it - rustc points at the definition too, but adds in this macro invocation. both callers (compute.rs:836, macro_call.rs:165) have the call syntax; worth carrying it into the report.

Done - report now takes the call's stable pointer from both callers and anchors the count-mismatch diagnostic on the call that determined the group count (Cairo diagnostics are single-span, so the call site wins over the declaration; the message names the block's operator instead). The defensive failures stay on the expansion node.