`&raw const` can sometimes do temporary lifetime extension

[theemathas]

I'm not sure if this is a bug or not.

struct LoudDrop;

impl Drop for LoudDrop {
    fn drop(&mut self) {
        println!("drop");
    }
}

fn main() {
    let _ptr = &raw const Box::new((LoudDrop,)).0;
    println!("after let");
}

This code compiles, and prints after let, then prints drop. This contradicts the following comment in the compiler, which says that the above code creates an immediately-dangling pointer:

rust/compiler/rustc_hir_typeck/src/expr.rs

Lines 735 to 737 in 4eedad3

	// This is maybe too permissive, since it allows
	// `let u = &raw const Box::new((1,)).0`, which creates an
	// immediately dangling raw pointer.

@rustbot labels +T-lang +T-compiler +A-raw-pointers

Meta

Reproducible on the playground with version 1.91.0-nightly (2025-08-23 69b76df90c7ea63b5350)

[danielhenrymantilla]

Yeah this seems way too lenient. Even something as:

let a = &raw const *&<temporary>;
let b = &raw mut *&mut <temporary>;

is also allowed.

[dianne]

I'm not sure whether this is intended, but the Reference section on extending expressions doesn't appear to distinguish between normal and raw borrow operators; the linked section on borrow expressions covers both¹. Accordingly, the implementation of lifetime extension in the compiler doesn't distinguish between them.

Footnotes

1. And as far as I can tell the restriction on what place expressions are allowed as operands to raw borrow operators isn't documented there. ↩

[matthewjasper]

Having &raw do temporary lifetime extension was intended, to make code like the comment less likely to be incorrect. I think when writing the comment I forgot about this. The comment should be changed to one of these:

let ptr = &raw const core::convert::identity(&Box::new((1,))).0;
let ptr = core::convert::identity(&raw const Box::new((1,)).0);

The "documentation" of this check is #66708, which didn't get noticed when the addr_of macro was stabilized (because it was tagged with the feature gate of for &raw?) and somehow also got missed when stabilizing the language feature.

[danielhenrymantilla]

Having &raw do temporary lifetime extension was intended,

To nuance, you mean that for cases where usage of &raw with temporaries would be allowed, then lifespan-of-temporaries extension would be intended. But according to the typical error obtained from doing, e.g., &raw String::from("…"), or &raw mut 42, usage of &raw with temporaries is not intended to be allowed.

So there seems to be a C-bug Category: This is a bug. , here. Strongly hinted at by the fact the boolean check in that source code mentions checking whether the expression is_named (e.g., &raw const SOME_STATIC.field), when there is nothing named with things such as the allowed &raw mut *&mut 42.

[RalfJung]

Yeah it does seem odd that &raw mut 42 would be rejected but &raw mut *&mut 42 would be allowed. I guess &raw can "propagate" lifetime extension but cannot "initiate" it.

Maybe &raw mut 42 should just be a lint saying that this is discouraged since the exact lifetime of 42 is unclear? The lint should probably also fire for &raw const Box::new((LoudDrop,)).0. OTOH, &raw mut *_ is fine as that's just a reborrow (i.e., basically a cast), so the lifetime is whatever the lifetime of _ is.

[matthewjasper]

Having &raw do temporary lifetime extension was intended,

To nuance, you mean that for cases where usage of &raw with temporaries would be allowed, then lifespan-of-temporaries extension would be intended.

I meant it was done deliberately as part of the initial implementation PR, not necessarily intended as part of a final design.