Allow disabling const_item_mutation lint for all uses of a specific const item

[dtolnay]

Closes #77425.

The const_item_mutation lint will look at whether allow(const_item_mutation) is present on the const being "mutated", and if so, respect that as suppressing const_item_mutation for all uses of that const.

#[allow(const_item_mutation)]
const MYCONST: MyConst = MyConst {...};


MYCONST.foo = ""; // does not trigger const_item_mutation

This supersedes the special case around consts having a Drop impl introduced in #77251, so it is removed in this PR.

r? @Aaron1011

[Aaron1011]

I thought about doing this - however, this has the unfortunate side effect of suppressing the lint within the initializer:

const OTHER: [bool; 1] = [true];

#[allow(const_item_mutation)]
const MYCONST: u8 = {
    OTHER[0] = false; // doesn't warn
    0
};

While this seems unlikely to come up in practice, I would prefer if we separated lints that reference a const definition from lints that apply to a const definition (i.e. the initializer).

[dtolnay]

Considering this in terms of false negatives, I think this approach is less likely to have problematic/surprising false negatives in practice than the one from #77251. The programmer already typed an allow(const_item_mutation) so it's on their mind and they are consciously doing something bizarre. If they need a super big initializer expression for some reason to the point that false negatives are concerning, the initializer can be moved to a separate const.

const OTHER: [bool; 1] = [true];

const MYCONST_HELPER: u8 = {
    OTHER[0] = false; //~ warning
    0
};

#[allow(const_item_mutation)]
const MYCONST: u8 = MYCONST_HELPER;

I would prefer if we separated lints that reference a const definition from lints that apply to a const definition (i.e. the initializer).

I agree, though having a "shallow" way to talk about an item without talking about nested pieces like the initializer is an extremely general problem. Some examples where I have seen the same thing come up with existing lints are:

• In async-trait we expand from this:

  #[async_trait]
  trait Trait {
      async fn f() {...}
  }

  into effectively something like this:

  trait Trait {
      fn f() -> Pin<Box<dyn Future<Output = ()> + Send>> {
          #[allow(clippy::missing_docs_in_private_items)]
          async fn __f() {
              ... // original body
          }
          Box::pin(__f())
      }
  }

  Notice the problem? I can't apply the allow to __f without also applying it to everything I'm pasting into __f from the user's code.

• This case from rustc_data_structures:

  rust/compiler/rustc_data_structures/src/lib.rs

  Lines 46 to 54 in 0d37dca

  	#[macro_export]
  	macro_rules! likely {
  	($e:expr) => {
  	#[allow(unused_unsafe)]
  	{
  	unsafe { std::intrinsics::likely($e) }
  	}
  	};
  	}

  We want likely! to be callable from inside safe code as well as from inside unsafe code, so it has an allow(unused_unsafe) around its unsafe call to std::intrinsics::likely, but that allow(unused_unsafe) (and, frighteningly, the unsafe itself) also gets applied to the caller's $expr.

[dtolnay]

Will close to give a chance to design a way to distinguish lints that reference a const vs lints inside the const definition; we can follow up in #77425.

[danielhenrymantilla]

FWIW, I agree with this idea / initiative; lints are good, and this one was direly needed, but "false positive" on lints can be quite annoying.

• I have personally been intending to use StackBox::new_in(&mut Slot::EMPTY, …) (and to suggest downstream users of my crate do so too), only to realize this lint was firing. &mut None is an idiomatic alloc-in-caller-frame pattern, and my Slot type was a small wrapper around that pattern for some added type-safety, hence my adding a const to emulate the None variant. I'd have liked the possibility to make my type opt out of this lint.

  • In the meantime, I have defined a free function const fn slot(), so that the pattern has now become &mut slot() 🤷

Aside

This case from rustc_data_structures

FWIW, I have encountered this myself, and this is how I palliate it:

match $e { b => { #[allow(unused_unsafe)]] {
    unsafe { ::std::intrinsics::likely(b) }
}}}

or:

({
    #[inline]
    fn likely (b: bool) -> bool {
        unsafe { ::std::intrinsics::likely(b) }
    }
    likely
})($e)