Reject linked dylib EII default overrides

[qaijuang]

This PR rejects explicit EII implementations that would override a default implementation already selected through a linked dylib.

The check is intentionally split:

• rustc_passes keeps the early, format-independent checks for missing impls and duplicate explicit impls.
• rustc_codegen_ssa checks the default-vs-explicit conflict during linking, using the dependency formats selected for the final artifact.

Fixes #156320.

[rustbot]

r? @mejrs

rustbot has assigned @mejrs.
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 73 candidates
• Random selection from 19 candidates

[qaijuang]

cc @bjorn3

[mejrs]

r? @jdonszelmann (or @bjorn3 perhaps)

[rustbot]

jdonszelmann is currently at their maximum review capacity.
They may take a while to respond.

[bjorn3]

Thinking about this a bit more, I'm wondering if maybe check_externally_implementable_items should be done only at link time? tcx.used_crate_source() may report that only a dylib exists even when at link time an rlib will be available and linked in. And tcx.dependency_formats() will report everything as NotLinked inside rlibs and would ideally only be called during the link step for -Zno-link/-Zlink-only to work (it is currently broken because dependency_formats is called during codegen. i've been working on moving this call to the link step for the past several months). On the other hand for all cases that the check caught before this PR, doing it before linking is fine. So splitting it into separate checks for duplicate explicit impls and for a default impl conflicting with an explicit impl would preserve early error messages (especially for cargo check) What do you think @jdonszelmann?

[qaijuang]

Thinking about this a bit more, I'm wondering if maybe check_externally_implementable_items should be done only at link time? tcx.used_crate_source() may report that only a dylib exists even when at link time an rlib will be available and linked in. And tcx.dependency_formats() will report everything as NotLinked inside rlibs and would ideally only be called during the link step for -Zno-link/-Zlink-only to work (it is currently broken because dependency_formats is called during codegen.

Nice catch @bjorn3

So splitting it into separate checks for duplicate explicit impls and for a default impl conflicting with an explicit impl would preserve early error messages (especially for cargo check)

right? seems like the next best move

[qaijuang]

@bjorn3 I'm done with the split, what do you think?

[jdonszelmann]

@bjorn3 that approach seems reasonable to me

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[qaijuang]

somehow, this got removed from main, making tests/ui/eii/default/call_impl.rs regress, which is why I did the rebase.

View changes since this review

[qaijuang]

this

View changes since the review

[qaijuang]

and this

View changes since the review