-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Set groundwork for proper const normalization #140549
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
changes to the core type system Some changes occurred in match checking cc @Nadrieril |
// system consts that we can retrieve with some `query const_arg_of_alias` query. Evaluating the | ||
// constant is "close enough" to getting the actual rhs of the const item for now even if it might | ||
// lead to some cycles | ||
super::evaluate_const(selcx.infcx, alias_ct, param_env) |
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.
feature(associated_const_equality)
might be a bit more cycle prone now due to evaluating here instead of normalizing to the impl definition and then evaluating? All the tests still pass though so I guess its fine- and both this and the previous way it worked can't stick around long term anyway.
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.
need to rebase
also, pls move the normalize.rs
move AliasKind branches into subfn into a separate commit if possible. Are there any other changes to that code while moving them?
merge conflicts :despair: |
Kinda, I had to change stuff from being working on AliasTy to AliasTerm so there's some minor changes for getting the types to line up, but behaviourally speaking it should be the same. I originally had it as its own commit but honestly it didn't really seem to matter much when I was looking over the changes because I had to switch from AliasTy to AliasKind at the same time 🤔 though i guess i could have just not done that... okay lemme split this up |
Okay first commit should contain no changes to the norm logic other than replacing the two match arms with an if/else. Second commit should be able to be reviewed to see the actual changes to the logic |
This comment has been minimized.
This comment has been minimized.
Oh |
This PR changes a file inside |
One of the crashes tests is also fixed by #140553 and in an actually principled way so I've just removed it and will let that PR add the test (which ive verified still ICEs under this PR). The other test I've updated to still reproduce since this PR doesn't really fix it afaik |
self.obligations.extend( | ||
infcx.tcx.predicates_of(free.def_id).instantiate_own(infcx.tcx, free.args).map( | ||
|(mut predicate, span)| { | ||
if free.has_escaping_bound_vars() { |
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.
why do that if free
has escaping bound vars instead of checking the predicate
?
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.
seems generally wrong to be instantiating early binders with bound vars, going to open an issue about this
5ea4762
to
5fb578e
Compare
@bors r+ rollup=iffy |
Set groundwork for proper const normalization r? lcnr Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do *before* proper support for normalizing const aliases is implemented. I dont *intend* for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in `project` for consts should only be reachable with mgca or ace.
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 3559e0a (parent) -> 1bea580 (this PR) Test differencesShow 20 test diffsStage 1
Stage 2
Additionally, 18 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 1bea580f364c65bd5f7380a1056e150df7b8a1a6 --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Finished benchmarking commit (1bea580): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 0.4%, secondary 2.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.2%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 769.569s -> 770.15s (0.08%) |
Most regressions are small, and a few look like non-noise. Looking at a function-level diff of the syn-1 benchmark... it looks like the changes are mostly small-ish changes around inlining, which doesn't seem worth further investigation.
|
r? lcnr
Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do before proper support for normalizing const aliases is implemented.
I dont intend for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in
project
for consts should only be reachable with mgca or ace.