Disallow *references* to static mut [Edition Idea]

[scottmcm]

Now that we have ptr::addr_of_mut!, the 2024 edition would be a great time to do @RalfJung's idea from #53639 (comment):

Disallow &MY_STATIC_MUT and &mut MY_STATIC_MUT entirely.

ptr::addr_of_mut!(MY_STATIC_MUT) could even be safe -- unlike taking a reference which is unsafe and often insta-UB -- and helps encourage avoiding races in the accesses, which is more practical than trying to avoid the UB from concurrent existence of references.

(Maybe people will end up just doing &mut *ptr::addr_of_mut!(MY_STATIC_MUT) without thinking through all the safety requirements -- in particular, making sure that the reference stops being used before a second reference is created -- but we can't force them to drink.)

[Lokathor]

I think that this would be much better if methods on a type could take *mut self, instead of only allowing &mut self, but that's not a hard blocker.

[scottmcm]

We discussed this in the lang team meeting today, and the consensus was in favour of going in this direction.

(With https://doc.rust-lang.org/std/cell/struct.SyncUnsafeCell.html and https://doc.rust-lang.org/std/ptr/macro.addr_of_mut.html we have options that we didn't back in 2018.)

Steps needed, I think:

• Add a lint that warns on using a & or &mut to a static mut, with some help suggesting other options.
• Make doing so a hard error in 2024 (in addition to the lint that affects the other editions)

[obeis]

@rustbot claim

[traviscross]

@rustbot labels -I-lang-nominated

I'm going to unnominate this, since there's nothing more to discuss until there is a PR to review. Please nominate such a PR as soon as it is posted.

(This is correctly labeled so we can track it with other ideas for the next edition without the nomination.)

[scottmcm]

@obeis Any updates? Have you managed to make progress here?

[obeis]

@scottmcm almost done. I will submit my pull request within the next two days at the latest. I apologize for the delay.

[RalfJung]

While implementing the lint in #117556, the question came up whether various cases of implicitly taking a reference should be linted against:

static mut STATIC = &[0, 1, 2];

let _ = STATIC.len();
let _ = STATIC[0];
let _ = format!("{}", STATIC);

The three listed cases are (fairly) harmless. However, let val = z.get() might not be harmless if get returns a 'static reference.

@scottmcm (and t-lang in general), what is your opinion on that?

[est31]

Personally I lean towards deprecating these cases, too, if the idea is that we want to mostly deprecate static mut anyways. As pointed out above, dot syntax can be used to create references without involving any &, so the creation of the potentially dangerous reference is quite hidden. By extension [] syntax and even field access syntax is in similar positions as well, when the type that they give access to is a static reference: but there you don't create a new reference but only access an existing one (example: static mut ST = (&[&0, &1, &2], &3); let _ = ST.0[0]; let _ = ST.1;).

[scottmcm]

I think this should be linting about anything that's created enough of a reference to trigger the reference rules -- if it can trigger UB when someone else holds a &mut to the static, that's worth linting about here.

[ravenexp]

Are Vec::leak() and the like still OK under the new rules?

[Lokathor]

This discussion is only about static mut variables (which can easily cause UB), not &mut T references with a 'static lifetime (which are 100% and UB free).

So Vec::leak and Box::leak and similar are unaffected.

[uazu]

Note that I don't find this particularly persuasive, since as far as the linker sees, static mut FOO: i32 and static FOO: SyncUnsafeCell<i32> are exactly the same. They're just as efficient.

Is there something you're seeing that actually needs static mut specifically, as opposed to static-with-UnsafeCell-internally?

Okay, I thought you were thinking of getting rid of mutable statics entirely. The 1.78 compiler warning which brought me to this page only mentioned addr_of_mut! and didn't say anything about static with UnsafeCell. So that is what we're supposed to use now instead of static mut? I really don't mind. I will switch if that is now the approved way. (Since you can get a *mut either way does it make any difference to safety? The coder still needs to know what they're doing.)

[RalfJung]

(Since you can get a *mut either way does it make any difference to safety? The coder still needs to know what they're doing.)

That's exactly why we are only deprecating references to static mut for now and encourage moving to raw pointers instead. Some people are arguing we should ban static mut entirely but so far those people have not managed to convince the team(s) that that step would be worth it.

My personal opinion is that switching from static mut with only raw pointers to static SyncUnsafeCell mostly feels like needless extra paperwork. So as far as I am concerned, if you're using static mut and raw pointers throughout, you're good. The moment you create references from those raw pointers you need to be extremely careful, and you should make them as short-lived as possible.

[scottmcm]

Well, the simplest transition is to https://doc.rust-lang.org/std/cell/struct.SyncUnsafeCell.html, but unfortunately that's not yet stable :( You can always also make your own types with appropriate unsafe impls that use UnsafeCell internally -- that's all SyncUnsafeCell is.

Since you can get a *mut either way does it make any difference to safety?

The differences are in whether you get a reference directly. *muts are allowed to alias, so you can make new ones all day long and keep them around -- the only problems are when you actually read or write through them. Whereas multiple independent live &muts at the same time is UB even without a data race. So that's the difference in footgun-ness.

[uazu]

This is clearer now, thanks. I can see the justification for some kind of static ... UnsafeCell approach instead of static mut because it does express the problems with mutable globals better in Rust terms, and the coder might be persuaded to read the UnsafeCell docs. It's not any safer for someone who is just copy/pasting incantations, though.

However, I couldn't use SyncUnsafeCell because I'm storing non-Sync types protected by a thread-ID check. So I needed to do what @eddyb explains at the top of #53639, i.e. create my own wrapper type that has an unsafe impl Sync and then justify the safety in comments. So telling everyone to use SyncUnsafeCell isn't going to work, unless the docs for SyncUnsafeCell explain that it doesn't cover all cases.

I don't think my new code is any better or worse without static mut, because I was already careful. It has 40% more LOC and has two more unsafe keywords. There's not much in it.

[yanchith]

My personal opinion is that switching from static mut with only raw pointers to static SyncUnsafeCell mostly feels like needless extra paperwork.

I feel this way too, and am glad that you do, too!

Still, if there's some busywork to discourage misuse, I can live with that, just please let me have (the equivalent of) my:

let p = ptr::addr_of_mut!(STATIC_MUT);

There's programs I can't express without. For instance, we have a low-overhead profiler in our company that is just two rdtscs, and a couple of adds, loads and stores per profiling zone. The profiler is very careful to not create references, and it can only be ran in isolated single-threaded scenarios when we are tuning algorithms.

[workingjubilee]

As a reminder, the Rust issue tracker is for filing bugs or issues with the language, it is not for use as a helpdesk. This includes creating code of dubious quality via passing a random number generator through a filter (or vector of weights) and asking us to not lint on it: When lints trigger correctly, they are supposed to trigger on code of dubious quality, to discourage reusing it.