Description
openedon Oct 6, 2024
I tried this code:
struct D(&'static str);
impl Drop for D {
fn drop(&mut self) {
println!("dropping {}", self.0);
}
}
fn f1() {
println!("===== f1 =====");
let _local = D("drop initialized first");
(D("drop initialized second"), ()).1
}
fn f2() {
println!("===== f2 =====");
let _local = D("drop initialized first");
(D("drop initialized second"), ()).1;
}
fn f3() {
println!("===== f3 =====");
let _local = D("drop initialized first");
return (D("drop initialized second"), ()).1
}
fn f4() {
println!("===== f4 =====");
let _local = D("drop initialized first");
return (D("drop initialized second"), ()).1;
}
fn f5() {
println!("===== f5 =====");
let _local = D("drop initialized first");
let result = (D("drop initialized second"), ()).1;
result
}
fn main() {
f1();
f2();
f3();
f4();
f5();
}
I expected to see this happen:
All these functions should do exactly the same. The parameters would be dropped in opposite initialization order.
To my understanding of Rust, implicitly and explicitly returning the last argument should do the same.
Also the semicolon after a return
shouldn't make a difference.
And binding the result of something to a variable and then returning it, should also do the same.
Instead, this happened:
f1
and f3
drop parameters in initialization order while f2
, f4
and f5
drop parameters in opposite initialization order.
It's especially weird that the semicolon after the return has any effect. cargo fmt
will add semicolons after return
.
So if this is intentional, there's a bug in cargo fmt
. Formatting should never do a semantic change.
So when reproducing this bug, be sure to turn off automatic formatting if you have it enabled.
I also had some discussion with somebody on Reddit.
It seems to be necessary for lifetimes of temporary values to work correctly.
But I still think, this is confusing. So at least the return
case should be fixed. The compiler could just implicitly add a semicolon after the return.
And for implicit return values, even if it's just the implicit return value of a subscope, the let
transformation (like in f5
) should fix the issue.
And since it's possible to generally fiix this with code, I'm sure this can also be fixed in the compiler.
Meta
rustc --version --verbose
:
rustc 1.81.0 (eeb90cda1 2024-09-04)
binary: rustc
commit-hash: eeb90cda1969383f56a2637cbd3037bdf598841c
commit-date: 2024-09-04
host: x86_64-unknown-linux-gnu
release: 1.81.0
LLVM version: 18.1.7
(no backtrace available, since it doesn't crash)