fix: return None for macro rule with missing param kind instead of panicking

[orizi]

Summary

Fixed handling of declarative macro parameters that are missing kind specifiers by returning None instead of panicking with unreachable!(), and added a test case to verify proper error reporting for this scenario.

---

Type of change

Please check one:

• Bug fix (fixes incorrect behavior)
• New feature
• Performance improvement
• Documentation change with concrete technical impact
• Style, wording, formatting, or typo-only change

---

Why is this change needed?

The code was using unreachable!() for a case that can actually occur when macro parameters are missing kind specifiers, causing the compiler to panic instead of gracefully handling the error and providing proper diagnostics to the user.

---

What was the behavior or documentation before?

When a declarative macro parameter was missing a kind specifier (e.g., ($x) instead of ($x:expr)), the compiler would panic with an "unreachable" error during macro rule matching.

---

What is the behavior or documentation after?

The compiler now gracefully handles missing kind specifiers by returning None from the matching function, allowing proper error diagnostics to be generated (E1010: "Macro parameter must have a kind" and E2158: "No matching rule found in inline macro").

---

Related issue or discussion (if any)

Fixes #9797

---

Additional context

The test case demonstrates that the compiler now properly reports two errors: one for the missing kind specifier in the macro definition, and another for the failed macro invocation due to no matching rules.

---

Note

Low Risk
Low risk: small, localized change to macro pattern matching error handling plus a regression test; behavior only changes for invalid macro definitions.

Overview
Prevents a compiler panic during declarative macro matching when a macro rule parameter has no kind specifier (e.g., ($x)), by treating that rule as a non-match (None) rather than hitting unreachable!().

Adds a semantic test case asserting the expected diagnostics for this invalid macro definition, including the missing-kind error and the subsequent "no matching rule" error at the call site.

^{Written by Cursor Bugbot for commit dbb21ea. This will update automatically on new commits. Configure here.}

[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: handle mismatched generic param kinds in substitution rewriter instead of panicking #9815
• fix: allow statement-level consts in named argument shorthand instead of panicking #9814
• fix: use Terminal::text() for modifier text to avoid panic on malformed attribute args #9813
• fix: handle missing struct field in const evaluation instead of panicking #9812
• fix: emit diagnostic for unsupported extern fn in const evaluation instead of panicking #9811
• fix: emit diagnostic for non-type numeric literal suffix instead of panicking #9810
• fix: return None for macro rule with missing param kind instead of panicking #9809 👈 (View in Graphite)
• fix: handle missing return type context in loop body instead of panicking #9808
• fix: emit diagnostic for member access on unreduced impl type instead of panicking #9807
• fix: emit diagnostic for unsupported items in statement position instead of panicking #9806
• main

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

[eytan-starkware]

@eytan-starkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on TomerStarkware).

[TomerStarkware]

@TomerStarkware made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on orizi).