-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
compare generic constants using AbstractConst
s
#76575
Conversation
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.
At the current level this is still very reasonable to keep an overview about, but I think we should proactively document the AbstractConstBuilder
in detail
// FIXME: we probably should only try to unify abstract constants | ||
// if the constants depend on generic parameters. | ||
// | ||
// Let's just see where this breaks :shrug: |
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.
maybe make the try_unify_abstract_consts
query a raw
query and add a wrapper that has a fast path for such checks
1cc022c
to
9ec4914
Compare
Does this treat const X: usize = { let x = 4; x + 1 };
const Y: usize = 4 + 1; the same? Should it? |
We do not yet support let bindings, as they add a I think it's a good idea to not support them for now and see how often they are desired once this lands on nightly. |
b5d6616
to
f7a7cf9
Compare
☔ The latest upstream changes (presumably #76637) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
if b_def == def && b_substs == substs { | ||
debug!("is_const_evaluatable: caller_bound ~~> ok"); | ||
return Ok(()); | ||
if let Some(ct) = AbstractConst::new(infcx.tcx, def, substs) { |
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 only need to build this in case we ever hit the situation where b_def != def || b_substs != substs
. I understand that this only computes it once even if needed multiple times, but maybe it can be cached in a mutable local Option
?
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.
Oh, this is super cheap for !polymorphic const bodies... carry on
@@ -16,18 +31,23 @@ pub fn is_const_evaluatable<'cx, 'tcx>( | |||
) -> Result<(), ErrorHandled> { | |||
debug!("is_const_evaluatable({:?}, {:?})", def, substs); | |||
if infcx.tcx.features().const_evaluatable_checked { |
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.
If I'm reading the code right, this is not needed as AbstractConst::new
will return None
if the feature gate is not enabled
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 kept it in as we otherwise have to reason globally here.
We would also be able to enter this conditional if we look at constants from extern crates if these crates use this feature without that check, which I don't actually want. (so that we can use it in libs
without worrying about this)
I think this can go out of draft mode now? 😄 |
f7a7cf9
to
09e6254
Compare
@bors r=oli-obk rollup=never in case this influences perf |
📌 Commit 09e6254 has been approved by |
@bors r=oli-obk |
📌 Commit b764120 has been approved by |
☀️ Test successful - checks-actions, checks-azure |
Hi! This PR showed up in the weekly perf triage report. It seems to have caused a It seems like this code is only needed behind a feature gate. @lcnr is there anything that can be done to reduce the impact for stable users? |
perf: move cold path of `process_obligations` into a separate function cc rust-lang#76575 This probably won't matter too much in the long run once rust-lang#69218 is merged so we may not want to merge this. r? `@ecstatic-morse`
This is a MVP of rust-lang/compiler-team#340. The changes in this PR should only be relevant if
feature(const_evaluatable_checked)
is enabled.currently based on top of #76559, so blocked on that.r? @oli-obk cc @varkor @eddyb