In const fn in a macro call, raw ptr deref does not work even inside unsafe

[RalfJung]

The following code should build, but for some reason it does not:

#![feature(const_raw_ptr_deref)]
#![feature(raw_ref_macros)]

use std::ptr;

const fn test_fn(x: *const i32) {
    let x2 = unsafe { ptr::raw_const!(*x) };
}

Removing the const or adding a const_fn feature gate makes it build.

Cc @oli-obk @petrochenkov

[RalfJung]

Ah, adding the const_fn feature also helps... is that the expected behavior @oli-obk?

[oli-obk]

Yes and no. The MIR is &raw const (*_1), where _1 is x. We prevent the deref on the raw pointer, even if that's not an actual read. Basically it's a combination of

rust/src/librustc_mir/transform/check_unsafety.rs

Line 232 in 4a86573

UnsafetyViolationDetails::DerefOfRawPointer,

and

rust/src/librustc_mir/transform/check_unsafety.rs

Line 355 in 4a86573

UnsafetyViolationKind::General

So... I guess we need to change

rust/src/librustc_mir/transform/check_unsafety.rs

Line 231 in 4a86573

UnsafetyViolationKind::General,

to GeneralAndConstFn

[mlodato517]

Has this ticket been picked up by anyone? If not, I'd be happy to hop in (especially if it's as easy as changing that one argument!)

[CloudNClock]

Has this ticket been picked up by anyone? If not, I'd be happy to hop in (especially if it's as easy as changing that one argument!)

@mlodato517 Hello, can I take this issue? This is my first time trying to make a PR. Thank you.

[mlodato517]

That's okay with me (unless someone got here before both of us and took it 😉)

[RalfJung]

@5M1Sec please post PR-specific questions in the PR, not the issue. That just mixes up the discussion about a particular fix and the discussion about the problem in general -- very confusing. Instead, leave a message here to point out that a PR exists, or ping people on the PR.

I hid your comment here to avoid that confusion.

[RalfJung]

With #75578 having landed, is there anything left to do here?

[oli-obk]

depends on whether we want this to work without the const_raw_ptr_deref feature gate. It's not actually a deref, it's a raw pointer reborrow of sorts.

[RalfJung]

For me, "deref" is the unary * operator. That's also how MIR places use that term. So the gate makes sense for that.

Closing then.