2 Checks for sets/maps with mutable key types.
5 All of `HashMap`, `HashSet`, `BTreeMap` and
6 `BtreeSet` rely on either the hash or the order of keys be unchanging,
7 so having types with interior mutability is a bad idea.
12 It's correct to use a struct that contains interior mutability as a key, when its
13 implementation of `Hash` or `Ord` doesn't access any of the interior mutable types.
14 However, this lint is unable to recognize this, so it will often cause false positives in
15 theses cases. The `bytes` crate is a great example of this.
18 For custom `struct`s/`enum`s, this lint is unable to check for interior mutability behind
19 indirection. For example, `struct BadKey<'a>(&'a Cell<usize>)` will be seen as immutable
20 and cause a false negative if its implementation of `Hash`/`Ord` accesses the `Cell`.
22 This lint does check a few cases for indirection. Firstly, using some standard library
23 types (`Option`, `Result`, `Box`, `Rc`, `Arc`, `Vec`, `VecDeque`, `BTreeMap` and
24 `BTreeSet`) directly as keys (e.g. in `HashMap<Box<Cell<usize>>, ()>`) **will** trigger the
25 lint, because the impls of `Hash`/`Ord` for these types directly call `Hash`/`Ord` on their
28 Secondly, the implementations of `Hash` and `Ord` for raw pointers (`*const T` or `*mut T`)
29 apply only to the **address** of the contained value. Therefore, interior mutability
30 behind raw pointers (e.g. in `HashSet<*mut Cell<usize>>`) can't impact the value of `Hash`
31 or `Ord`, and therefore will not trigger this link. For more info, see issue
32 [#6745](https://github.com/rust-lang/rust-clippy/issues/6745).
36 use std::cmp::{PartialEq, Eq};
37 use std::collections::HashSet;
38 use std::hash::{Hash, Hasher};
39 use std::sync::atomic::AtomicUsize;
41 struct Bad(AtomicUsize);
42 impl PartialEq for Bad {
43 fn eq(&self, rhs: &Self) -> bool {
52 fn hash<H: Hasher>(&self, h: &mut H) {
59 let _: HashSet<Bad> = HashSet::new();