Make std::env::{set_var, remove_var} unsafe in edition 2024

[tbu-]

Allow calling these functions without unsafe blocks in editions up until 2021, but don't trigger the unused_unsafe lint for unsafe blocks containing these functions.

Fixes #27970.
Fixes #90308.
CC #124866.

[rustbot]

r? @joboet

rustbot has assigned @joboet.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/tools/compiletest

cc @jieyouxu

The Miri subtree was changed

cc @rust-lang/miri

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[RalfJung]

Should there be a warning on older editions, to make this not come entirely out of the blue when doing edition migration?

[tbu-]

Should there be a warning on older editions, to make this not come entirely out of the blue when doing edition migration?

I agree that this would be quite useful. It seems hard to do right now, though, because a stage 0 compiler will detect a lot of unused unsafe blocks because it doesn't know about the std::env::set_var unsafety. Perhaps this could be postponed until after one bootstrap cycle?

[RalfJung]

I agree that this would be quite useful. It seems hard to do right now, though, because a stage 0 compiler will detect a lot of unused unsafe blocks because it doesn't know about the std::env::set_var unsafety. Perhaps this could be postponed until after one bootstrap cycle?

I wasn't talking about unused_unsafe, but a lint that warns against using set_var/remove_var outside an unsafe block on old editions.

Also, I am not sure if it's the best idea to add new lang items for these functions. In the past the proposal was to add an attribute for "deprecating safety". Then we could e.g. also add that attribute to before_exec.

[BoxyUwU]

This had the relnotes label added but as far as I can tell this only affects 2024 edition. Is that understanding correct or is there a subtle stable affecting change here :3

[beetrees]

There is a change affecting other editions: the std::env::{set_var,remove_var} functions can no longer be converted to safe function pointers in any edition. For example, both of the following examples compile on current stable but not on current nightly:

use std::ffi::OsString;

fn main() {
	let x: fn(OsString, OsString) = std::env::set_var;
}

and

use std::ffi::OsString;

fn f(x: impl Fn(OsString, OsString)) {}

fn main() {
	f(std::env::set_var);
}

[joshtriplett]

This will be incorrect if we mark any other functions with this attribute where the unsafety is for a different reason.

[tbu-]

Yes, it'll be fixed before #125970 is merged. This PR was intentionally minimal so it could definitely make it into the Rust 2024 edition.

[joshtriplett]

@beetrees Yikes, that doesn't seem right. That sounds like a bug in the implementation of rustc_deprecated_safe_2024; If you're allowed to treat the function as safe, you should be allowed to do anything with it you could have with a safe function, including passing it as an argument.

[RalfJung]

That was a deliberate choice evaluated with crater. From my understanding, it is quite tricky to hook into the type system to achieve this, and it is what stalled the previous attempt at implementing this.

[cuviper]

For safe function pointers, a workaround is that you can wrap them in a safe closure.

let x: fn(OsString, OsString) = |name, value| std::env::set_var(name, value);

It's unfortunate, but maybe someone will figure out how to make this unnecessary later. Or it will just become moot after everyone migrates to 2024+ and they really are unsafe.