Clippy lints / Suspicious
Clippy lint · Suspicious · checked with Clippy 0.1.99
clippy::mutable_key_type: Checks for sets/maps with mutable key types
What it meansChecks for sets/maps with mutable key types. It is in the suspicious group and warns by default.
Does it matter?
All of HashMap, HashSet, BTreeMap and BtreeSet rely on either the hash or the order of keys be unchanging, so having types with interior mutability is a bad idea.
Code that is most likely wrong or useless. Warns by default.
How to fix it
Clippy does not fix this one automatically. Change the code by hand:
Flagged
use std::cmp::{PartialEq, Eq};
use std::collections::HashSet;
use std::hash::{Hash, Hasher};
use std::sync::atomic::AtomicUsize;
struct Bad(AtomicUsize);
impl PartialEq for Bad {
fn eq(&self, rhs: &Self) -> bool {
..
}
}
impl Eq for Bad {}
impl Hash for Bad {
fn hash<H: Hasher>(&self, h: &mut H) {
..
}
}
fn main() {
let _: HashSet<Bad> = HashSet::new();
}
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::mutable_key_type)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
mutable_key_type = "allow"One run
cargo clippy -- -A clippy::mutable-key-typeThe [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.
Settings in clippy.toml
ignore-interior-mutability: A list of paths to types that should be treated as if they do not contain interior mutability
Clippy's own documentation
What it does
Checks for sets/maps with mutable key types.
Why is this bad?
All of HashMap, HashSet, BTreeMap and
BtreeSet rely on either the hash or the order of keys be unchanging,
so having types with interior mutability is a bad idea.
Known problems
False Positives
It’s correct to use a struct that contains interior mutability as a key when its
implementation of Hash or Ord doesn’t access any of the interior mutable types.
However, this lint is unable to recognize this, so it will often cause false positives in
these cases.
False Negatives
This lint does not follow raw pointers (*const T or *mut T) as Hash and Ord
apply only to the address of the contained value. This can cause false negatives for
custom collections that use raw pointers internally.
Example
use std::cmp::{PartialEq, Eq};
use std::collections::HashSet;
use std::hash::{Hash, Hasher};
use std::sync::atomic::AtomicUsize;
struct Bad(AtomicUsize);
impl PartialEq for Bad {
fn eq(&self, rhs: &Self) -> bool {
..
}
}
impl Eq for Bad {}
impl Hash for Bad {
fn hash<H: Hasher>(&self, h: &mut H) {
..
}
}
fn main() {
let _: HashSet<Bad> = HashSet::new();
}
Configuration
-
ignore-interior-mutability: A list of paths to types that should be treated as if they do not contain interior mutability(default:
["bytes::Bytes"])
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- missing_transmute_annotationsChecks if transmute calls have all generics specified
- multi_assignmentsassignments don't nest intuitively
- mut_range_boundattempt to mutate range bound within loop
- needless_character_iterationchecking if a string is ascii using iterators
- needless_maybe_sized`?Sized` bound is ignored because of a `Sized` requirement
- no_effect_replacereplacing text with itself
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::missing_transmute_annotationsChecks if transmute calls have all generics specifiedRead it next →Did this answer your question?