Introduce unsafe methods for mutating environment

[jhpratt]

As requested in #92365. I'm not sure if it's worth mentioning platforms by name in the documentation. If we do, it's possible we miss something and lead people to a false sense of security (rather than having them check single-threadedness on every platform).

For sanity purposes I've made all the implementation functions unsafe, regardless of actual safety on that OS. This ensures the API is the same for every platform.

This still needs a tracking issue to be created. Given the discussion in #92365 of a "deprecated safe", I'm not certain whether these functions will ever actually be stabilized.

@rustbot label +T-libs +C-feature-request

r? @joshtriplett

[jhpratt]

Just pushed up the recommended changes. I think it might be worth holding off on merging this until it's clear whether a "deprecated safe" attribute will work.

[ghost]

I still have to implement it and show it will work, but the #[deprecated_safe] proposal was accepted.

• Add #[deprecated_safe] attribute to allow functions be be marked unsafe in a backwards compatible fashion lang-team#147
• Tracking Issue for #[deprecated_safe] attribute #94978

[jhpratt]

Awesome. I'll leave this open until the initial implementation lands, at which point I think it's safe to assume this won't be accepted.

[jhpratt]

For the same reason described in #92365, I'm marking this as blocked.

@rustbot label -S-waiting-on-review +S-blocked

[bors]

☔ The latest upstream changes (presumably #93668) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

r? libs

[ehuss]

Given #124866, I think this can be closed?

[jhpratt]

Definitely