-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
make evaluation track whether outlives relationships mattered #54401
Conversation
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 |
☔ The latest upstream changes (presumably #54389) made this pull request unmergeable. Please resolve the merge conflicts. |
I feel that this mismatch between evaluation and "normal" selection is fairly likely to cause quite a few problems - ICEs and the like (i.e., evaluation returns "success" for Also, the current implementation might kick a bunch of types out of the evaluation fastpath during trans, which is also quite unfortunate. How good looking are universe-based lifetimes? Can this wait for them? |
8732915
to
34424f6
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 |
☔ The latest upstream changes (presumably #54457) made this pull request unmergeable. Please resolve the merge conflicts. |
I don't disagree. This is partial motivator for getting rid of the distinction in the move to chalk-style trait evaluation (which I expect to be taking place in earnest this fall). In answer to your question about universes, I've been working on a branch for that on the side, hoping to open soon though I have to resolve a few complications. All of that said, it feels like this is a gaping soundness hole that we ought to close sooner rather than later. This PR seemed like a pretty simple and clean fix. Do you see any particular problems with it, or does it just not seem to go far enough for your taste? |
We could probably measure this — I was considering that we could make it less pessimistic by making evaluation look at the outlives code to see if it trivially holds. e.g., I believe it is true that if we see a |
Previously, evaluation ignored outlives relationships. Since we using evaluation to skip the "normal" trait selection (which enforces outlives relationships) this led to incorrect results in some cases.
86c806c
to
563ba10
Compare
let's see how bad does this regress performance due to caching losses @bors try |
☀️ Test successful - status-travis |
@rust-timer build 643b173 |
Success: Queued 643b173 with parent ae36663, comparison URL. |
The perf results seem to show minimal impact. I suspect the regressions (and improvements) shown are the result of noise:
|
Well, perhaps I was hasty in calling them noise. Still, it's a bit suspicious for |
@@ -900,7 +917,13 @@ impl<'cx, 'gcx, 'tcx> SelectionContext<'cx, 'gcx, 'tcx> { | |||
{ | |||
debug!("evaluate_stack({:?}) --> recursive", | |||
stack.fresh_trait_ref); | |||
let cycle = stack.iter().skip(1).take(rec_index + 1); | |||
|
|||
// Subtle: when checking for a coinductive cycle, we do |
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.
Could you give an example where this subtle thing is true? It certainly seems like we are comparing freshened regions, and that should be OK: freshening does not touch LBRs (even escaping LBRs), and trait evaluation pretty much works with the staticized version of a type, ignoring non-late-bound regions.
Closing in favor of #54624 |
…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
Previously, evaluation ignored outlives relationships. Since we using
evaluation to skip the "normal" trait selection (which enforces
outlives relationships) this led to incorrect results in some cases.
Fixes #54302
r? @arielb1