Change:
<ins> // Ensures that the alignment check we insert for raw pointer dereferences // does not prevent crates without a panic_impl from compiling. // See rust-lang/rust#109996 // build-pass // compile-flags: -Cdebug-assertions=yes #![crate_type = "lib"] #![feature(lang_items)] #![feature(no_core)] #![no_core] #[lang = "sized"] trait Foo {} pub unsafe fn foo(x: *const i32) -> &'static i32 { unsafe { &*x } } </ins>

Discussion:
I tried this script: I expected to see a successful complication. Instead, this happened: Passing seems to fix this, so it looks like a possible regression introduced in It most recently worked on: rustc 1.70.0-nightly ( 2023-03-30) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority (). label -I-prioritize +P-high
label -I-prioritize +P-medium -P-high
This is a nice reproducer but the priority was reduced because the use seems very niche and/or unmotivated. Can you explain why compiling just is a requirement for you? Or what broader thing this is part of?
I was surprised that building the sysroot for i686-pc-windows-gnu doesn't hit this. and should be compiled as part of building the sysroot for mingw targets. Turns out we always compile them with the bootstrap compiler: As such this issue will block bumping the bootstrap compiler to one containing and breaks local rebuilds. I'm pretty sure it will also prevent me from updating cgclif to the latest nightly as cgclif rebuilds and when targeting mingw. The fix for this issue I think is to use instead. Or equivalently using , which expands to, as is not available in these crates.
Indeed, this could be problematic when this regression would be present in the stage0 compiler, or when is set to a nightly after . FWIW, this was originally caught which builds these startup objects with the stage1 compiler. I've never encountered any problems with this approach until now.
The declaration for the static is here: So (since it is not ) LLVM should be able to optimize out the alignment check, and indeed it does. suffices. So this problem is specific to unoptimized builds, which we explicitly identify as unsupported: So I don't think this qualifies as a regression. But there is a separate question: It looks like you have been using an unsupported configuration, and maybe found it useful? Maybe we should try to support this use case on those grounds?
The mere presence of this check in MIR that is codegened is enough to cause rustc to record a use of the panic lang item.

It doesn't matter that the check is removed by optimizations, rustc will check that the lang item is defined by this crate or any of it's dependencies.
Ah! Adding turns off debug assertions. Knowing that, this makes more sense.
Here's another reproducer using the bootstrap script: (this assumes is available, for example on Fedora you need to install ) So this is not an unsupported configuration, rsbegin/rsend is always compiled without optimizations and therefore this should still be considered a regression. FWIW, the only reason I compile Rust from source is to support the 32-bit targets. I've already reported this here: Does this unwinding issue still occurs on the 32-bit LLVM targets when bootstrapping Rust natively?
doesn't help, because it still does a Deref of the static pointer. Sorry I didn't respond on here for a while, I've been thinking about this and finally came up with something that I think works, if it is a bit ungraceful.
yes, it was fixed by Given Rust uses LLVM 16 now and no patching is required I suppose this target could be .