Change:
<ins> error[E0133]: call to unsafe function `std::env::set_var` is unsafe and requires unsafe block --> $DIR/unsafe-env.rs:10:5 | LL |     env::set_var("FOO", "BAR"); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ 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 --> $DIR/unsafe-env.rs:9:1 | LL | unsafe fn unsafe_fn() { | ^^^^^^^^^^^^^^^^^^^^^ note: the lint level is defined here --> $DIR/unsafe-env.rs:8:8 | LL | #[deny(unsafe_op_in_unsafe_fn)] |        ^^^^^^^^^^^^^^^^^^^^^^ error[E0133]: call to unsafe function `std::env::remove_var` is unsafe and requires unsafe block --> $DIR/unsafe-env.rs:12:5 | LL |     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 error[E0133]: call to unsafe function `unsafe_fn` is unsafe and requires unsafe block --> $DIR/unsafe-env.rs:15:9 | LL |         unsafe_fn(); |         ^^^^^^^^^^^ 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 </ins> error[E0133]: call to unsafe function `set_var` is unsafe and requires unsafe block <del> --> $DIR/unsafe-env.rs:13:5 </del> <ins> --> $DIR/unsafe-env.rs:23:5 </ins> | LL |     env::set_var("FOO", "BAR"); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: will become in Rust 2024, the above code is using Rust 2021, so this should compile with no issue. Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<pNot needed </p</detailsI think the root cause is the lint , commenting it out would make the code compile: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Thanks for the report! That should not happen. We did a so I don't know how this is even possible... any ideas? This seems to be some bad interaction with .
claim Hmmm, weird that crater run didn't catch this.
I posted a PR fixing this: . Does crater maybe restrict lints?
I don't think it does. Is this code part of the "nix" crate?
If you are asking if this problem originates from the nix crate, then yes, see
I am wondering whether the nix crate as published on fails to build with latest nightly due to this issue.
I think yes, the has been in Nix for a long time. One should be able to reproduce the build failure on a UNIX platform other than: I am currently on Linux, will try reproducing it on my mac tomorrow.
Looks like crater tested nix 0.26.4 and that failed already before the removevar/setvar change (). That's due to the 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.
I created an issue and a PR against nix-rust.
Yeah, we can reproduce this on macOS
The reason this was missed is a combination of and
WG-prioritization assigning priority (). label -I-prioritize +P-high
Fix already exists, just needs a review: .