edition 2024 migration of Command::before_exec is suboptimal and doesn't compile

[eric-seppanen]

I ran cargo +nightly fix --edition on this code:

pub fn spawn_child() {
    let _status = Command::new("some_program")
        .before_exec(|| {
            unsafe {
                // Make the child process its own process group leader
                if libc::setpgid(0, 0) != 0 {
                    return Err(std::io::Error::last_os_error());
                }
                Ok(())
            }
        })
        .status();
}

And it made the following changes:

pub fn spawn_child() {
    // TODO: Audit that the closure is async-signal-safe.
    let _status = unsafe { Command::new("some_program")
        .before_exec(|| {
            unsafe {
                // Make the child process its own process group leader
                if libc::setpgid(0, 0) != 0 {
                    return Err(std::io::Error::last_os_error());
                }
                Ok(())
            }
        }) }
        .status();
}

The output is unsatisfying in a few ways:

1. There are now two unsafe blocks, triggering the unused_unsafe lint.
2. before_exec is still deprecated, so perhaps it should just be replaced with pre_exec?
3. The formatting is a bit weird; The newly added braces should get additional line breaks.
4. The code doesn't compile once I add edition = "2024" to Cargo.toml:

error[E0716]: temporary value dropped while borrowed
  --> src/lib.rs:7:9
   |
7  |           Command::new("some_program").before_exec(|| {
   |           -^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |           |
   |  _________creates a temporary value which is freed while still in use
   | |
8  | |             unsafe {
9  | |                 // Make the child process its own process group leader
10 | |                 if libc::setpgid(0, 0) != 0 {
...  |
14 | |             }
15 | |         })
   | |          -
   | |          |
   | |__________temporary value is freed at the end of this statement
   |            borrow later used here
   |
   = note: consider using a `let` binding to create a longer lived value

I wouldn't have submitted an issue based on the first three, but since cargo fix is responsible for the new structure of the code, it seems like the failure to compile should have been avoidable.

I am confused about why this doesn't build. Why does pre_exec / before_exec cause there to be a dropped-while-borrowed temporary under the 2024 edition where none existed previously?

To repair the broken build, I guess something like this is required? (The let mut cmd part.)

pub fn spawn_child() {
    let mut cmd = Command::new("some_program");
    let _status = unsafe {
        cmd.pre_exec(|| {
            // Make the child process its own process group leader
            if libc::setpgid(0, 0) != 0 {
                return Err(std::io::Error::last_os_error());
            }
            Ok(())
        })
    }
    .status();
}

Meta

rustc --version --verbose:

rustc 1.85.0-nightly (c94848c04 2024-12-05)
binary: rustc
commit-hash: c94848c046d29f9a80c09aae758e27e418a289f2
commit-date: 2024-12-05
host: x86_64-unknown-linux-gnu
release: 1.85.0-nightly
LLVM version: 19.1.5

[kpreid]

I am confused about why this doesn't build. Why does pre_exec / before_exec cause there to be a dropped-while-borrowed temporary under the 2024 edition where none existed previously?

It’s because the Command builder methods return &mut Self, not Self, so what you’re returning from the block is an &mut Command, not a Command. This works in 2021 because, surprisingly, the temporary scope of the tail expression of a block is not the block (so any temporaries created in that block may outlive the block), but in 2024 it is. A simpler example which compiles in 2021 and not in 2024 is:

fn foo() {
    {
        &mut String::new()
    }.push_str("hello");
}

The current version of the migration guide doesn’t really explain this part and describes things as if the issue is only about drop order within the block. I’ll file an issue about that.

[eric-seppanen]

@kpreid thanks for the explanation!

[traviscross]

The main issue here is that there is currently no machine-applicable lint for tail_expr_drop_order:

• 2024 No migration for tail expression temporary drop #132814

If there were, then that would run along with the cargo fix --edition here and would make the code compile.

This also relates to...

• Possible false-negative with tail-expr-drop-order #132861

...in that tail_expr_drop_order catches less than it should.

The other two maybe-actionable asks in this issue are:

• Whether the migration should also change before_exec to pre_exec.
• Whether we should remove the inner unsafe.

cc @dingxiangfei2009 @tbu-

[tbu-]

• Whether the migration should also change before_exec to pre_exec.

I don't think it should. before_exec was deprecated before the 2024 edition and it's still deprecated.

• Whether we should remove the inner unsafe.

That sounds reasonable. I wonder how hard it is to implement this. I can probably not just walk the contents and remove all unsafe blocks, because there might be functions which open another safe scope.

[tbu-]

Since the tail expression drop order is a likely issue for most before_exec call sites, maybe we should enclose the entire expression involving before_exec in an unsafe block, sidestepping the issue?

[traviscross]

• Whether we should remove the inner unsafe.

That sounds reasonable. I wonder how hard it is to implement this. I can probably not just walk the contents and remove all unsafe blocks, because there might be functions which open another safe scope.

See also:

• An unsafe const fn being used to compute an array length or const generic is incorrectly described as being an "item". #133441
• unsafe blocks do not apply to array length expressions they contain #72359?