fix: handle missing return type context in loop body instead of panicking

[orizi]

Summary

Fixed a panic that occurred when loop expressions were used in fixed-size array size positions by handling the case where no return type context is available and providing appropriate error diagnostics.

---

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 compiler was panicking when encountering loop expressions in array size positions because get_return_type() would return None (since loops in array size positions are outside function/loop contexts), but the code was calling unwrap() on this None value.

---

What was the behavior or documentation before?

The compiler would panic with an unwrap error when processing loop expressions in fixed-size array size positions, preventing proper error reporting.

---

What is the behavior or documentation after?

The compiler now gracefully handles this invalid usage by using a missing type when no return type context is available, allowing the semantic analysis to continue and report appropriate error diagnostics about type mismatches and invalid array sizes.

---

Related issue or discussion (if any)

Fixes #9787

---

Additional context

The fix includes a test case demonstrating the improved error handling for the specific case of fn f() -> [felt252; for _ in 0..1_u32 {}], which now produces clear error messages instead of panicking.

---

Note

Low Risk
Low risk: a small semantic-analysis guard replaces an unwrap() with a missing-type fallback, primarily affecting invalid code paths and error reporting.

Overview
Prevents a semantic-analysis panic when computing a loop body in contexts without an available return type (e.g. a for used in fixed-size array size position) by falling back to TypeId::missing instead of unwrap().

Adds a regression test ensuring this invalid construct no longer crashes and now produces regular diagnostics (type mismatch and invalid fixed-size array size).

^{Written by Cursor Bugbot for commit b495f1a. 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
• fix: handle missing return type context in loop body instead of panicking #9808 👈 (View in Graphite)
• 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 reviewed all commit messages and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on orizi).