std::env::remove_var() becomes unsafe even in Rust 2021

[SteveLauC]

I tried this code:

#![deny(unsafe_op_in_unsafe_fn)]

fn main() {
    unsafe { foo() };
}

unsafe fn foo() {
    std::env::remove_var("foo");
}

[package]
name = "remove_var_2021_reproduction"
version = "0.1.0"
edition = "2021"

[dependencies]

I expected to see this happen:

std::env::remove_var() will become unsafe in Rust 2024, the above code is using Rust 2021, so this should compile with no issue.

Instead, this happened:

$ cargo +nightly b
   Compiling remove_var_2021_reproduction v0.1.0 (remove_var_2021_reproduction)
error[E0133]: call to unsafe function `std::env::remove_var` is unsafe and requires unsafe block
 --> src/main.rs:8:5
  |
8 |     std::env::remove_var("foo");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
  |
  = note: for more information, see issue #71668 <https://github.com/rust-lang/rust/issues/71668>
  = note: consult the function's documentation for information on how to avoid undefined behavior
note: an unsafe function restricts its caller, but its body is safe by default
 --> src/main.rs:7:1
  |
7 | unsafe fn foo() {
  | ^^^^^^^^^^^^^^^
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![deny(unsafe_op_in_unsafe_fn)]
  |         ^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0133`.
error: could not compile `remove_var_2021_reproduction` (bin "remove_var_2021_reproduction") due to 1 previous error

Meta

rustc --version --verbose:

$ rustc +nightly --version --verbose
rustc 1.80.0-nightly (ada5e2c7b 2024-05-31)
binary: rustc
commit-hash: ada5e2c7b5427a591e30baeeee2698a5eb6db0bd
commit-date: 2024-05-31
host: x86_64-unknown-linux-gnu
release: 1.80.0-nightly
LLVM version: 18.1.6

Backtrace

Not needed

Possible root cause

I think the root cause is the lint unsafe_op_in_unsafe_fn, commenting it out would make the code compile:

$ rg unsafe_op src/main.rs
1:// #![deny(unsafe_op_in_unsafe_fn)]

$ cargo +nightly b
   Compiling remove_var_2021_reproduction v0.1.0 (remove_var_2021_reproduction)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.10s

[RalfJung]

Thanks for the report! That should not happen. We did a crater run so I don't know how this is even possible...

@tbu- any ideas? This seems to be some bad interaction with unsafe_op_in_unsafe_fn.

[tbu-]

@rustbot claim

Hmmm, weird that crater run didn't catch this.

[tbu-]

I posted a PR fixing this: #125925.

We did a crater run so I don't know how this is even possible...

Does crater maybe restrict lints?

[RalfJung]

I don't think it does. Is this code part of the "nix" crate?

[SteveLauC]

Is this code part of the "nix" crate?

If you are asking if this problem originates from the nix crate, then yes, see nix-rust/nix#2421 (comment)

[RalfJung]

I am wondering whether the nix crate as published on crates.io fails to build with latest nightly due to this issue.

[SteveLauC]

I am wondering whether the nix crate as published on crates.io fails to build with latest nightly due to this issue.

I think yes, the related code has been in Nix for a long time.

One should be able to reproduce the build failure on a UNIX platform other than:

if #[cfg(any(linux_android,
                     target_os = "fuchsia",
                     target_os = "wasi",
                     target_env = "uclibc",
                     target_os = "emscripten"))] {

I am currently on Linux, will try reproducing it on my mac tomorrow.

[RalfJung]

Looks like crater tested nix 0.26.4 and that failed already before the remove_var/set_var change (logfile here). That's due to the deny(warnings) which makes the build fail even when there are just warnings. I guess we can add this to the list of why having deny(warnings) in the code is considered bad practice.

[tbu-]

I created an issue and a PR against nix-rust.

[SteveLauC]

I am currently on Linux, will try reproducing it on my mac tomorrow.

Yeah, we can reproduce this on macOS

$ uname -rs
Darwin 22.6.0

$ cargo +nightly --version
cargo 1.80.0-nightly (7a6fad098 2024-05-31)

$ cargo +nightly b --all-features -q
error[E0133]: call to unsafe function `std::env::remove_var` is unsafe and requires unsafe block
  --> src/env.rs:52:17
   |
52 |                 env::remove_var(name);
   |                 ^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
   |
   = note: for more information, see issue #71668 <https://github.com/rust-lang/rust/issues/71668>
   = note: consult the function's documentation for information on how to avoid undefined behavior
note: an unsafe function restricts its caller, but its body is safe by default
  --> src/env.rs:41:1
   |
41 | pub unsafe fn clearenv() -> std::result::Result<(), ClearEnvError> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: the lint level is defined here
  --> src/lib.rs:94:9
   |
94 | #![deny(unsafe_op_in_unsafe_fn)]
   |         ^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0133`.
error: could not compile `nix` (lib) due to 1 previous error

[RalfJung]

The reason this was missed is a combination of nix-rust/nix#2423 and rust-lang/crater#727.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[tbu-]

WG-prioritization assigning priority

Fix already exists, just needs a review: #125925.