Avoid duplicate type check errors for constrained struct - #159848
chenyukang wants to merge 2 commits into
Conversation
rustbot
added
S-waiting-on-review
|
r? @oli-obk rustbot has assigned @oli-obk. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| let expected_ty_provides_bounds = expected_ty.is_some_and(|expected_ty| { | ||
| !expected_ty.has_non_region_infer() | ||
| && self.can_eq(self.param_env, expected_ty, ty.normalized) | ||
| }); |
There was a problem hiding this comment.
That's a funky solution. I get how that would work, but it's very targeted to the duplication seen if there are expectations, when the same duplication happens without expectations, too. I'm nominating this for T-types discussion as I think we can find more general solutions to "compiler fails to prove the same thing 20 times and reports 20 slightly differently spanned errors.
oli-obk
added
I-types-nominated
|
Brought this up with the rest of T-types The gist is: Your solution is scary even if carefully crafted to prevent the issues that would occur with a naive version. It also doesn't apply generally to such errors. The only difference in the errors is the root span, all the extra information in the diagnostic pointing to the where bound is duplicated. With the information about which type and which where bound part of the error, we can deduplicate those errors simply by root span order (only report the top one if they are all the same file). Basically change |
|
☔ The latest upstream changes (presumably #163111) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
This branch has not been deployed
3 participants
Fixes #104637
When a struct literal has an equivalent concrete expected type, avoid registering the same struct bounds again, remove some noise.