Skip to content

ast_lowering: fix ICE in fn_delegation with complex generics#153443

Open
Delta17920 wants to merge 1 commit intorust-lang:mainfrom
Delta17920:fix-fn-delegation-ice
Open

ast_lowering: fix ICE in fn_delegation with complex generics#153443
Delta17920 wants to merge 1 commit intorust-lang:mainfrom
Delta17920:fix-fn-delegation-ice

Conversation

@Delta17920
Copy link
Contributor

@Delta17920 Delta17920 commented Mar 5, 2026

the unstable fn_delegation feature duplicates ast nodes, causing the lowerer to visit the same generic parameters multiple times and triggering an ice on a duplicate def_id assertion.

in compiler/rustc_ast_lowering/src/item.rs, i changed the duplicate def_id panic to a silent continue. delegation inherently reuses the same ast nodes, so the strict one-to-one mapping assumption in lctx.children doesn't work here. skipping already-registered def_ids safely unblocks lowering and lets actual user errors (like e0428) get caught normally by the type-checker later.

in compiler/rustc_ast_lowering/src/delegation/generics.rs, i deduplicated the generic parameters using an fxhashset. just fixing item.rs prevents the immediate crash, but it would leave us with malformed hir signatures containing duplicate lifetimes. deduplicating by def_id ensures the final hir is structurally valid and prevents cascading crashes in later compiler queries.

feedback on whether this is the preferred way to handle the duplication during lowering is welcome.
fixes #153433

@rustbot 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 Mar 5, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 5, 2026

r? @nnethercote

rustbot has assigned @nnethercote.
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 16 candidates

@nnethercote
Copy link
Contributor

Seems reasonable to me but I will defer to someone who actually knows about lowering, in case I'm overlooking something.

r? @fmease

@rustbot rustbot assigned fmease and unassigned nnethercote Mar 6, 2026
@mu001999
Copy link
Contributor

mu001999 commented Mar 6, 2026

the unstable fn_delegation feature duplicates ast nodes, causing the lowerer to visit the same generic parameters multiple times and triggering an ice on a duplicate def_id assertion.

Just curious, why the following won't make ICE if we will lower generic parameters multiple times for delegation items🤔:

#![feature(fn_delegation)]
#![allow(incomplete_features)]

fn main() {
    trait Foo {}
    fn foo<N: for<'a> Foo>() {}
    reuse foo;
}

@aerooneqq
Copy link
Contributor

aerooneqq commented Mar 6, 2026

The problem here is that in current implementation we copy const type and eventually lower it twice. I don't think that the removal of the duplicated copy assertion is a correct way to fix this problem, this assertion did it job and highlighted the real issue. This issue should be solved by a proper const type propagation from HIR to TY level (i.e., adding stubs in hir::Ty in InferDelegation variant).

Just curious, why the following won't make ICE if we will lower generic parameters multiple times for delegation items🤔:

In this case N is a generic type parameter and for<'a> Foo is a predicate, predicates are not created at AST -> HIR lowering stage, they are inherited later.

@Delta17920
Copy link
Contributor Author

thanks @aerooneqq for the explanation! that makes total sense.

however, i feel like implementing proper const-type propagation across the hir/ty level is a bit too big in scope for this single pr.

would it make sense to leave this as a temporary stopgap to fix the ice for now, or is it better to just close this and track the broader architectural fix in a separate issue?

@aerooneqq
Copy link
Contributor

I think the second option is preferable, as there is at least one more ICE (#153499) that relates to const types. Now we are researching a better way to work with generics and delegation code generation at all, If this prototype will be merged then it will be much easier to fix those ICEs, so I would wait until we finish with this research PR.

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

Labels

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ICE]: duplicate copy of DefId in lctx.children

6 participants