Fix : Handle inconsistent resolution gracefully

[Delta17920]

This PR fixes an Internal Compiler Error (ICE) that occurs when a macro-expanded extern crate shadows a name passed with --extern.

The Issue

When extern crate std as core; is expanded from a macro while core is already imported (e.g. via use core; or use crate::*;), the resolver ends up in an inconsistent state where the initial_res differs from the final resolution res. Previously, this triggered a span_bug! panic in finalize_import.

The Fix

The resolver already correctly identifies and reports the shadowing error (macro-expanded extern crate items cannot shadow names passed with --extern).

This PR modifies finalize_import to check if any errors have already been reported (this.dcx().has_errors()). If an error exists, we suppress the panic, assuming the inconsistency is a side-effect of the invalid code. As a fallback safety measure, span_bug! was replaced with span_delayed_bug to ensure we don't crash if the shadowing error were to be suppressed in the future.

Test

Added regression test: tests/ui/resolve/ice-inconsistent-resolution-149821.rs
Fixes #149821

[rustbot]

r? @mati865

rustbot has assigned @mati865.
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

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 6a9cd26

[Kivooeo]

Closing this PR per our policy rust-lang/compiler-team#893.

First of all, it suppresses an ICE instead of fixing the root cause & checking has_errors() can potentially hide legitimate compiler bugs

And second less important it will create a burden on reviewers, because it would require deep analysis of resolver internals to verify correctness

ICEs in Rust must be fixed, not suppressed. A proper fix requires understanding why the resolver gets inconsistent, not just masking the symptom.

[Kivooeo]

upd: this is answer to their deleted comment

Sorry, but I don't know what should you do next, if you know a lot of how resolver works - then, maybe, it would be correct for you to do a deep dive and try to find original problem in resolver, not just replace span_bug with span_delayed_bug

The only thing I know for sure for now is that the current fix is not correct, and I don't have time to do investigation of real error for you, and, more important I don't want to our reviewers do this work and spend their time for this

Don't take it close to your heart, if I see that author spend their time to solve the issue and understand the root problem, then I'd love to do a review myself even though I don't know much about resolver, I'd love to spend my time for understanding fix and problem to make a good review the same way as author put their time and effort to land a good fix, but I don't want to do this dive when I see that author is not understand the code or not put the effort into the fix, I'm against fix just for fix in this case, this shall be fixed with a proper solution

[Delta17920]

I opened a different pr with the root cause fix rather than just masking

[Delta17920]

@Kivooeo i understand your review it's my fault I took a completely wrong approach. It's my third pr for this repo so I am getting used to it sorry for wasting your time