ast_lowering: fix ICE in fn_delegation with complex generics#153443
ast_lowering: fix ICE in fn_delegation with complex generics#153443Delta17920 wants to merge 1 commit intorust-lang:mainfrom
Conversation
|
r? @nnethercote rustbot has assigned @nnethercote. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Seems reasonable to me but I will defer to someone who actually knows about lowering, in case I'm overlooking something. r? @fmease |
Just curious, why the following won't make ICE if we will lower generic parameters multiple times for delegation items🤔: |
|
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
In this case |
|
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? |
|
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. |
the unstable
fn_delegationfeature duplicates ast nodes, causing the lowerer to visit the same generic parameters multiple times and triggering an ice on a duplicatedef_idassertion.in
compiler/rustc_ast_lowering/src/item.rs, i changed the duplicatedef_idpanic to a silentcontinue. delegation inherently reuses the same ast nodes, so the strict one-to-one mapping assumption inlctx.childrendoesn't work here. skipping already-registereddef_ids safely unblocks lowering and lets actual user errors (likee0428) get caught normally by the type-checker later.in
compiler/rustc_ast_lowering/src/delegation/generics.rs, i deduplicated the generic parameters using anfxhashset. just fixingitem.rsprevents the immediate crash, but it would leave us with malformed hir signatures containing duplicate lifetimes. deduplicating bydef_idensures 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