Use delay_span_bug in validate-mir.

[cjgillot]

Fixes #126680
Fixes #137916
Fixes #146210 (dup of #137916)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

[rustbot]

r? @jdonszelmann

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

[jdonszelmann]

looks reasonable to me, could you rebase @cjgillot?

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[jdonszelmann]

why did this need to change?

[cjgillot]

Because the syntax error would hide the validation ICE.

[jdonszelmann]

@rustbot author

[jdonszelmann]

r=me after fixing ci

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[RalfJung]

Seems a bit odd to only do this at the end... I assume this is fairly cheap? Maybe we should just do it in find_mir_or_eval_fn after load_mir?

[RalfJung]

Are you sure delaying this is the right strategy? The reason the validator exists is that a bunch of things working on MIR (interpreter and MIR transforms) make assumptions about MIR having some reasonable shape. We don't want to litter them all with delay_span_bug, that will take up way too much room in the code. Delaying the bug in the validator will, I think, just push these ICEs to later in the execution.

[cjgillot]

I could split the validator in two:

• syntactic and dialect checks (is this terminator is allowed in this phase?) ;
• type and layout checks, which can spuriously fail depending on weird predicates and normalization issues.

All crashes are from the second category.

[RalfJung]

The validator is already split, right? There's the parts that need to be re-checked after a substitution is applied, and the parts that can't be broken by substitution.

What are examples of these "type and layout checks"?
For the interpreter we've so far had the rule that if the body doesn't typeck, it shouldn't be fed to the interpreter. A lot of that was type and layout stuff, which can have entirely nonsensical consequences, like nonsensical reference layout when it thinks [T] is sized (and therefore &[T] is a thin ptr), or when an unsized type gets plugged in for a T: Sized and so a ptr-sized &T suddenly is two prts large. If every MIR transform needs to be robust against such nonsense, we'll never be able to stop all the ICEs.

[cjgillot]

What are examples of these "type and layout checks"?

Checking that the source and destination of a Unsize cast are related by a trait. Checking that the source and destination of a Subtype projection are related...

For the interpreter we've so far had the rule that if the body doesn't typeck, it shouldn't be fed to the interpreter. A lot of that was type and layout stuff, which can have entirely nonsensical consequences, like nonsensical reference layout when it thinks [T] is sized (and therefore &[T] is a thin ptr), or when an unsized type gets plugged in for a T: Sized and so a ptr-sized &T suddenly is two prts large. If every MIR transform needs to be robust against such nonsense, we'll never be able to stop all the ICEs.

This is ok for the interpreter, as it can only call functions that are reachable. But the MIR optimizer is called on all bodies. We filter out those that are obviously erroneous, and try to filter out those that have impossible predicates. But those filters are leaky, and don't catch spurious normalization failures for example.

[RalfJung]

Some MIR opts call into the interpreter, so it does end up being called on dead code. IIRC @BoxyUwU was working on improving the guards that avoid nonsense code from getting so far into the compilation; not sure what the status of that is or whether it would help with the issues you are trying to fix here.

[BoxyUwU]

I'm not sure I fully understand the context of the mir validator 🤔 I think we should be running on the assumption that in the long term the interpreter can't be called on items where .has_param() on the generic args returns true.

If we don't evaluate things in that case then we can always avoid running the interpreter on things with trivial bounds/bounds that would cause problems with the interpreter 🤔 I'm a bit blocked on actually making progress here though. And no idea how it interacts with this change :)

[RalfJung]

This is not just about the interpreter, MIR opts also rely on MIR invariants.

[BoxyUwU]

Yeah, I don't have much of an idea of what's currently going wrong there 😅 only familiar with all the problems around const generics and the interpreter being run on stuff when it shouldn't

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job x86_64-gnu-gcc failed! Check out the build log: (web) (plain enhanced) (plain)

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

test [crashes] tests/crashes/138088.rs ... ok
test [crashes] tests/crashes/138089.rs ... ok
test [crashes] tests/crashes/138156.rs ... ok
test [crashes] tests/crashes/138534.rs ... ok
2026-01-14T16:23:01.334777Z 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/138274.rs ... FAILED
test [crashes] tests/crashes/138564.rs ... ok
test [crashes] tests/crashes/138707.rs ... ok
test [crashes] tests/crashes/139089.rs ... ok
test [crashes] tests/crashes/138660.rs ... ok
---

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

------rustc stderr------------------------------
error: future cannot be sent between threads safely
##[error]  --> /checkout/tests/crashes/138274.rs:16:32
   |
16 |         let _: Box<dyn Send> = Box::new(fut);
   |                                ^^^^^^^^^^^^^ future created by async block is not `Send`
   |
   = help: the trait `Send` is not implemented for `dyn Trait`
note: future is not `Send` as this value is used across an await
  --> /checkout/tests/crashes/138274.rs:14:22
   |
13 |             let _x = foo();
   |                 -- has type `Box<dyn Trait>` which is not `Send`
14 |             async {}.await;
   |                      ^^^^^ await occurs here, with `_x` maybe used later
   = note: required for the cast from `Box<{async block@/checkout/tests/crashes/138274.rs:12:19: 12:24}>` to `Box<dyn Send>`

error: aborting due to 1 previous error


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

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/138274.rs' panicked at src/tools/compiletest/src/runtest/crashes.rs:17:18:
fatal error
stack backtrace:
   5: __rustc::rust_begin_unwind

For more information how to resolve CI failures of this job, visit this link.

[feishiheng]

Hi @cjgillot

I’ve been investigating a similar ICE in #150378 and found that it appears to be a duplicate of #137916, as they share the same query stack.

By tracing the query dependencies, I pinpointed an issue where ordinary_coroutine_layout (in compiler/rustc_middle/src/ty/mod.rs) invokes optimized_mir before stalled coroutine obligations have been reported. This causes the MIR validator to encounter an inconsistent state while the diagnostic context (dcx) is still unaware of the underlying trait errors.

I’ve verified that ensuring check_coroutine_obligations is called within ordinary_coroutine_layout (as seen in this commit) resolves this ICE for the standard compilation pipeline. However, I noticed the ICE still persists when -Zvalidate-mir is enabled, suggesting there might be additional validation triggers or deeper inconsistencies involved.

Just wanted to share this in case it helps with your work here!