Skip to content

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

Closed

Description

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

A-diagnosticsArea: Messages for errors, warnings, and lintsA-lintArea: Lints (warnings about flaws in source code) such as unused_mut.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions