@@ -89,19 +89,26 @@ declare_clippy_lint! {
89
89
90
90
declare_clippy_lint ! {
91
91
/// ### What it does
92
- /// This lint checks for functions that take immutable
93
- /// references and return mutable ones.
92
+ /// This lint checks for functions that take immutable references and return
93
+ /// mutable ones. This will not trigger if no unsafe code exists as there
94
+ /// are multiple safe functions which will do this transformation
95
+ ///
96
+ /// To be on the conservative side, if there's at least one mutable
97
+ /// reference with the output lifetime, this lint will not trigger.
94
98
///
95
99
/// ### Why is this bad?
96
- /// This is trivially unsound, as one can create two
97
- /// mutable references from the same (immutable!) source.
98
- /// This [error](https://github.com/rust-lang/rust/issues/39465)
99
- /// actually lead to an interim Rust release 1.15.1.
100
+ /// Creating a mutable reference which can be repeatably derived from an
101
+ /// immutable reference is unsound as it allows creating multiple live
102
+ /// mutable references to the same object.
103
+ ///
104
+ /// This [error](https://github.com/rust-lang/rust/issues/39465) actually
105
+ /// lead to an interim Rust release 1.15.1.
100
106
///
101
107
/// ### Known problems
102
- /// To be on the conservative side, if there's at least one
103
- /// mutable reference with the output lifetime, this lint will not trigger.
104
- /// In practice, this case is unlikely anyway.
108
+ /// This pattern is used by memory allocators to allow allocating multiple
109
+ /// objects while returning mutable references to each one. So long as
110
+ /// different mutable references are returned each time such a function may
111
+ /// be safe.
105
112
///
106
113
/// ### Example
107
114
/// ```ignore
0 commit comments