@@ -89,19 +89,26 @@ declare_clippy_lint! {
8989
9090declare_clippy_lint ! {
9191 /// ### 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.
9498 ///
9599 /// ### 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.
100106 ///
101107 /// ### 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.
105112 ///
106113 /// ### Example
107114 /// ```ignore
0 commit comments