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