static_mut_refs: Automatic edition migration #123061

Activity

1. ehuss

   added

   A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lints

   T-langRelevant to the language teamRelevant to the language team

   A-edition-2024Area: The 2024 editionArea: The 2024 edition

   on Mar 25, 2024
2. traviscross commented on Mar 25, 2024

   

   traviscross

   on Mar 25, 2024

   Contributor

   More actions

   cc @obeis @scottmcm @RalfJung @est31

   Also see:

   • suggest mut removal sometimes for static mut ref lint/error #120574
3. traviscross commented on Mar 25, 2024

   

   traviscross

   on Mar 25, 2024

   Last edited by traviscross

   Contributor

   More actions

   Here's what @scottmcm earlier had to say about this:

   As mentioned in #114447 (comment), you can always change &BLAH to &*ptr::addr_of!(BLAH), which will compile, but still be just as UB-prone.

   The problem with taking references to static mut is that it's most often insta-UB, so there's no local change that can fix that, and yes, larger rework will typically be needed.

   For more reading, there's been discussion and slow movement for at least 5 years towards limiting static mut. See #53639 for example.
4. RalfJung commented on Mar 25, 2024

   

   RalfJung

   on Mar 25, 2024

   Member

   More actions

   Yeah, this is a case of "please use this opportunity to carefully review your code, based on today's understanding of how references work". There's no sensible automatic migration.

   👍React with 👍2Reacted by est31 and Lv Yitian
5. est31 commented on Mar 26, 2024

   

   est31

   on Mar 26, 2024

   Member

   More actions

   Yeah indeed edition changes are required to have automatic migrations implemented, but this is not a change where such automatic migration is easy to do (unlike say Trait to dyn Trait). It's similar to discussions about deprecating other UB-prone code like forbidding mem::uninitialized in new editions or such.

   Maybe that policy should be evolved into: if the API/pattern is UB-prone and easy to misuse, it is okay to not offer automatic edition migrations.
6. ryanavella commented on Apr 2, 2024

   

   ryanavella

   on Apr 2, 2024

   More actions

   Forgive me if this has been suggested before, but is there room for a --allow-unsound flag for cargo fix?

   I'm imagining that something like this:

   static mut X: i32 = 0;
   let _y = unsafe { &mut X };

   Could be transformed into this:

   static mut X: i32 = 0;
   let _y = unsafe {
       // TODO: this was rewritten by `cargo fix`, and needs to be manually audited.
       // See [https://github.com/rust-lang/rust/issues/114447] for more information.
       &mut *std::ptr::addr_of_mut!(X)
   };
7. traviscross commented on May 14, 2024

   

   traviscross

   on May 14, 2024

   Contributor

   More actions

   We're not necessarily going to add any specific migration lints here as we want people to carefully review any code that is affected by this. So let's go ahead and close this as we'll be willing to mark this as ready for Rust 2024 without any lints here.
8. traviscross

   closed this as completedon May 14, 2024