-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
handle outlives predicates in trait evaluation #54624
Conversation
8cc25ce
to
546768e
Compare
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.
I agree this is good. I'm happy to land this in place of my PR. Left a few nits/thoughts, though.
Also, do you still think we need to keep that !data.has_late_bound_regions()
check, though? If so, why?
if r_a == r_b { | ||
// for<'a> 'a: 'a. OK | ||
Ok(EvaluatedToOk) | ||
} else if r_a.is_late_bound() || r_b.is_late_bound() { |
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.
Annoyingly, the current region solver has one extra case to consider: the case where r_a
is 'static
. In that case, know it outlives any r_b
. But we support this case inconsistently owing to the leak-check. Not sure how relevant that is here.
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.
In particular, even within the leak check, we don't generate a constraint like 'a <= 'static
, and hence the leak-check doesn't fail:
rust/src/librustc/infer/region_constraints/mod.rs
Lines 731 to 733 in 80e6e3e
(_, &ReStatic) => { | |
// all regions are subregions of static, so we can ignore this | |
} |
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.
The caching code that is going wrong — however — only cares about predicate_must_hold
, so it's ok to falsely fail from time to time. Still, we might want this to be is_late_bound() && is_late_bound()
?
You mentioned coherence, though...
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.
This is trait inference, so I don't think r_a
can ever end up being literally 'static
(as opposed to being some inference variable that happens to be equatable to 'static
).
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.
Actually, I think the only way something like this might happen if someone writes a literal where 'static: 'a
bound in their trait. In this case, evaluation would return an error, but fulfillment would be ok. I'm not sure this inconsistency
Currently I did the EvaluatedToAmbig
thing in intercrate mode, so this won't affect coherence.
Eventually I decided on adding support for the literal-ReStatic case, to not regress on handling |
There is no reason not to do it.
This makes evaluation more consistent with fulfillment.
fbb6b16
to
1069c0e
Compare
@bors r+ |
📌 Commit 1069c0e has been approved by |
⌛ Testing commit 1069c0e with merge 33a3327eb9e324cb13bca0eb2ffd9e23262c82fe... |
💔 Test failed - status-travis |
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 |
…tsakis handle outlives predicates in trait evaluation This handles higher-ranked outlives predicates in trait evaluation the same way they are handled in projection. Fixes rust-lang#54302. I think this is a more correct fix than rust-lang#54401 because it fixes the root case in evaluation instead of making evaluation used in less cases. However, we might want to go to a direction closer to @nikomatsakis's solution with Chalk. r? @nikomatsakis
handle outlives predicates in trait evaluation This handles higher-ranked outlives predicates in trait evaluation the same way they are handled in projection. Fixes #54302. I think this is a more correct fix than #54401 because it fixes the root case in evaluation instead of making evaluation used in less cases. However, we might want to go to a direction closer to @nikomatsakis's solution with Chalk. r? @nikomatsakis
☀️ Test successful - status-appveyor, status-travis |
This hurt perf by ~1% for several benchmarks: @arielb1: any thoughts? |
This handles higher-ranked outlives predicates in trait evaluation the same way they are handled in projection.
Fixes #54302. I think this is a more correct fix than #54401 because it fixes the root case in evaluation instead of making evaluation used in less cases. However, we might want to go to a direction closer to @nikomatsakis's solution with Chalk.
r? @nikomatsakis