Uh oh!
There was an error while loading. Please reload this page.
compare generic constants using AbstractConsts - #76575
Conversation
oli-obk
left a comment
There was a problem hiding this comment.
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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
maybe make the try_unify_abstract_consts query a raw query and add a wrapper that has a fast path for such checks
oli-obk
commented
Sep 11, 2020
Does this treat constX:usize = {let x = 4; x + 1};constY: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
f7a7cf9Comparebors
commented
Sep 12, 2020
☔ 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: |
There was a problem hiding this comment.
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.
Oh, this is super cheap for !polymorphic const bodies... carry on
There was a problem hiding this comment.
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.
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)
oli-obk
commented
Sep 18, 2020
I think this can go out of draft mode now? 😄 |
lcnr
commented
Sep 18, 2020
@bors r=oli-obk rollup=never in case this influences perf |
bors
commented
Sep 18, 2020
📌 Commit 09e6254 has been approved by |
lcnr
commented
Sep 18, 2020
@bors r=oli-obk |
bors
commented
Sep 18, 2020
📌 Commit b764120 has been approved by |
bors
commented
Sep 18, 2020
bors
commented
Sep 18, 2020
☀️ 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