Repository navigation
Produce a warning when using const with interior mutability #40543
Description
Originally reported in https://users.rust-lang.org/t/broken-atomics-puzzle/9533
Consider this code
use std::sync::atomic::{AtomicBool, Ordering};
pub const A: AtomicBool = AtomicBool::new(false);
fn main() {
A.compare_exchange(false, true, Ordering::SeqCst, Ordering::SeqCst);
println!("A = {}", A.load(Ordering::SeqCst));
}It compiles and runs cleanly, but produces unexpected results because const is used instead of static.
It would be nice to somehow give a warning for .compare_and_swap call, but I am not sure it is possible.
Activity
petrochenkov commentedon Mar 15, 2017
cc rust-lang/rfcs#885 https://github.com/Manishearth/rust-clippy/issues/829
matklad commentedon Mar 15, 2017
Note that
compare_and_swapuses&self:petrochenkov commentedon Mar 15, 2017
The underlying issue is the same -
Ais a rvalue and copied on use and this becomes observable when any mutability is involved, interior or exterior.steveklabnik commentedon Mar 15, 2017
New warnings generally require an RFC, but I'll let @rust-lang/compiler make the call
nikomatsakis commentedon Mar 16, 2017
I'm not sure -- precisely what conditions would trigger the warning? I agree there is a subtle footgun at play here, if you don't understand the rules.
matklad commentedon Mar 16, 2017
I think "calling a method exploiting interior mutability on
const" is the right condition, but I don't think we can really check it because we don't know which methods involve interior mutability.nikomatsakis commentedon Mar 21, 2017
Seems like it would have to "calling any method on
constif the type of thatconstinvolvesUnsafeCell", roughly speaking. Right?matklad commentedon Mar 21, 2017
Yep. Perhaps this won't add false positives in practice?
I wonder if we need to warn about creating constants with interior mutability. This is the root of the problem. Currently we need such constants for
ATOMIC_X_INIT, but it is only because there are no constant functions in Rust yet.Diggsey commentedon Sep 13, 2017
I'm not sure that's quite right:
selfare probably OK even on values with an UnsafeCell, since any side-effects wouldn't be visible anyway.Seems to me like this behaviour occurs whenever an internally mutable rvalue is borrowed. However, it's only surprising when that rvalue comes from a constant, because constants don't look like rvalues, and because they can be used multiple times, whereas most rvalues can only be used once.
Putting that together, it looks like the compiler should issue a warning whenever a constant containing an UnsafeCell is borrowed.
burdges commentedon Jan 19, 2018
Another autotrait would be required for this, no? All atomics have this problem, but maybe not all usages of
UnsafeCell? Also variance matters, like a&AtomicBoolor&Arc<T>sounds okay.Also, there are usages for
const fnwith smart pointer, likeMutex/Arc::new()should becomeconst fnso thatstaticscontainingArcs can be initialized at compile time, meaning you'll transiently have aconstwith an Atomic and/orUnsafeCellduring compilation.9 remaining items
PatchMixolydic commentedon Aug 11, 2022
Clippy has two lints for this situation:
clippy::declare_interior_mutable_constandclippy::borrow_interior_mutable_const. Since this seems to be a common stumbling block and there don't seem to be many reasons for placing an interior mutable value in aconst, I believe this lint should probably be lifted into rustc.mitsuhiko commentedon Aug 12, 2022
Now that
Mutexhas a const ctor this is more likely to trip up people. It has come up more than once in the discussions of the announcement post. If this lint is lifted it would probably be nice if types gain an attribute similar to#[must_use]on functions so that user code can also annotate this. An alternative would be not to warn on the declaration but when someone tries to do something likeacquire(thus adding the annotation to the methods instead).jplatte commentedon Aug 12, 2022
Yeah, an opt-in or opt-out would be nice. The clippy lint is pretty useful, but sometimes it's also unhelpful, for example when storing the result of http::header::HeaderName::from_static in a
constsuch that the compiler guarantees its validity.bbqsrc commentedon Apr 25, 2023
This too has hit me now.
vultix commentedon May 7, 2023
I accidentally ran into this when using a
OnceCell, accidentally reinitializing my type each call due toconstinstead ofstatic. This is certainly an easy footgun to run intoquaternic commentedon Jun 16, 2023
I've previously hit and reported a false positive (rust-lang/rust-clippy#7665) with the clippy lint clippy::declare_interior_mutable_const.
In short, when
[Cell::new(true); 7]fails as the type is notCopy, rustc correctly suggests this fix:However, this code triggers the clippy lint, and even gives the incorrect suggestion to change the
constto astatic.I did just learn that since 1.63 we've had this cleaner alternative:
Either way, the relevant question I was wondering about in that issue:
Are there cases where an interior mutable
constis never used by reference (e.g. by calling Once::call_once), but the lint would still be useful?Rollup merge of rust-lang#148407 - Urgau:suspicious_int_mutable_const…
Rollup merge of rust-lang#148407 - Urgau:suspicious_int_mutable_const…
Rollup merge of rust-lang#148407 - Urgau:suspicious_int_mutable_const…
Rollup merge of rust-lang#148407 - Urgau:suspicious_int_mutable_const…
Unrolled build for #148407
Rollup merge of #148407 - Urgau:suspicious_int_mutable_consts, r=Jona…
Rollup merge of rust-lang#148407 - Urgau:suspicious_int_mutable_const…
Rollup merge of #148407 - Urgau:suspicious_int_mutable_consts, r=Jona…