Allow UnsafeCell content access without get in invalid_reference_casting lint

[Urgau]

#159730 relaxed the rules so that it's no longer necessary to use UnsafeCell::raw_get or UnsafeCell::get to access the content of an unsafe cell.

As a consequence this means that code this like is no longer invalid:

use std::cell::UnsafeCell;

unsafe fn get_mut_unchecked<T>(ptr: &UnsafeCell<T>) -> &mut T {
    let t = ptr as *const UnsafeCell<T> as *mut T;
    unsafe { &mut *t }
}

Fixes #159915
cc @RalfJung

[rustbot]

r? @mejrs

rustbot has assigned @mejrs.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 74 candidates
• Random selection from 15 candidates

[Urgau]

@RalfJung could you double-check and confirm that all of those casts are now fine.

View changes since the review

[RalfJung]

Depends on what you mean by "fine". ;)

They are not immediate UB. But getting a reference into a Cell is still incredibly dangerous. Just as dangerous as Cell::as_ptr though.

[Urgau]

Yeah, by "fine" I mean no longer immediate UB, it can still be very UB. Thanks for checking.

[RalfJung]

Wow that was fast ❤️

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[mejrs]

Are these casts valid? The lint, as implemented here, does not lint on them.

use std::cell::UnsafeCell;
use std::marker::PhantomData;

#[repr(transparent)]
struct MyUnsafeCell<T> {
    data: T,
    _p: PhantomData<UnsafeCell<T>>,
}

unsafe fn cast<T>(ptr: &MyUnsafeCell<T>) -> &mut T {
    let t = ptr as *const MyUnsafeCell<T> as *mut T;
    unsafe { &mut *t }
}

and

unsafe fn cast<T>(ptr: &UnsafeCell<T>) -> &mut UnsafeCell<T> {
    let t = ptr as *const _ as *mut _;
    unsafe { &mut *t }
}

[RalfJung]

Those casts are both dangerous but not immediate UB.

[Morgane55440]

Those casts are both dangerous but not immediate UB.

@RalfJung are you sure ? the first one triggers miri instantaneously.

use std::cell::UnsafeCell;
use std::marker::PhantomData;

#[repr(transparent)]
struct MyUnsafeCell<T> {
    data: T,
    _p: PhantomData<UnsafeCell<T>>,
}

#[allow(invalid_reference_casting)]
unsafe fn cast<T>(ptr: &MyUnsafeCell<T>) -> &mut T {
    let t = ptr as *const MyUnsafeCell<T> as *mut T;
    unsafe { &mut *t }
}

fn main() {
    let mut c : MyUnsafeCell<u8> = MyUnsafeCell { data : 2, _p : PhantomData };
    unsafe {cast(&mut c) };
}

Undefined Behavior: trying to retag from <367> for Unique permission at alloc194[0x0], but that tag only grants SharedReadOnly permission for this location
  --> src/main.rs:19:14
   |
19 |     unsafe { &mut *t }
   |              ^^^^^^^ this error occurs as part of retag at alloc194[0x0..0x1]

[RalfJung]

Oh wait I didn't read the example properly. I thought you were asking about what cast does to an unsafe cell, not about a weird custom type. What is that MyUnsafeCell type doing? That indeed makes no sense.

Please always give context for questions like this to make it more likely I look at the right parts of the code. Dumping an uncommented piece of code with weird corner cases without even mentioning the thought process that lead to the example isn't a good way to ask a question. Unfortunately I am often in a rush so I only dig deeper when there's some clear indication where to dig. Sorry for that.

OTOH the lint is not expected to find all UB so not linting on these is not necessarily a problem.

[mejrs]

Please always give context for questions like this

My apologies, I was also a bit in a rush myself 😅

Anyway, my mental model of interior mutability is that you always have to go through/pierce/peel/unwrap (what's the precise language for this?) UnsafeCell. Whether that is by using get or casting away the UnsafeCell, you must "peel away" a UnsafeCell wrapper.

But in the second example:

unsafe fn cast<T>(ptr: &UnsafeCell<T>) -> &mut UnsafeCell<T> {
    let t = ptr as *const _ as *mut _;
    unsafe { &mut *t }
}

...we cast the UnsafeCell itself, we don't peel it away Is that also OK?

OTOH the lint is not expected to find all UB so not linting on these is not necessarily a problem.

That's true, it doesn't have to be perfect. However what I see occasionally is:

• a (often very inexperienced in Rust) programmer will trigger a ub related lint
• they'll rationalize to themselves that their code is actually ok (this works in C, my program is single threaded, etc)
• they'll reshape their code without changing the semantics but in a way that the lint no longer understands
• they move on

It would be nice to make them jump a little bit higher.

[mejrs]

Regardless, the impl looks good to me so no need to block on anything.

@Urgau up to you if you want to make the lint smarter, either here or in a followup

r=me (after nits) if not

View changes since this review

[RalfJung]

Anyway, my mental model of interior mutability is that you always have to go through/pierce/peel/unwrap (what's the precise language for this?) UnsafeCell

That's not quite right. It's more that UnsafeCell "punches a hole" in the immutability requirement of &. So if you have &(i32, Cell<i32>, i32) (if we assume a linear layout) then & enforces immutability of bytes 0..4 and 8..12, but does not enforce anything for bytes 4..8. That's why you can mutate those bytes but not the others. It does not matter if you go "through" an UnsafeCell, you just have to ensure that all of the live shared references pointing to this memory have an UnsafeCell on the bytes you mutate.

That's why the 2nd example is okay.

[Urgau]

@bors r=mejrs

[rust-bors]

📌 Commit 6b0ea30 has been approved by mejrs

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

Reason for tree closure: spurious failures