CTFE: avoid emitting a hard error on generic normalization failures by lcnr · Pull Request #149501 · rust-lang/rust

lcnr · 2025-12-01T12:03:46Z

The fix is quite unsatisfying and should not be necessary, cc #149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs.

cc @rust-lang/types I think we should try to fix issue #149283 in the near future and then remove this hack again.

I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this:

we only fetch the MIR in the eval_to_allocation_raw query
figuring out which MIR to use is hard
- dealing with trivial consts is annoying
- need to resolve instances for associated consts
- implementing this by hand is hard
inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness
- try_normalize_after_erasing_regions generally does two things
  - deal with ambiguity after inlining
  - deal with error tainting issues (please don't, we should stop doing that)
CTFE could be changed to always silently ignore normalization failures if we're in a generic body
- hides actual bugs <- went with this option

r? types

rustbot · 2025-12-01T12:03:49Z

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

rust-log-analyzer · 2025-12-01T12:59:53Z

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

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

warning ../../../../../package.json: License should be a valid SPDX license expression
warning No license field
[1/4] Resolving packages...
[2/4] Fetching packages...
error Error: https://registry.yarnpkg.com/ms/-/ms-2.1.3.tgz: Request failed "500 Internal Server Error"
    at ResponseError.ExtendableBuiltin (/node/lib/node_modules/yarn/lib/cli.js:696:66)
    at new ResponseError (/node/lib/node_modules/yarn/lib/cli.js:802:124)
    at Request.<anonymous> (/node/lib/node_modules/yarn/lib/cli.js:66750:16)
    at Request.emit (node:events:518:28)
    at module.exports.Request.onRequestResponse (/node/lib/node_modules/yarn/lib/cli.js:142287:10)
    at ClientRequest.emit (node:events:518:28)
    at HTTPParser.parserOnIncomingClient (node:_http_client:698:27)
    at HTTPParser.parserOnHeadersComplete (node:_http_common:119:17)
    at TLSSocket.socketOnData (node:_http_client:540:22)
    at TLSSocket.emit (node:events:518:28)
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn install did not exit successfully

thread 'main' (59568) panicked at src/tools/rustdoc-gui-test/src/main.rs:63:10:
unable to install browser-ui-test: Custom { kind: Other, error: "yarn install returned exit code exit status: 1" }
stack backtrace:
   0: __rustc::rust_begin_unwind
             at /rustc/3b4dd9bf1410f8da6329baa36ce5e37673cbbd1f/library/std/src/panicking.rs:698:5
   1: core::panicking::panic_fmt
             at /rustc/3b4dd9bf1410f8da6329baa36ce5e37673cbbd1f/library/core/src/panicking.rs:80:14

RalfJung · 2025-12-01T19:37:24Z

😢
But I can live with this as a temporary work-around.

lcnr · 2025-12-03T08:50:56Z

@rust-lang/types would like to beta backport this as early as possible ideally. Can I get one of you to quickly look at this PR?

lqd · 2025-12-03T09:44:38Z

@lcnr Are you confident we can fix #149283 soon-ish? (I'm concerned about potential breakage issues we have to deal with, which if I remember correctly were encountered in previous efforts)

Either way, this PR also makes sense to me as a temporary fix. So r=me should you want it.

BoxyUwU · 2025-12-03T10:30:16Z

I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters

In the long term I think this is the right fix 🤔

Before this PR were we getting similar kinds of ICEs due to opaque types? I was looking at the doc comments for NormalizationFailure which link to tests/ui/layout/normalization-failure.rs which is also about layout computation failure due for generic bodies.

I'm not sure I feel confident in being able to judge whether there are any weird side effects from this PR or not. I'd certainly feel better to revert #147793 and then land this "normally" or if it really will be the near future that we fix #149283 then land that and then re-land #147793

lcnr · 2025-12-03T11:14:14Z

Good catch @BoxyUwU, there are apparently other "not quite a bug" reasons for normalization failures in well-formed programs. This PR causes us to also weaken CTFE errors due to param-env shadowing from a hard-error to simply returning TooGeneric :x

Now, not erroring in these cases also feels desirable to me. However, this is something I did not consider when writing this PR. More thoughts on this later

lcnr · 2025-12-03T11:16:39Z

@lcnr Are you confident we can fix #149283 soon-ish? (I'm concerned about potential breakage issues we have to deal with, which if I remember correctly were encountered in previous efforts)

soon-ish? no

it depends on whether somebody ends up working on this, it'd probably take a few months to get something working here (with mentoring) for a somewhat experienced contributor.

oli-obk · 2025-12-03T12:10:27Z

Short term let's land this. While I expect it to be possible to construct some edge case where we hide a bug and start erroring again when we fix #149283, I expect the fallout from that to be very small if nonexistent.

@bors r+

bors · 2025-12-03T12:10:30Z

📌 Commit 02d84c8 has been approved by oli-obk

It is now in the queue for this repository.

oli-obk · 2025-12-03T12:10:47Z

@bors r=lqd,oli-obk

bors · 2025-12-03T12:10:50Z

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: Update cargo submodule #149555

bors · 2025-12-03T12:10:51Z

📌 Commit 02d84c8 has been approved by lqd,oli-obk

It is now in the queue for this repository.

…, r=lqd,oli-obk CTFE: avoid emitting a hard error on generic normalization failures Fixes rust-lang#149081. The fix is quite unsatisfying and should not be necessary, cc rust-lang#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs. cc `@rust-lang/types` I think we should try to fix issue rust-lang#149283 in the near future and then remove this hack again. I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this: - we only fetch the MIR in the `eval_to_allocation_raw` query - figuring out which MIR to use is hard - dealing with trivial consts is annoying - need to resolve instances for associated consts - implementing this by hand is hard - inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness - `try_normalize_after_erasing_regions` generally does two things - deal with ambiguity after inlining - deal with error tainting issues (please don't, we should stop doing that) - CTFE could be changed to always silently ignore normalization failures if we're in a generic body - hides actual bugs <- went with this option r? types

Rollup of 9 pull requests Successful merges: - #147841 (Fix ICE when applying test macro to crate root) - #149501 (CTFE: avoid emitting a hard error on generic normalization failures) - #149517 (Implement blessing for tidy alphabetical check) - #149521 (Improve `io::Error::downcast`) - #149545 (fix the check for which expressions read never type) - #149549 (Regression test for system register `ttbr0_el2`) - #149579 (Motor OS: fix compile error) - #149595 (Tidying up `tests/ui/issues` tests [2/N]) - #149597 (Revert "implement and test `Iterator::{exactly_one, collect_array}`") r? `@ghost` `@rustbot` modify labels: rollup

…, r=lqd,oli-obk CTFE: avoid emitting a hard error on generic normalization failures Fixes rust-lang#149081. The fix is quite unsatisfying and should not be necessary, cc rust-lang#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs. cc ``@rust-lang/types`` I think we should try to fix issue rust-lang#149283 in the near future and then remove this hack again. I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this: - we only fetch the MIR in the `eval_to_allocation_raw` query - figuring out which MIR to use is hard - dealing with trivial consts is annoying - need to resolve instances for associated consts - implementing this by hand is hard - inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness - `try_normalize_after_erasing_regions` generally does two things - deal with ambiguity after inlining - deal with error tainting issues (please don't, we should stop doing that) - CTFE could be changed to always silently ignore normalization failures if we're in a generic body - hides actual bugs <- went with this option r? types

…, r=lqd,oli-obk CTFE: avoid emitting a hard error on generic normalization failures Fixes rust-lang#149081. The fix is quite unsatisfying and should not be necessary, cc rust-lang#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs. cc ```@rust-lang/types``` I think we should try to fix issue rust-lang#149283 in the near future and then remove this hack again. I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this: - we only fetch the MIR in the `eval_to_allocation_raw` query - figuring out which MIR to use is hard - dealing with trivial consts is annoying - need to resolve instances for associated consts - implementing this by hand is hard - inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness - `try_normalize_after_erasing_regions` generally does two things - deal with ambiguity after inlining - deal with error tainting issues (please don't, we should stop doing that) - CTFE could be changed to always silently ignore normalization failures if we're in a generic body - hides actual bugs <- went with this option r? types

Rollup of 12 pull requests Successful merges: - #147841 (Fix ICE when applying test macro to crate root) - #149147 (Fix unused_assignments false positives from macros) - #149183 (Use `TypingMode::PostAnalysis` in `try_evaluate_const`) - #149456 (std: don't call `current_os_id` from signal handler) - #149501 (CTFE: avoid emitting a hard error on generic normalization failures) - #149528 (reword error for invalid range patterns) - #149539 (Additional test for uN::{gather,scatter}_bits) - #149549 (Regression test for system register `ttbr0_el2`) - #149550 (Disable native-lib for x check miri) - #149554 (build-manifest: generate MSI and MINGW arrays from rustc) - #149557 (c-variadic: bpf and spirv do not support c-variadic definitions) - #149569 (Fix mailmap issue) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #149501 - lcnr:no-hard-error-on-norm-failure, r=lqd,oli-obk CTFE: avoid emitting a hard error on generic normalization failures Fixes #149081. The fix is quite unsatisfying and should not be necessary, cc #149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs. cc ````@rust-lang/types```` I think we should try to fix issue #149283 in the near future and then remove this hack again. I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this: - we only fetch the MIR in the `eval_to_allocation_raw` query - figuring out which MIR to use is hard - dealing with trivial consts is annoying - need to resolve instances for associated consts - implementing this by hand is hard - inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness - `try_normalize_after_erasing_regions` generally does two things - deal with ambiguity after inlining - deal with error tainting issues (please don't, we should stop doing that) - CTFE could be changed to always silently ignore normalization failures if we're in a generic body - hides actual bugs <- went with this option r? types

apiraino · 2025-12-04T15:13:48Z

Beta backport accepted as per compiler team on Zulip. A backport PR will be authored by the release team at the end of the current development cycle. Backport labels handled by them.

Note: before moving on with the backport @wesleywiser will investigate if we can revert the culprit PR first (comment). So this backport is approved but in stand-by. We will comment later on.

EDIT: A revert PR has been done in #149649 and it looks a solution we feel more confident in. So I'll move the beta backport approval there.

@rustbot label -beta-nominated -beta-accepted

apiraino · 2025-12-05T11:34:36Z

Besides everything, thank you so much @lcnr for your work on this!!

Rollup of 12 pull requests Successful merges: - rust-lang/rust#147841 (Fix ICE when applying test macro to crate root) - rust-lang/rust#149147 (Fix unused_assignments false positives from macros) - rust-lang/rust#149183 (Use `TypingMode::PostAnalysis` in `try_evaluate_const`) - rust-lang/rust#149456 (std: don't call `current_os_id` from signal handler) - rust-lang/rust#149501 (CTFE: avoid emitting a hard error on generic normalization failures) - rust-lang/rust#149528 (reword error for invalid range patterns) - rust-lang/rust#149539 (Additional test for uN::{gather,scatter}_bits) - rust-lang/rust#149549 (Regression test for system register `ttbr0_el2`) - rust-lang/rust#149550 (Disable native-lib for x check miri) - rust-lang/rust#149554 (build-manifest: generate MSI and MINGW arrays from rustc) - rust-lang/rust#149557 (c-variadic: bpf and spirv do not support c-variadic definitions) - rust-lang/rust#149569 (Fix mailmap issue) r? `@ghost` `@rustbot` modify labels: rollup

lcnr added 2 commits December 1, 2025 13:00

add test

9549166

generic normalization errors to TooGeneric

02d84c8

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 1, 2025

rustbot assigned spastorino Dec 1, 2025

rustbot added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Dec 1, 2025

lcnr closed this Dec 1, 2025

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 1, 2025

lcnr reopened this Dec 1, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 1, 2025

oli-obk approved these changes Dec 3, 2025

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 3, 2025

matthiaskrgr mentioned this pull request Dec 3, 2025

Rollup of 9 pull requests #149603

Closed

Zalathar mentioned this pull request Dec 4, 2025

Rollup of 14 pull requests #149628

Closed

This was referenced Dec 4, 2025

Rollup of 13 pull requests #149629

Closed

Rollup of 12 pull requests #149631

Merged

bors merged commit 40c97a9 into rust-lang:main Dec 4, 2025
19 of 22 checks passed

rustbot added this to the 1.93.0 milestone Dec 4, 2025

rustbot added beta-accepted Accepted for backporting to the compiler in the beta channel. and removed beta-accepted Accepted for backporting to the compiler in the beta channel. beta-nominated Nominated for backporting to the compiler in the beta channel. labels Dec 4, 2025

apiraino mentioned this pull request Dec 5, 2025

[beta] Revert "Replace NullOp::SizeOf and NullOp::AlignOf by lang items." #149649

Merged

lcnr deleted the no-hard-error-on-norm-failure branch December 5, 2025 13:49

theemathas mentioned this pull request Jan 29, 2026

Regression in 1.93.0 the type <XYZ as Archive>::Archived has an unknown layout #151791

Open

Uh oh!

Conversation

lcnr commented Dec 1, 2025 • edited by lqd Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Dec 1, 2025

Uh oh!

rust-log-analyzer commented Dec 1, 2025

Uh oh!

RalfJung commented Dec 1, 2025

Uh oh!

lcnr commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lqd commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BoxyUwU commented Dec 3, 2025

Uh oh!

lcnr commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lcnr commented Dec 3, 2025

Uh oh!

oli-obk commented Dec 3, 2025

Uh oh!

bors commented Dec 3, 2025

Uh oh!

oli-obk commented Dec 3, 2025

Uh oh!

bors commented Dec 3, 2025

Uh oh!

bors commented Dec 3, 2025

Uh oh!

Uh oh!

apiraino commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

apiraino commented Dec 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

lcnr commented Dec 1, 2025 •

edited by lqd

Loading

lcnr commented Dec 3, 2025 •

edited

Loading

lqd commented Dec 3, 2025 •

edited

Loading

lcnr commented Dec 3, 2025 •

edited

Loading

apiraino commented Dec 4, 2025 •

edited

Loading