fix: handle mismatched generic param kinds in substitution rewriter instead of panicking

[orizi]

Summary

Fixed a panic in the semantic analyzer when encountering mismatched generic parameter kinds between trait and impl functions by replacing extract_matches! with proper error handling that skips diagnostics when the generic argument type doesn't match the expected type parameter.

---

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 semantic analyzer would panic when processing impl functions that had mismatched generic parameter kinds compared to their corresponding trait functions. Specifically, when a trait function expected a type parameter but the impl function provided an impl parameter (like +Drop<felt252>), the extract_matches! macro would panic instead of gracefully handling the mismatch.

---

What was the behavior or documentation before?

The code would panic with extract_matches! when trying to extract a GenericArgumentId::Type from a generic argument that was actually a different kind (like GenericArgumentId::Impl).

---

What is the behavior or documentation after?

The code now properly handles the mismatch by checking the generic argument type with pattern matching and returning skip_diagnostic() when the kinds don't match, allowing the previously reported diagnostic (WrongGenericParamKindForImplFunction) to be the primary error without causing a panic.

---

Related issue or discussion (if any)

Fixes #9798

---

Additional context

The test case demonstrates the specific scenario: a trait function bar<T> with a type parameter T, but an impl function bar<+Drop<felt252>> with an impl parameter. The fix ensures that the appropriate error messages are shown (E2036 for parameter name incompatibility and E2038 for generic parameter kind incompatibility) without crashing the compiler.

---

Note

Medium Risk
Touches core type substitution rewriting logic and changes error propagation paths, which could affect downstream type resolution and diagnostics beyond the targeted mismatch case.

Overview
Fixes a crash in SubstitutionRewriter when rewriting TypeLongId::GenericParameter by replacing extract_matches! with an explicit GenericArgumentId::Type match and returning skip_diagnostic() when the generic argument kind is incompatible.

Adds a regression test covering a trait/impl mismatch where the trait expects a type generic but the impl provides an impl generic (e.g., bar<T> vs bar<+Drop<felt252>>), ensuring the compiler reports E2036/E2038 instead of panicking.

^{Written by Cursor Bugbot for commit a5034b8. 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 👈 (View in Graphite)
• 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
• 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).