-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Aggressively check for non-PartialEq
types in const_to_pat
#72184
Conversation
☔ The latest upstream changes (presumably #72202) made this pull request unmergeable. Please resolve the merge conflicts. |
9009d34
to
78e3312
Compare
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
78e3312
to
2137e0e
Compare
// ones. This leverages the fact that function pointers with no late-bound lifetimes do | ||
// satisfy `PartialEq`. In other words, we transform `Option<for<'r> fn(&'r i32)>` to | ||
// `Option<fn(&'erased i32)>` and again check whether `PartialEq` is satisfied. | ||
// Obviously this is too permissive, but it is better than the old behavior, which |
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.
It would probably be a good idea to construct an example of something that runs into this (and presumably causes the same ICE that this is fixing most other occurrences of), and then file a bug about fixing that remaining hole, right?
@ecstatic-morse , can you provide a piece of example code that runs into that scenario?
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.
My thought was that you could write something like impl PartialEq for &'static MyStruct
and then somehow write a higher-ranked reference to MyStruct
in a const
. Depending on how the trait solver treats 'erased
, that might still cause an ICE.
However, I think the only way we let the user write higher-ranked types is with fn(&i32)
or Fn(&i32)
, neither of which can run into that problem. Additionally, users can no longer use trait objects in patterns since #71038. If these really are all the ways that the user can write higher-ranked types, perhaps this exactly the right amount of permissive?
This seems fine, as long as I'm correct in my understanding that this is just turning some ICE's from #65466 (most, to be fair) into static errors, while leaving the remaining ICEs from #65466 as ICEs. That is, the note about "this is too permissive, obviously" -- that doesn't correspond to any case where we previously had an ICE (or static error) and would now attempt to do codegen for invalid code, right? |
☔ The latest upstream changes (presumably #72575) made this pull request unmergeable. Please resolve the merge conflicts. |
@pnkfelix I'm just going to close this PR since #72184 (comment) has gone unanswered for so long. It was prompted by #67343 (comment). I guess you were right 😄. |
Resolves #65466.
Previously, we allowed constants without structural match violations through to codegen even if they did not satisfy
PartialEq
. This was because higher-ranked types such asfor<'r> fn(&'r i32)
needed to be allowed in patterns, despite the fact that they cannot be proven to bePartialEq
. I think this is due to a limitation in the trait solver?This PR falls back to a terrible hack–replacing all late-bound regions with concrete ones–after initially failing to prove
PartialEq
. This succeeds for higher-ranked types that would implementPartialEq
with some unconstrained set of concrete lifetimes, such as the aforementioned function pointer. Now we can reject types that don't satisfyPartialEq
without breaking backwards compatibility for function pointers. This prevents some ICEs during codegen.cc rust-lang/rfcs#1445
r? @pnkfelix (diff -w recommended)