Tracking Issue for `ambiguous_glob_imports` lint

[bvanjoi]

This is a tracking issue for the "ambiguous_glob_imports", a lint that follows the breaking change policy.

Problem

The name resolution algorithm in rustc does not update bindings recursively when the (Module, Key) already has a binding. This can result in a situation where a glob binding should be marked as ambiguous but it is not, potentially causing code that should fail to compile to pass instead.

For example(#112713):

pub fn foo() -> u32 {
    use sub::*;
    C
}

mod sub {
    mod mod1 { pub const C: u32 = 1; }
    mod mod2 { pub const C: u32 = 2; }

    pub use mod1::*;
    pub use mod2::*;
}

The C in foo function was referred to (Mod(root), Key(C)), where it should have an ambiguous binding but actually not due to the stop the update process early.

Here are additional details regarding the update process:

-	importer	resolve_glob_import
0	use sub::*	nothing was defined
1	use mod1::*	1. (root::sub, C) -> root::sub::mod1::C without ambiguity; 2. (root, C) -> root::sub::mod1::C without ambiguity.
2	use mod2::*	1. (root::sub, C) -> root::sub::mod1::C with ambiguity; 2. It had been stop update the binding of (root, C) due to (root, C) already has a binding.

Solve

We have relaxed the condition for update process and now treat the updated ambiguous error as a warning instead of an error. We use the ambigous_glob_imports lint for back compatibility.

Steps

• Implement: fix(resolve): update the ambiguity glob binding as warning recursively #113099
• Make it as an error

[tmiasko]

The future incompatibility report is not enabled for dependencies (FutureReleaseError vs FutureReleaseErrorReportNow). Is that intentional?

[bvanjoi]

The future incompatibility report is not enabled for dependencies (FutureReleaseError vs FutureReleaseErrorReportNow). Is that intentional?

Yes, it is indeed another matter: #36837

[LorrensP-2158466]

Hi, I'd like to work on converting this lint to an error.

I'm one of the GSoC contributors this year, working on parallel macro expansion (see relevant Zulip thread). When trying to understand import resolution I asked a question to petrochenkov what these warn_ambiguity fields and such were for, and he explained it to me.

He said that if I was open to it, I could try to make some progress on this. However, I have no experience with converting warnings to errors, so some guidance is appreciated!

[petrochenkov]

In lint declaration (declare_lint!) for AMBIGUOUS_GLOB_IMPORTS Warn needs to be changed to Deny and report_in_deps: true needs to be added to FutureIncompatibleInfo { .. }.
All affected tests will also need to be updated.

After a PR with those changes is made we can run crater on it.

UPD: there are some docs for the process in https://rustc-dev-guide.rust-lang.org/bug-fix-procedure.html

[LorrensP-2158466]

No changes to the code itself? Even something like warn_ambiguity to err_ambiguity.

[bvanjoi]

No changes to the code itself?

In my view:

• Firstly, Replace Warn with Deny in the lint declaration, and run crater to assess the impact on ecosystem compatibility.
• ​If compatibility is acceptable, then proceed with removing all warn_ambiguity logic from the resolver.