Consider adding a lint for ambiguous re-exports, since they are unusable

[obi1kenobi]

Code

pub mod a {
    pub struct Foo {}
}

pub mod b {
    // Some other unrelated stuff here,
    // for example:
    pub struct Bar {}
    
    // Later on,
    // the following struct is added:
    //
    // pub struct Foo {}
    //
    // Uncommenting the line above breaks
    // all downstream uses of `this_crate::Foo`:
    // - the name is ambiguous,
    // - ambiguous names only error if used,
    // - there's no lint or warning for this.
    //
    // Unless `this_crate` has tests that
    // *specifically* use `this_crate::Foo` itself,
    // the odds are excellent that this bug
    // only gets discovered after breaking downstream.
}

pub use a::*;
pub use b::*;

Current output

compiles without errors, warnings, or clippy lints

Desired output

pub use b::*;
        ^^^^ this includes b::Foo
note: re-exported Foo is ambiguous, since a::Foo is also re-exported
      this will cause an error when attempting to import Foo from this module

Rationale and extra context

It makes sense to defer ambiguous import errors until the ambiguous import is used. However, the same policy currently applies to ambiguous re-exports: they do not error at the time they are created, and instead error only when they are attempted to be used. But an ambiguous re-export is almost certainly unintentional and an error, as it is completely unusable.

Mistakes like in the example code above have excellent odds of being discovered only when they break downstream: there's currently no error, lint, or warning from any tool, and most crates don't write test that use the re-exported names of items so cargo test probably won't find the problem either.

A bit more discussion (including a playground link) here: https://hachyderm.io/@predrag/109786028398707576

Other cases

No response

Anything else?

I wasn't sure if this should be a rustc lint, a clippy lint, or something else. I decided to start here but I wouldn't mind moving this to the clippy issue tracker if that's the better place for this lint.

[jieyouxu]

Given something like

pub mod a {
    pub fn foo() {}
}

pub mod b {
    pub fn foo() {}
}

pub use a::*;
pub use b::*;

rustc doesn't complain. But if you change glob exports to specific exports, rustc does complain correctly:

pub mod a {
    pub fn foo() {}
}

pub mod b {
    pub fn foo() {}
}

pub use a::foo;
pub use b::foo;

outputs:

error[E0252]: the name `foo` is defined multiple times
  --> src/lib.rs:10:9
   |
9  | pub use a::foo;
   |         ------ previous import of the value `foo` here
10 | pub use b::foo;
   |         ^^^^^^ `foo` reimported here
   |
   = note: `foo` must be defined only once in the value namespace of this module
help: you can use `as` to change the binding name of the import
   |
10 | pub use b::foo as other_foo;
   |         ~~~~~~~~~~~~~~~~~~~

For more information about this error, try `rustc --explain E0252`.

Maybe we could just piggyback off of E0252 and fix its detection for glob exports.

[jieyouxu]

I think I found a fix for this, modulo the suggestion to fix it (haven't gotten to that part yet).

error[E0252]: the name `Foo` is defined multiple times
  --> issue-107563.rs:13:9
   |
12 | pub use a::*;
   |         ---- previous import of the type `Foo` here
13 | pub use b::*;
   |         ^^^^
   |         |
   |         `Foo` reimported here
   |         you can use `as` to change the binding name of the import
   |
   = note: `Foo` must be defined only once in the type namespace of this module

[jieyouxu]

Hmm my current attempt has a problem where

error[E0252]: the name `fmt` is defined multiple times
  --> library/core/src/ffi/mod.rs:14:5
   |
12 | use crate::fmt;
   |     ---------- previous import of the module `fmt` here
13 | use crate::marker::PhantomData;
14 | use crate::num::*;
   |     ^^^^^^^^^^^^^
   |     |
   |     `fmt` reimported here
   |     you can use `as` to change the binding name of the import
   |
   = note: `fmt` must be defined only once in the type namespace of this module

error[E0659]: `fmt` is ambiguous
   --> library/core/src/ffi/mod.rs:221:6
    |
221 | impl fmt::Debug for c_void {
    |      ^^^ ambiguous name
    |
    = note: ambiguous because of a conflict between a name from a glob import and a macro-expanded name in the same module during import or macro resolution

since crate::fmt has the name fmt and crate::num::fmt is imported too by crate::num::*... This doesn't seem ideal since I feel like the more-specific fmt import should override the glob import?

[jieyouxu]

@rustbot claim