Skip to content

Implicit returns and missing semicolons after return might cause a different drop order #131313

Open

Description

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    A-destructorsArea: Destructors (`Drop`, …)Area: Destructors (`Drop`, …)C-discussionCategory: Discussion or questions that doesn't represent real issues.Category: Discussion or questions that doesn't represent real issues.T-langRelevant to the language team, which will review and decide on the PR/issue.Relevant to the language team, which will review and decide on the PR/issue.needs-triageThis issue may need triage. Remove it if it has been sufficiently triaged.This issue may need triage. Remove it if it has been sufficiently triaged.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions