Do not promote values with const drop that need to be dropped#89988
Do not promote values with const drop that need to be dropped#89988bors merged 2 commits intorust-lang:masterfrom
Conversation
|
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
compiler/rustc_const_eval/src/transform/check_consts/qualifs.rs
Outdated
Show resolved
Hide resolved
|
r? @oli-obk |
11496d4 to
f8ea04e
Compare
|
cc @rust-lang/wg-const-eval discussion that spawned this: https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const.20drop.20and.20promoteds @bors r+ |
|
📌 Commit f8ea04e3a33eeb29438889e162c977a3fd5314d4 has been approved by |
compiler/rustc_const_eval/src/transform/check_consts/qualifs.rs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Why do we have both NeedsDrop and NeedsNonConrstDrop? That seems rather redundant.
There was a problem hiding this comment.
We only want to detect nonconst drops in const items, as const drops can actually get executed just fine.
There was a problem hiding this comment.
So why does check_consts have NeedsDrop then? Promotion is a separate pass after all.
|
@bors r- |
f8ea04e to
d1b72ef
Compare
Changes from rust-lang#88558 allowed using `~const Drop` in constants by introducing a new `NeedsNonConstDrop` qualif. The new qualif was also used for promotion purposes, and allowed promotion to happen for values that needs to be dropped but which do have a const drop impl. Since for promoted the drop implementation is never executed, this lead to observable change in behaviour. For example: ```rust struct Panic(); impl const Drop for Panic { fn drop(&mut self) { panic!(); } } fn main() { let _ = &Panic(); } ``` Restore the use of `NeedsDrop` qualif during promotion to avoid the issue.
d1b72ef to
915a581
Compare
|
@bors r+ |
|
📌 Commit 915a581 has been approved by |
| /// This must be ruled out because implicit promotion would remove side-effects | ||
| /// that occur as part of dropping that value. N.B., the implicit promotion has | ||
| /// to reject const Drop implementations because even if side-effects are ruled | ||
| /// out through other means, the execution of the drop could diverge. |
There was a problem hiding this comment.
"diverge" means "running into an endless loop", right? Panics seem like a much simpler example to me.
There was a problem hiding this comment.
The sentence was intended to encompass panicking. In the context of rustc we generally use diverge to describe a computation that does not return normally, but I can see where you are coming from.
There was a problem hiding this comment.
Oh I see. Yeah I think that is not standard terminology, at least not in my peer group. ;)
…askrgr Rollup of 8 pull requests Successful merges: - rust-lang#89766 (RustWrapper: adapt for an LLVM API change) - rust-lang#89867 (Fix macro_rules! duplication when reexported in the same module) - rust-lang#89941 (removing TLS support in x86_64-unknown-none-hermitkernel) - rust-lang#89956 (Suggest a case insensitive match name regardless of levenshtein distance) - rust-lang#89988 (Do not promote values with const drop that need to be dropped) - rust-lang#89997 (Add test for issue rust-lang#84957 - `str.as_bytes()` in a `const` expression) - rust-lang#90002 (:arrow_up: rust-analyzer) - rust-lang#90034 (Tiny tweak to Iterator::unzip() doc comment example.) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Changes from #88558 allowed using
~const Dropin constants byintroducing a new
NeedsNonConstDropqualif.The new qualif was also used for promotion purposes, and allowed
promotion to happen for values that needs to be dropped but which
do have a const drop impl.
Since for promoted the drop implementation is never executed,
this lead to observable change in behaviour. For example:
Restore the use of
NeedsDropqualif during promotion to avoid the issue.