Skip to content

rustc_monomorphize: Skip vtable alloc collection in the pre-optimisation MentionedItems mode#152462

Open
jakubadamw wants to merge 2 commits intorust-lang:mainfrom
jakubadamw:issue-141911
Open

rustc_monomorphize: Skip vtable alloc collection in the pre-optimisation MentionedItems mode#152462
jakubadamw wants to merge 2 commits intorust-lang:mainfrom
jakubadamw:issue-141911

Conversation

@jakubadamw
Copy link
Contributor

@jakubadamw jakubadamw commented Feb 11, 2026

When collecting mentioned items during monomorphization, the collect_alloc() routine was recursively walking vtable allocations, which could lead to infinite recursion if a vtable method's body contained a const embedding another vtable. We can skip the recursive walk when we're only gathering mentioned items. Vtable methods are only relevant during actual codegen, so this should be safe.

Closes #141911.

… mode

When collecting mentioned items during monomorphization, the routine was
recursively walking vtable allocations, which could lead to infinite
recursion if a vtable method's body contained a const embedding another vtable.
We can skip the recursive walk when we're only gathering mentioned items.
Vtable methods are only relevant during actual codegen, so this should be safe.
@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 Feb 11, 2026
@rustbot
Copy link
Collaborator

rustbot commented Feb 11, 2026

r? @fmease

rustbot has assigned @fmease.
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 66 candidates
  • Random selection from 13 candidates

@Mark-Simulacrum
Copy link
Member

Vtable methods are only relevant during actual codegen, so this should be safe.

Can you elaborate on "safe"? Are we reaching the mentioned items only brought in via vtables in some other way already? Can this change behavior of existing programs (e.g., make more things compile in check mode)?

@@ -0,0 +1,16 @@
//@ run-pass
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem resurfaces when compiling without optimizations -Zmir-opt-level=0. The motivation behind "mentioned" collection mode is to ensure consistency across optimization levels. In that sense the existing implementation is working as intended (putting aside the glaring issue of ICE itself).

@fmease fmease assigned Mark-Simulacrum and tmiasko and unassigned fmease Feb 11, 2026
@tmiasko
Copy link
Contributor

tmiasko commented Feb 11, 2026

ICE will be turned into an error in #152120. I don't think collection process needs any changes (except perhaps to improve the diagnostic to indicate a source location that gives rise to the error).

@jakubadamw
Copy link
Contributor Author

Can you elaborate on "safe"? Are we reaching the mentioned items only brought in via vtables in some other way already? Can this change behavior of existing programs (e.g., make more things compile in check mode)?

@Mark-Simulacrum, these are very helpful questions! You're right that this attempt may be preventing some invalid programs from being rejected, and I'll try to come up with a test case that demonstrates it.

@tmiasko, thank you for your feedback as well!

@tmiasko
Copy link
Contributor

tmiasko commented Feb 12, 2026

You're right that this attempt may be preventing some invalid programs from being rejected, and I'll try to come up with a test case that demonstrates it.

To be clear, the test case you have already included should fail to compile. This is because evaluating const { std::ptr::null::<VirtualWrapper<T>>() as *const dyn MyTrait }; for T = u8 requires constructing vtable for VirtualWrapper<u8> as MyTrait, which in turn requires constructing vtable for VirtualWrapper<VirtualWrapper<u8>> as MyTrait and so on.

The only issue is that this results in an ICE instead of an error.

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:failed to build vtable representation:SizeOverflow

5 participants