Rust: #[non_exhaustive] enums allow glob imports for variants

[bash]

I think wildcard imports for enum variants of enums that have the #[non_exhaustive] attribute set should be disallowed, because adding a new variant on the enum could break downstream crates.

Given the following two crates:

crate-a:

#![feature(non_exhaustive)]

#[non_exhaustive]
pub enum A {
    Foo,
    Bar,
}

crate-b:

use crate_a::A::*;
use self::B::*;

enum B {
    Baz,
}

fn main() {
    let _ = Baz;
}

Adding a new variant Baz to enum A breaks compilation for crate-b with the following error:

error[E0659]: `Baz` is ambiguous (glob import vs glob import in the same module)
 --> crate-b/src/main.rs:9:13
  |
9 |     let _ = Baz;
  |             ^^^ ambiguous name
  |
note: `Baz` could refer to the unit variant imported here

---

Output from rustc --version:

rustc 1.35.0-nightly (88f755f8a 2019-03-07)

[petrochenkov]

That's not a problem specific to non-exhaustive enums, adding public items into any public module (mod) can cause "glob vs glob" ambiguities downstream.
That's generally considered an acceptable breakage, because otherwise all APIs would be frozen at the moment of their creation.

[petrochenkov]

I think, clippy could consider adding a lint for the non-exhaustive enum case specifically, if you file an issue in https://github.com/rust-lang/rust-clippy.

[petrochenkov]

It could be even better to lint multiple glob imports in a single module if at least one of them refers to an "open" entity - module or non-exhaustive enum.

[bash]

You're absolutely right, I totally forgot about the breaking change nature of glob imports. 😄

There's already a clippy lint that warns about glob imports of enum variants: https://rust-lang.github.io/rust-clippy/master/index.html#enum_glob_use, I don't think that another lint is necessary?

[jonas-schievink]

Closing in favor of a Clippy lint/issue (assuming one is needed, but that might not even be the case here)