-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Cleanup: Eliminate ConstnessAnd #90274
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
Conversation
This now causes a lot of queries to be executed twice, as reveal_all forces NotConst
…ension for it This breaks a ~const test that will be fixed in a follow up commit of this PR
…the same information
…se TraitPredicate instead
Nothing else makes sense, and there is no "danger" in doing so, as it only does something if there are const bounds, which are unstable. This used to happen implicitly via the inferctxt before, which was much more fragile.
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 764aac2 with merge 5149eb5f1733b5aeadfdd0a2e8a18c34cc023b71... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #90282) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
Some queries do not care about if we are in a const context. Maybe we could always change the ParamEnv to be NonConst before caching?
I also think that we need a test for reproducing the error caused by the bad caching system.
impl TraitObligation<'tcx> { | ||
/// Returns `true` if the trait predicate is considered `const` in its ParamEnv. | ||
pub fn is_const(&self) -> bool { | ||
match (self.predicate.skip_binder().constness, self.param_env.constness()) { | ||
(ty::BoundConstness::ConstIfConst, hir::Constness::Const) => true, | ||
_ => false, | ||
} | ||
} | ||
} | ||
|
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 can hurt performance by making cache misses more common. Before it is just the trait and the constness, now it is the predicate's constness AND the ParamEnv's constness.
NonConst predicate inside a NonConst context is very common.
But what about a NonConst predicate inside a Const context? For example associated consts in traits. These don't use the same cache.
Perhaps we need a function BoundConstness.and(hir::Constness) -> hir::Constness
and use this to change the ParamEnv's constness to the result, not storing the BoundConstness in the cache.
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.
We could make ParamEnv::and
go through its anded value and check whether it needs constness, and remove said constness from itself if not
How would we handle the queries that do require constness? We could add a new query modifier stating whether constness is relevant and if not, automatically adjust the paramenv in its arguments |
Yes, that is what I meant. I used "always" changing, but I forgot to say to change those "that do not require constness" |
|
@oli-obk: do you mind if I take this PR and update it? You seem quite busy with other stuff and I really want this to land. I tried rebasing the PR a while back and I couldn't push to your repository. |
Yea, feel free to take over. I recommend splitting it into parts though, as the non-param-env parts should be perf and behaviour neutral |
@fee1-dead ohh great. I've promised @oli-obk that I was going to take this over but had some stuff on my plate and couldn't yet. If you're going ahead please do, otherwise I'd take it over probably this week. |
Cleanup: Eliminate ConstnessAnd This is almost a behaviour-free change and purely a refactoring. "almost" because we appear to be using the wrong ParamEnv somewhere already, and this is now exposed by failing a test using the unstable `~const` feature. We most definitely need to review all `without_const` and at some point should probably get rid of many of them by using `TraitPredicate` instead of `TraitRef`. This is a continuation of rust-lang#90274. r? `@oli-obk` cc `@spastorino` `@ecstatic-morse`
Cleanup: Eliminate ConstnessAnd This is almost a behaviour-free change and purely a refactoring. "almost" because we appear to be using the wrong ParamEnv somewhere already, and this is now exposed by failing a test using the unstable `~const` feature. We most definitely need to review all `without_const` and at some point should probably get rid of many of them by using `TraitPredicate` instead of `TraitRef`. This is a continuation of rust-lang/rust#90274. r? `@oli-obk` cc `@spastorino` `@ecstatic-morse`
Thanks @fee1-dead for carrying this over the finish line |
This is almost a behaviour-free change and purely a refactoring. "almost" because we appear to be using the wrong ParamEnv somewhere already, and this is now exposed by failing a test using the unstable
~const
feature. I am looking into that, but not sure if I'll get to it this week.We most definitely need to review all
without_const
and at some point should probably get rid of many of them by using TraitPredicate instead of TraitRef.This pull request is best reviewed commit by commit, as it works on each commit (modulo some ui changes that will go away once I squash 764aac2 into 8e84aa9
r? @fee1-dead
cc @spastorino @ecstatic-morse