I'm not sure if this is a bug or not.
#![allow(unused)]
use std::fmt::Display;
struct Wrap<T: Display>(T);
impl<T: Display> Drop for Wrap<T> {
fn drop(&mut self) {
println!("{}", self.0);
}
}
fn main() {
let x;
{
let y = 1;
x = Wrap(&y);
panic!();
}
}
In the above code, I expected that, conceptually, the memory for y is deallocated, then the destructor for x is ran, then the memory for x is deallocated. Therefore, I would expect the code to not compile, since the Drop impl would be accessing freed memory.
Instead, the code compiles and runs fine, panicking and printing 1. Miri does not detect any UB.
Note that, if the value inside y has a destructor, then the code doesn't compile, as expected.
Removing the panic causes the code to stop compiling, as expected. Replacing the panic with drop(x) causes the code to compile again.
I am unable to cause UB with this behavior, but I still find it extremely weird.
Possibly related to #128225
Meta
Reproducible on the playground with version 1.92.0-nightly (2025-10-18 6380899f32599ea25615)
I'm not sure if this is a bug or not.
In the above code, I expected that, conceptually, the memory for
yis deallocated, then the destructor forxis ran, then the memory forxis deallocated. Therefore, I would expect the code to not compile, since theDropimpl would be accessing freed memory.Instead, the code compiles and runs fine, panicking and printing
1. Miri does not detect any UB.Note that, if the value inside
yhas a destructor, then the code doesn't compile, as expected.Removing the panic causes the code to stop compiling, as expected. Replacing the panic with
drop(x)causes the code to compile again.I am unable to cause UB with this behavior, but I still find it extremely weird.
Possibly related to #128225
Meta
Reproducible on the playground with version
1.92.0-nightly (2025-10-18 6380899f32599ea25615)