Skip virtual dispatches when collecting default impl mono items

[peterphitran]

Fixes #158411. Fixes #114198.

With -Clink-dead-code, create_mono_items_for_default_impls resolves each inherited provided method of a trait impl. When the impl's self type normalizes to the trait's own object type (via a type alias or projection, which coherence accepts, see #57893), resolution picks the builtin object candidate and returns InstanceKind::Virtual, which was pushed as a mono item and ICEd in instance_mir. This skips Virtual instances there, as visit_instance_use already does on the lazy path. Nothing reachable is lost: calls on dyn Trait always go through the vtable. Rejecting these impls instead would break tests/ui/traits/object/ambiguity-vtable-segfault.rs. Reproduces on nightly without feature gates (impl Trait for <Ty as Owner>::Struct with Struct = dyn Trait).

Test plan (build-pass with -Clink-dead-code):

• Lazy type alias and associated type projection self types both compile: the two ways to reach the ICE.
• An overridden method in the same impl is still collected: the skip must not drop real items.
• dyn Trait + Send compiles: auto traits in the object type take the same path.
• tests/crashes/114198*.rs are removed since they now compile; their cases are in the new test.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @TaKO8Ki (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 21 candidates

[rustbot]

This PR changes a file inside tests/crashes. If a crash was fixed, please move into the corresponding ui subdir and add 'Fixes #' to the PR description to autoclose the issue upon merge.

[rust-bors]

☔ The latest upstream changes (presumably #159407) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[apiraino]

@rustbot reroll

[jieyouxu]

@rustbot reroll

[folkertdev]

r? oli-obk (or at least you might know someone specific that is able to review, instead of random chance)

[oli-obk]

Please state how and where an LLM was used in the process of creating this PR

[peterphitran]

@oli-obk

• Recreated and validated this issue myself watching for the crash, from there went back and forth with LLM evaluating root cause, blast radius, and iterating through possible fixes.
• Landed on this fix from the LLM to skip at the item collection list.
• From there had it implement and create the tests where I reviewed and then had the LLM create the pr.
• Had the LLM trace back into the history of where this issue came from
• Also I have noticed the new LLM policy announced which this PR predates so let me know if needed I can look to start fresh requesting to work with a mentor

Side note:

• Had the LLM run variant scenarios and found that crashing can occur when a trait has where Self: Sized default method it will return None and expect_resolve resulting in an ICE this is another issue coming from the same root cause as the current issue with -Clink-dead-code and dyn-self impl
• I asked it about just skiping both Virtual and None and then LLM said it was an option but also brought up another route where can return early from create_mono_items_for_default_impls when its the same or a parent trait and its arguments match dyn type since it is the built in object choice instead of impl

[oli-obk]

Since the PR change is rather trivial, and you predate the policy, I'll give it a shot, but if this results in you just running the LLM for me, then please just close the PR.

Why do we land in this situation, but not for impls that are directly on dyn Trait? Can we instead make it so that there is no difference when resolving method calls for dyn Trait impls compared to impls for type aliases/projections that normalize to dyn Trait?