You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Auto merge of rust-lang#132329 - compiler-errors:fn-and-destruct, r=lcnr
Implement `~const Destruct` effect goal in the new solver
This also fixed a subtle bug/limitation of the `NeedsConstDrop` check. Specifically, the "`Qualif`" API basically treats const drops as totally structural, even though dropping something that has an explicit `Drop` implementation cannot be structurally decomposed. For example:
```rust
#![feature(const_trait_impl)]
#[const_trait] trait Foo {
fn foo();
}
struct Conditional<T: Foo>(T);
impl Foo for () {
fn foo() {
println!("uh oh");
}
}
impl<T> const Drop for Conditional<T> where T: ~const Foo {
fn drop(&mut self) {
T::foo();
}
}
const FOO: () = {
let _ = Conditional(());
//~^ This should error.
};
fn main() {}
```
In this example, when checking if the `Conditional(())` rvalue is const-drop, since `Conditional` has a const destructor, we would previously recurse into the `()` value and determine it has nothing to drop, which means that it is considered to *not* need a const drop -- even though dropping `Conditional(())` would mean evaluating the destructor which relies on that `T: const Foo` bound to hold!
This could be fixed alternatively by banning any const conditions on `const Drop` impls, but that really sucks -- that means that basically no *interesting* const drop impls could be written. We have the capability to totally and intuitively support the right behavior, which I've implemented here.
0 commit comments