Mutable borrow from immutable input(s)

[saarshah]

what is the problem with Clippy on if we return mutable from immutable . see the the following code...

pub unsafe fn get_unchecked_mut(&self, key: usize) -> &mut T {

self.get_element_at(key).get_occupied_mut()

}

I means above code is working properly , but clippy suggesting us its as error (Clippy Lints)

[Cerber-Ursi]

Simply stated, this is an UB if you somehow transform immutable reference to a variable into mutable one. Clippy doesn't try to look at the function's body to determine whether it is the case or two references are unrelated, it just throws a warning in. And, so to say, your code in fact contains an UB: if some optimisation assumes that the object is immutable, but it was in fact mutated (through the reference acquired by this function), you'll easily can get anything wrong.

[RustyYato]

Even if you are using interior mutability, this is almost always UB.
Note: The only way to use interior mutability is by using UnsafeCell or types that use UnsafeCell, like Cell, Mutex, or Atomic*.

[saarshah]

thanks for your reply.. its means rust compiler allow UB.. if yes, in this case, compiler , at least , must warn us.

[saarshah]

If we use UnsafeCell , there is also get function of UnsafeCell (UnsafeCell in std::cell - Rust), which doing the same thing.. So, what is the difference between doing manually or using UnsafeCell.

[Cerber-Ursi]

UnsafeCell is treated specially (more about it and the similar cases here). It is marked as the only thing which can be modified while being behind shared reference.

[kornel]

When you use unsafe {}, you take responsibility for ensuring the safety rules are upheld, as otherwise the unsafety can spread beyond the block.

[Hyeonu]

UnsafeCell is a language item. It is allowed to be modified under shared reference in the same sense as ManuallyDrop will not run destructor of its content.

Unsafe Rust is much more unsafe than unsafe C/++ as Rust restricts far much more things for the sake of performance. Those restrictions are automatically proven by compiler in safe context. But in unsafe { } it is you who has responsibility to guarantee ALL those restrictions. That's why I always (half-seriously) shout that the unsafe keyword should be renamed to unsafe_but_trust_me_i_know_what_im_doing_here

[Yandros]

@https://danielhenrymantilla.github.io/posts/2019-02-24-mutation-part-2-to-mut-or-not-to-mut#why-transmuting-to-mut-is-ub

Why transmuting & to &mut is UB

Well, because for any type T :

1. The only* way to mutate a T is through a unique handle on that value; i.e. , a straight-owned T , a &mut T , a &mut &mut T , etc.
2. This implies that it is not possible mutate a T through a &T shared reference .
3. Actually, the very existence of a &T shared reference prevents the existence of any other &mut T or straight-owned T handle that would allow us to mutate that data!!
4. In other words, whenever a & _ exists, the pointee is guaranteed to be immutable for the lifetime of the reference .
5. This is a very interesting invariant that the compiler can use and ( does use! ) to aggressively optimize your code.
6. So if the data turned out not to be immutable, these assumptions would be invalidated making the optimized code wrong. Such contract violation is the very definition of Undefined Behavior.

TL,DR

Once a reference reaches the “potentially shared” state ( &_ ), Rust asserts that the pointee is immutable (during the lifetime of the reference).