-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Suppress suggest try wrap when found is unresolved infer #145707
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: xizheyin <[email protected]>
Signed-off-by: xizheyin <[email protected]>
This PR modifies |
// when found is unresolved var, we can't suggest anything | ||
if exp_found.found.has_type_flags(TypeFlags::HAS_INFER_TY_VAR) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're checking for inference variables on the error path, would it make sense to do so in a way that doesn't require tracking them for all types on the happy path too?
I think the "found" type may also be very likely to have inference variables when it doesn't match the expected type, on account of how pattern type-checking works. The type of the constructor pattern is checked against the type of the scrutinee, without knowledge of what the constructor's type's generic arguments are; I think those are all left for type inference to handle. As such, I think something more targeted may be needed if the suggestion is to support types with generic arguments.
it seems like if the scrutinee isn't a reference while the pattern clearly is, we could try suggesting removing the |
@rustbot author |
☔ The latest upstream changes (presumably #145997) made this pull request unmergeable. Please resolve the merge conflicts. |
Fixes #145634
In this example,
&Some((1, 2))
is an&_
, and we cannot know the exact type, so I think suppressing this suggestion is the most appropriate choice here. This is similar to / inspired by #145361.I expanded
TypeFlags
to indicate whether a type contains a type withis_ty_var
true.The test with regression(#3680, #5358, #12552) are all ICE, and some are even from many years ago. Therefore, this change in PR should not have a significant impact on them?
Two commits shows the diff of the newly added test.
r? compiler