static mut: allow mutable reference to arbitrary types, not just slices and arrays

[RalfJung]

For historical reasons, we allow this:

static mut ARRAY: &'static mut [isize] = &mut [1];

However, we do not allow this:

static mut INT: &'static mut isize = &mut 1;

I think that's terribly inconsistent. I don't care much for static mut, but we have to keep it around for backwards compatibility and so we have to keep supporting it properly in the compiler. In recent refactors of how we deal with mutability of data in static and const, I almost made a fatal mistake since I tested static mut INT: &'static mut isize = &mut 1 and concluded that we don't allow such 'static mutable references even inside static mut. After all, nobody would expect this to be allowed only for arrays and slices, right?!?? So for the sake of our own sanity, and of whoever else reverse engineers these rules in the future to understand what the Rust compiler accepts or does not accept, I propose that we accept this for all types, not just arrays and slices.

[rustbot]

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

[TaKO8Ki]

It's better to reroll. r? compiler

[davidtwco]

Implementation looks good to me, but this should have t-lang look over it.

[RalfJung]

Note that this is orthogonal to feature(const_mut_refs). That feature would still not accept the example since it only allows mutable references to memory that will be deallocated before the static mut is done computing. Also, without const_mut_refs, there's no way to write to a mutable reference in const context, so even though we allow more &mut expressions in static mut, there's not a ton one can do with them except for just using them as the final value of the static. (And if there is a way to write to a mutable reference in static mut, say due to an accidental stabilization, then that's already an issue for the array case, so allowing it on more types doesn't really make things worse.)

[joshtriplett]

We didn't get to this in today's @rust-lang/lang meeting, but let's handle it asynchronously. I think we should accept this:

@rfcbot merge

[joshtriplett]

@rfcbot cancel

Oops. I meant for that to be a lang FCP. Will remove compiler, FCP, and re-add compiler.

[rfcbot]

@joshtriplett proposal cancelled.

[joshtriplett]

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[homersimpsons]

Note that this feature may be deprecated / removed in the future following rust-lang/rfcs#3560

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[oli-obk]

@bors r=davidtwco,oli-obk

[bors]

📌 Commit 9a819ab has been approved by davidtwco,oli-obk

It is now in the queue for this repository.