Fix #151880: avoid ICE when CTFE evaluates static with unknown layout

[Pinguimmar]

This ICE occurred during const-eval when evaluating a static whose type has an unknown layout due to earlier type errors. In this situation the interpreter attempted to access the layout of the referenced static, triggering an assertion that assumed the layout was sized.

Adds a check when evaluating statics to detect unsized or unknown layouts and report a layout error instead of panicking.

closes #151880

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[rustbot]

r? @fmease

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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 69 candidates
• Random selection from 12 candidates

[RalfJung]

I'm afraid this is the wrong fix. The interpreter should never be invoked on invalid code in the first place.

[rust-log-analyzer]

The job aarch64-gnu-llvm-21-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

##[endgroup]
Executing "/scripts/stage_2_test_set1.sh"
+ /scripts/stage_2_test_set1.sh
+ '[' 1 == 1 ']'
+ echo 'PR_CI_JOB set; skipping tidy'
+ SKIP_TIDY='--skip tidy'
+ ../x.py --stage 2 test --skip tidy --skip compiler --skip src
PR_CI_JOB set; skipping tidy
##[group]Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.04s
##[endgroup]
---
test [crashes] tests/crashes/100041.rs ... ok
test [crashes] tests/crashes/102047.rs ... ok
test [crashes] tests/crashes/101557.rs ... ok
test [crashes] tests/crashes/103708.rs ... ok
2026-03-29T16:02:46.330905Z ERROR compiletest::runtest: fatal error, panic: "crashtest no longer crashes/triggers ICE, hooray! Please give it a meaningful name, add a doc-comment to the start of the test explaining why it exists and move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR description ensures that the corresponding ticket is auto-closed upon merge. If you want to see verbose output, set `COMPILETEST_VERBOSE_CRASHES=1`."
test [crashes] tests/crashes/102252.rs ... ok
test [crashes] tests/crashes/104685.rs ... FAILED
test [crashes] tests/crashes/105238-2.rs ... ok
test [crashes] tests/crashes/105238-1.rs ... ok
test [crashes] tests/crashes/106473.rs ... ok
---

---- [crashes] tests/crashes/104685.rs stdout ----
------rustc stdout------------------------------

------rustc stderr------------------------------
warning: `extern` declarations without an explicit ABI are deprecated
##[warning] --> /checkout/tests/crashes/104685.rs:5:1
  |
5 | extern {
  | ^^^^^^ help: explicitly specify the "C" ABI: `extern "C"`
  |
  = note: `#[warn(missing_abi)]` on by default

error[E0080]: the type `ExternType` has an unknown layout
##[error]  --> /checkout/tests/crashes/104685.rs:13:34
   |
13 | pub static EMPTY: () = unsafe { &EXTERN; };
   |                                  ^^^^^^ evaluation of `EMPTY` failed here

error: aborting due to 1 previous error; 1 warning emitted

For more information about this error, try `rustc --explain E0080`.

------------------------------------------

error: crashtest no longer crashes/triggers ICE, hooray! Please give it a meaningful name, add a doc-comment to the start of the test explaining why it exists and move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR description ensures that the corresponding ticket is auto-closed upon merge. If you want to see verbose output, set `COMPILETEST_VERBOSE_CRASHES=1`.

thread '[crashes] tests/crashes/104685.rs' panicked at src/tools/compiletest/src/runtest/crashes.rs:17:18:
fatal error
stack backtrace:
   8: __rustc::rust_begin_unwind

[Pinguimmar]

I'm afraid this is the wrong fix. The interpreter should never be invoked on invalid code in the first place.

I'm guessing it should have been noticed in type checking then. I will investigate a bit more before submitting a new commit.

[oli-obk]

You can check where the other errors are emitted and why they don't taint. I expect some of them to be from check_well_formed, which would make things hard,but maybe one of the errors is from typeck?