Skip to content

Report CodegenError::Unsupported as a rustc diagnostic instead of panicking#1669

Open
soumik15630m wants to merge 1 commit into
rust-lang:mainfrom
soumik15630m:fix-unsupported-error-panic
Open

Report CodegenError::Unsupported as a rustc diagnostic instead of panicking#1669
soumik15630m wants to merge 1 commit into
rust-lang:mainfrom
soumik15630m:fix-unsupported-error-panic

Conversation

@soumik15630m

@soumik15630m soumik15630m commented Jul 1, 2026

Copy link
Copy Markdown

Summary

When Context::compile returns Err(CodegenError::Unsupported(_)),
src/base.rs currently falls through to the generic catch-all arm and
panics:

Err(err) => {
    panic!("Error while defining {name}: {err:?}", name = codegened_func.symbol_name);
}

This turns a recoverable, known-cause compilation error into an ICE.
The codebase already has a precedent for handling a specific
CodegenError variant gracefully — CodegenError::Verifier is caught
in its own arm just above and reported via early_dcx.early_fatal
instead of panicking. This PR adds a matching arm for
CodegenError::Unsupported.

Motivation

This gap was found while working on
bytecodealliance/wasmtime#13783, which changes x64 codegen to return
CodegenError::Unsupported instead of panicking when a function's
stack frame is too large to encode (see
#1656). Before that PR, Cranelift
never returned this error variant from this call site, so this gap in
cg_clif's own error handling was never exercised. With rust-lang/rustc_codegen_cranelift#13783's fix
applied, Context::compile now reaches this code path and previously
hit the generic panic!, producing an ICE with a stack trace instead
of a clean compiler error.

Testing

Built this against a local patch of bytecodealliance/wasmtime#13783
(via [patch.crates-io]) and rebuilt with y.sh build. Compiling the
repro from #1656
(let x = [0; 536870787_usize];) now produces:error: cranelift codegen error: stack frame size exceeds the 2GB limit supported by the x64 backend (see #1656)

instead of panicking on the Err at this call site.

Known follow-up (not fixed here)

With this change, the error is reported cleanly, but the worker thread
that calls early_fatal from inside this closure then triggers a
secondary panic in rustc_codegen_ssa ("expected abort due to worker
thread errors", back/write.rs:2107). This reproduces for the
existing Verifier arm too, using this same early_fatal pattern —
it's a pre-existing issue in how rustc's codegen coordinator handles a
worker thread calling early_fatal, tracked separately in #1664, and
out of scope for this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant