Conversation
…ust the first While collecting a generic parameter's associated-item constraints, the `NonTraitTypeConstrained` arm did `return map`, abandoning the rest of the constraint list after the first bad one. So `+MyTrait<T>[Bogus1: u8, Bogus2: u16]` reported E2189 only for `Bogus1` and silently dropped `Bogus2`. Replace `return map` with `continue`, matching the sibling arm, so each invalid constraint is diagnosed. Adds an `expr/test_data/generics` golden (gated on the experimental `associated_item_constraints` feature) asserting both `Bogus1` and `Bogus2` are reported.
|
This change is |
This stack of pull requests is managed by Graphite. Learn more about stacking. |
PR SummaryLow Risk Overview In A generics semantic test asserts both Reviewed by Cursor Bugbot for commit 4f661ac. Bugbot is set up for automated code reviews on this repo. Configure here. |
TomerStarkware
left a comment
There was a problem hiding this comment.
@TomerStarkware reviewed 2 files and all commit messages, and made 1 comment.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on eytan-starkware).
Summary
When processing associated-item constraints on a generic parameter, a
returnstatement caused the loop to exit early after encountering the first invalid associated type, silently dropping any subsequent constraint errors. Replacingreturn mapwithcontinueallows the loop to keep processing remaining constraints and emit a diagnostic for each invalid one.Type of change
Please check one:
Why is this change needed?
When a generic bound included multiple invalid associated-item constraints (e.g.,
+MyTrait<T>[Bogus1: u8, Bogus2: u16]), only the first unknown associated type was reported. The earlyreturnprevented the remaining constraints from being validated, leaving subsequent errors silently ignored.What was the behavior or documentation before?
Only the first invalid associated type in a constraint list would produce a diagnostic. Any further invalid constraints in the same bound were silently skipped.
What is the behavior or documentation after?
Every invalid associated type in a constraint list produces its own diagnostic. For example, both
Bogus1andBogus2in+MyTrait<T>[Bogus1: u8, Bogus2: u16]are now reported as unknown associated types.Related issue or discussion (if any)
N/A
Additional context
A new test case was added to
genericstest data to verify that all invalid associated-item constraints are reported independently rather than stopping at the first failure.