Fix large_futures ICE with the next solver

[tamird]

With the new trait solver enabled by default in nightly-2026-08-22 1, large_futures can ICE while inspecting an awaited future.

The lint switches to Codegen mode to obtain coroutine layouts but passes a type whose opaque aliases are still marked rigid from type checking. Because layout_of receives an already-Codegen environment, its environment-change path does not clear those markers.

Clear alias rigidity and normalize the awaited type in that environment before querying its layout. Codegen mode must remain: post-analysis layout queries cannot compute coroutine sizes 2.

The regression covers direct and pinned futures under both solvers, without other lint errors that could hide a delayed ICE.

Fixes rust-lang/rust#161495.

changelog: [large_futures]: Fix an ICE on awaited futures with the next trait solver.

[rustbot]

Thanks for the pull request. A reviewer will take a look after it receives 2 community reviews.

In the meantime, we would highly appreciate if you could try to review any of PRs waiting on community reviews.

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 9ec68e8

[tamird]

r? @jdonszelmann

[rustbot]

Error: Failed to set assignee to jdonszelmann: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[CommanderStorm]

community review:
not entirely sure I follow why ty::set_aliases_to_non_rigid (that would require a bit of deeper context that @jdonszelmann is likely better to judge 😅), but explanation and testcase sounds plausible to me.

View changes since this review

[tamird]

@CommanderStorm

not entirely sure I follow why ty::set_aliases_to_non_rigid

The rigidity marker is specific to the environment where the alias was normalized. We switch to Codegen, so those aliases need to be reconsidered in the new environment. The original design review explicitly requested resetting rigidity alongside the environment change.

layout_of already does this when it changes environments itself, but here it receives an already-Codegen environment, so that reset is skipped. The patch uses the same reset-then-normalize pattern as rustc's MIR mode-transition pass.

[CommanderStorm]

Ah, makes sense.

[jdonszelmann]

This seems correct to me. Only thing I'm afraid of is that more of clippy may be using the wrong typing mode w.r.t. the new trait solver. Lemme do a quick investigation. Otherwise if I were a clippy maintainer

[jdonszelmann]

is_uninit_value_valid_for_ty_fallback should probably also use codegen (it calls into layout_of right after), that's the only other example I could find

[tamird]

@jdonszelmann

is_uninit_value_valid_for_ty_fallback should probably also use codegen

I checked that path: its local PostAnalysis environment is used only to normalize field types. Recursive checks return to cx.layout_of with the original LateContext environment, so layout_of still performs its own mode transition and rigidity reset. Changing the fallback's local environment to Codegen alone wouldn't change those layout queries' mode.

The existing uninit_assumed_init and uninit_vec fixtures also complete under both solvers with matching warnings, kept nonfatal so delayed ICEs remain visible. I haven't found a reason to change that helper in this PR.

CI is green. If you're happy with the current patch, could you submit an approving GitHub review? CommanderStorm has approved; Clippy needs two community approvals before assigning a maintainer.

[jdonszelmann]

approved officially, after my previous comment :)

View changes since this review

[rustbot]

r? @dswij

rustbot has assigned @dswij for the project review.
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: 9 candidates
• 9 candidates expanded to 9 candidates
• Random selection from Jarcho, Manishearth, blyxyas, dswij, llogiq