Creating a raw pointer to an external static requires an unsafe block

[Nemo157]

I tried this code (playground):

#![feature(raw_ref_op)]

extern {
    static FOO: u32;
}

mod foo {
    #[no_mangle]
    static FOO: u32 = 5;
}

fn main() {
    dbg!(core::ptr::addr_of!(FOO));
    dbg!(&raw const FOO);
}

I expected to see this happen: it compile and print the address of FOO twice.

Instead, this happened: compilation failed because accessing FOO requires an unsafe block

error[E0133]: use of extern static is unsafe and requires unsafe function or block
  --> src/main.rs:13:10
   |
13 |     dbg!(core::ptr::addr_of!(FOO));
   |          ^^^^^^^^^^^^^^^^^^^^^^^^ use of extern static
   |
   = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior
   = note: this error originates in the macro `core::ptr::addr_of` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0133]: use of extern static is unsafe and requires unsafe function or block
  --> src/main.rs:14:10
   |
14 |     dbg!(&raw const FOO);
   |          ^^^^^^^^^^^^^^ use of extern static
   |
   = note: extern statics are not controlled by the Rust type system: invalid data, aliasing violations or data races will cause undefined behavior

As far as I can tell none of the potential causes of UB can be caused by just creating a raw pointer to the static. This should be a safe operation, and only when attempting to use the pointer in the future should you need to prove validity of it.

[Nemo157]

Based on the MIR generated this is creating a temporary reference to the static, asserting its validity, so technically does need unsafe with the current desugaring.

[RalfJung]

Yeah I think this is a duplicate of #74840.

Basically the bug is that &raw const FOO desugars to &raw const *&FOO. That explains both problems.

[RalfJung]

Closing in favor of #74840.

[Nemo157]

I was reminded about this again today. #74840 got closed by banning extern static FOO: !;, not by changing how creating a raw pointer to it is treated, so this was not affected. #77096 I think covers the high-level "statics need to be fixed", but it doesn't directly mention this case. So I think it's worth having this re-opened as something that should be fixed. (I'll update the code in the OP for the new stable API).

[RalfJung]

FWIW, creating a raw pointer to a mutable static is also unsafe. So this looks deliberate to me. Not saying it can't be changed, but that should be considered a change/feature, not a bugfix (i.e. it will need T-lang FCP at least).