Taking a raw ref (&raw (const|mut)) of a deref of pointer (*ptr) is always safe

[compiler-errors]

T-opsem decided in rust-lang/reference#1387 that *ptr is only unsafe if the place is accessed. This means that taking a raw ref of a deref expr is always safe, since it doesn't constitute a read.

This also relaxes the DEREF_NULLPTR lint to stop warning in the case of raw ref of a deref'd nullptr, and updates its docs to reflect that change in the UB specification.

This does not change the behavior of addr_of!((*ptr).field), since field projections still require the projection is in-bounds.

I'm on the fence whether this requires an FCP, since it's something that is guaranteed by the reference you could ostensibly call this a bugfix since we were counting truly safe operations as unsafe. Perhaps someone on opsem has a strong opinion? cc @rust-lang/opsem

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
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

[RalfJung]

Seems more like a lang question to me than an opsem question -- from an opsem side, the relevant question is whether there is UB, and the answer is "no". But from a lang perspective, it may seem odd to have unsafe rules that depend on the place-vs-value distinction, as many programmers do not properly understand this distinction. But maybe it's good that they will wonder " 🤔 why is this safe?" and then can be taught about said distinction?

Also note that due to #117288, sometimes we do have UB just from constructing a place. That's a MIR building bug but we should probably fix it before accepting such code as safe. (Sorry I didn't remember this when we spoke earlier.)

[compiler-errors]

👍 yep, this could be blocked on #117288 then. I think we can probably T-lang-nominate this regardless for discussion.

[nnethercote]

The code changes seem fine, so r=me on them if/when lang/opsem are happy with this.

[scottmcm]

Thinking about the DEREF_NULLPTR relaxation, I was pondering whether we should still lint -- but not say "this is UB" when it's not, of course -- on this as something that we might want you to do in a different way instead. @compiler-errors convinced me that rustc is not the correct place for that, however, and a "clippy suspicious" or similar would be the place to do that instead, if useful.

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this in lang triage today and agreed that this was both a good idea and one that's a natural consequence of our other recent decisions and so can go without FCP.

@bors r=nnethercode

[bors]

📌 Commit 25d617f has been approved by nnethercode

It is now in the queue for this repository.

[compiler-errors]

@bors r-

This is still unsound!! #117288

[traviscross]

Good catch. Thanks.

[workingjubilee]

warning: the feature raw_ref_op has been stable since 1.82.0-nightly and no longer requires an attribute to enable

Truly?!

[RalfJung]

Yes, truly. :)

#127679

[RalfJung]

So let _ = *raw_ptr; and match *raw_ptr { _ => ... } are not affected by this?

That does seem a bit inconsistent. It doesn't seem super useful to write code like that, but then it doesn't seem super useful to write &raw const *ptr either.

[compiler-errors]

@RalfJung: No, that would need to have another special case in the THIR.

[bors]

☔ The latest upstream changes (presumably #130390) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

That does seem a bit inconsistent. It doesn't seem super useful to write code like that, but then it doesn't seem super useful to write &raw const *ptr either.

🤷 I'd still like to fix it, regardless, I think, especially now that #117288 is closed. I'd also like if let _ = *raw_ptr; weren't unsafe, but that's far more difficult for unsafeck to implement.

[scottmcm]

I'd also like if let _ = *raw_ptr; weren't unsafe

I mean, we intentionally changed it to require being in an unsafe block...

[compiler-errors]

Because it was unsound? Could you provide some context?

[compiler-errors]

also this is

@rustbot ready

:D

[nnethercote]

@RalfJung, @scottmcm: any objections before I approve this?

[RalfJung]

Procedurally it has been approved by t-lang. I'm not very familiar with THIR so it's hard for me to say whether the implementation matches the intent. We don't have a dedicated test for the cases that should be rejected, but tests/ui/lint/lint-deref-nullptr.rs and tests/ui/static/raw-ref-deref-without-unsafe.rs to cover the most important cases I can think of.