-
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
rustc: include ParamEnv in global trait select/eval cache keys. #66963
Conversation
59d8369
to
1d1298e
Compare
@bors try @rust-timer queue (I don't want to cause a perf regression) |
Awaiting bors try build completion |
⌛ Trying commit 1d1298e with merge 7cb06892a23b4da510686618c8730f0b2e8bd952... |
rustc: allow non-empty ParamEnv's in global trait select/eval caches. *Based on #66963* This appears to alleviate the symptoms of #65510 locally (without fixing WF directly), and is potentially easier to validate as sound (since it's a more ad-hoc version of queries we already have). I'm opening this PR primarily to test the effects on perf. r? @nikomatsakis cc @rust-lang/wg-traits
☀️ Try build successful - checks-azure |
Queued 7cb06892a23b4da510686618c8730f0b2e8bd952 with parent 2da942f, future comparison URL. |
@craterbot check |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
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 likely a bug fix and seems pretty reasonable. I'm curious to see the performance impact. I'm also curious to understand the behavior of the test case.
@@ -1079,12 +1079,10 @@ fn assemble_candidates_from_impls<'cx, 'tcx>( | |||
if !is_default { | |||
true | |||
} else if obligation.param_env.reveal == Reveal::All { | |||
debug_assert!(!poly_trait_ref.needs_infer()); |
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.
To be clear, did you see this debug assertion fail?
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.
Yes, in a run-pass specialization test, as I assume this can happen inside a temporary inference context inside a normalization query.
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 little bit of code is making me nervous. I'm wondering if we might get into some scenario where we have an unresolved inference variable and so we opt not to reveal the item. I think this would mean we normalize to (e.g.) <T as Foo<?X>>::Bar
. But then later the inference variable ?X
gets resolved in such a way that we could have revealed the value. This could lead to an inconsistency that causes some ICEs or something.
I think I would feel better if we flagged cases that involve inference variables as 'ambiguous'. I have to remember how that is done in this code, I can check if it has any impact.
Still, I could probably be persuaded to land it as is.
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'm pretty sure not revealing is "ambiguous", to the extent that projection would be.
Doesn't ambiguity result in not making progress, in general?
This could lead to an inconsistency that causes some ICEs or something.
Wouldn't that same situation apply to non-specialized impls when e.g. there's a Foo<A>
impl and a Foo<B>
one and so ?X
being resolved later to one of them would allow revealing Bar
?
I don't mind ICEs caused indirectly by this, considering this was even more ICE-y before, but also keep in mind this requires specialization, which is still unstable.
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.
Huh, looks like the assert was added by... me, in #35091, and it assumed that only monomorphic codegen would use the Reveal::All
codepath (I was curious and dug through the history).
@@ -1143,15 +1148,15 @@ impl<'cx, 'tcx> SelectionContext<'cx, 'tcx> { | |||
let tcx = self.tcx(); | |||
if self.can_use_global_caches(param_env) { | |||
let cache = tcx.evaluation_cache.hashmap.borrow(); | |||
if let Some(cached) = cache.get(&trait_ref) { | |||
if let Some(cached) = cache.get(¶m_env.and(trait_ref)) { |
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.
ok, so, in this case the only purpose is to capture the reveal mode, correct?
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.
Yes, I can change to be literally that if e.g. it's a perf problem.
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 wouldn't expect that to have a perf impact, but might be worth including in a comment somewhere.
@@ -1,5 +1,14 @@ | |||
error[E0277]: the trait bound `T: TraitWithAssoc` is not satisfied |
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.
Huh, this error is definitely not great. Do you understand what's going on here? (I don't, at least not yet)
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 think this is because T
ends up in the context of the impl Trait
which doesn't have the parameter nor the relevant bound in its ParamEnv
.
It's not great but this is a pre-existing bug in the existential type aliases feature that was being hidden because the Reveal
mode was getting ignored after the first time.
Finished benchmarking try commit 7cb06892a23b4da510686618c8730f0b2e8bd952, comparison URL. |
The perf regression could be from one of two things:
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
@eddyb well the perf impact looks fairly small to me: Not sure if it's worth worrying about, especially if we expect some improvements down the line. |
🎉 Experiment
|
Regression is spurious. |
OK, so, I ran an experiment where I made trait projection "ambiguous" when there were unresolved inference variables. I ran into an ICE in the It's also interesting why it gets an ICE. The ICE occurred because we were never able to definitely resolve the obligation, I think because we would never generate any constraint on What happens on this branch, I think, is that we ignore the impl, and hence we normalize to OK, I'm inclined to land this then, because:
|
@bors r+ |
📌 Commit 1d1298e has been approved by |
@bors r- |
Actually, let's land this together with #66821 |
rustc: allow non-empty ParamEnv's in global trait select/eval caches. *Based on #66963* This appears to alleviate the symptoms of #65510 locally (without fixing WF directly), and is potentially easier to validate as sound (since it's a more ad-hoc version of queries we already have). I'm opening this PR primarily to test the effects on perf. r? @nikomatsakis cc @rust-lang/wg-traits
Without #66821, this doesn't cache more than before, but it does include
Reveal
in the trait select/eval cache keys (viaParamEnv
), which is what caused the test failures in #66821.IIUC, this is a bug fix, because before this PR, cached select/eval results:
Reveal::UserFacing
, could limit whatReveal::All
sees (and cause ICEs?)Reveal::All
, could expose more toReveal::UserFacing
than intendedThe second case is the worse one IMO, I just hope we don't find people relying on it, on crater.
r? @nikomatsakis cc @rust-lang/compiler