Remove promotion candidate gathering and checking from qualify_consts.rs
#66066
Conversation
rust-highfive
added
the
S-waiting-on-review
|
This is more easily reviewed commit-by-commit, and hiding whitespace changes will make the first commit more intelligible. |
This comment has been minimized.
This comment has been minimized.
|
It looks like removing |
ecstatic-morse
force-pushed
the
remove-promotion-from-qualify-consts
branch
2 times, most recently
from
5b09205
to
5e23e46
Compare
|
Interestingly, just removing it does not cause any test errors. I think this code-path will only be important if we try to promote a reference to a |
|
Specifically, this is the code I'm worried about. It looks for I plan to approximate this behavior in the new const-checker by setting qualifs conservatively (as well as setting an error bit) if there are errors during const-checking. I think this is roughly what was intended in this code? We'll need a crater run anyways when switching to the new const-checker, which should give us more confidence. I still think we should just leave this in for now (and erase the last commit in this PR). I would rather work on improving the final version, which will replace this entirely, than spend time on this. |
|
☔ The latest upstream changes (presumably #66143) made this pull request unmergeable. Please resolve the merge conflicts. |
|
I don't think there's any reason to care about const-checking errors, compilation will fail anyway, I was likely trying to avoid weird ICEs but nowadays everything is so much more robust that it's pointless. |
| // promote anything, since that can cause errors in a `const` if e.g. rvalue static | ||
| // promotion is attempted within a loop body. | ||
| let unleash_miri = self.tcx.sess.opts.debugging_opts.unleash_the_miri_inside_of_you; | ||
| let promotion_candidates = if has_controlflow_error && !unleash_miri { |
There was a problem hiding this comment.
I was going to say that this isn't needed (since IIRC the reason I added it was because there would be mismatches since qualify_consts doesn't see as many candidates as there are in the body, because it stops looking at BBs) but you did replace my HACK comment so I'm guessing you hit some other issue?
Actually, I'm still not sure this check is needed, promotion within fn bodies works just fine without it, so what gives?
There was a problem hiding this comment.
We can't do rvalue-static promotion in a loop with the current "storage dead removal" system for consts; it results in broken MIR and ultimately an ICE as the stack slot for the temp is never cleaned up:
const X: () = loop {
let x = &4;
};There was a problem hiding this comment.
Actually, there's no ICE on the test that hits this (sorry, it's been a few days since I ran them). There's just a regular error. I vaguely remember hitting something worse, but maybe we just always try promotion?
+ error[E0384]: cannot assign twice to immutable variable `_`
+ --> $DIR/issue-52475.rs:10:18
+ |
+ LL | x = &0; // Materialize a new AllocId
+ | ^ cannot assign twice to immutable variable
+
We no longer compare the results of `promote_consts::validate_candidates` with `checker.promotion_candidates`, and `promote_consts` becomes the canonical source for determining promotability.
Also removes any code used only to populate `promotion_candidates` during const checking.
The former was cleared from `qualifs_in_return_place`, and the latter was never checked. `QUALIF_ERROR_BIT` no longer corresponds to a real `Qualif`, however.
The old const-checker conservatively reset qualifs when `IsNotPromotable` was in the return place. Unfortunately, named variables have `IsNotPromotable`, so this could cause promotion to fail. This should work now.
ecstatic-morse
force-pushed
the
remove-promotion-from-qualify-consts
branch
from
5e23e46
to
ec5ba54
Compare
|
@bors r+ |
|
📌 Commit ec5ba54 has been approved by |
bors
added
S-waiting-on-bors
…onsts, r=eddyb Remove promotion candidate gathering and checking from `qualify_consts.rs` This makes promotion candidate gathering and checking the exclusive domain of `promote_consts`, but the `QualifyAndPromoteConsts` pass is still responsible for both const-checking and creating promoted MIR fragments. This should not be merged until the beta branches on Nov. 5. r? @eddyb
|
☀️ Test successful - checks-azure |
This makes promotion candidate gathering and checking the exclusive domain of
promote_consts, but theQualifyAndPromoteConstspass is still responsible for both const-checking and creating promoted MIR fragments.This should not be merged until the beta branches on Nov. 5.
r? @eddyb