"Foo is ambiguous" only when deriving Debug

[oberien]

playpen

This may be related to #62768.

Given this code:

pub use Foo::*;
#[derive(Debug)]
pub enum Foo {
    Foo(i32),
}

The compiler errors, saying that the Foo in use Foo::* may refer both to the enum (type-namespace) Foo and the yet-to-be-imported variant (value-namespace) Foo::Foo:

error[E0659]: `Foo` is ambiguous (glob import vs macro-expanded name in the same module during import/macro resolution)
 --> src/lib.rs:1:9
  |
1 | pub use Foo::*;
  |         ^^^ ambiguous name
  |
note: `Foo` could refer to the enum defined here
 --> src/lib.rs:3:1
  |
3 | / pub enum Foo {
4 | |     Foo(i32),
5 | | }
  | |_^
note: `Foo` could also refer to the variant imported here
 --> src/lib.rs:1:9
  |
1 | pub use Foo::*;
  |         ^^^^^^
  = help: consider adding an explicit import of `Foo` to disambiguate

However, if I remove the #[derive(Debug)], then the code compiles just fine as expected (playpen).

[oberien]

When I expand the code using --pretty=expanded and just copy-paste the expanded code, which doesn't contain the #[derive(Debug)] anymore, the code compiles just fine (playpen).

[estebank]

cc @petrochenkov

[petrochenkov]

First, variants exist in type namespace (and their constructors exist in value namespace).
Second, macro-expanded names have some extra restriction to avoid paradoxes, so --pretty=expanded code compiling doesn't necessarily mean the non-expanded compiling successfully as well (see the error message, it says something about macro-expanded names specifically).

Beside that, it's rather a conservative error than an outright bug.
Yeah, we should ideally do some causal tracking for globs use foo::something::* /*foo*/; and know that the suffix foo "does not exist" during resolution of the prefix foo, but we do not do it right now.

(We actually do it for single imports though, otherwise use my_crate; would cause an infinite loop.
This is done by blacklisting the "output" my_crate when resolving the "input" my_crate, but should probably be done through introducing a single "inference variable" for both, which would work for globs as well.)

[steveklabnik]

Triage: this error is a bit more descriptive today:

error[E0659]: `Foo` is ambiguous (glob import vs macro-expanded name in the same module during import/macro resolution)
 --> src/lib.rs:1:9
  |
1 | pub use Foo::*;
  |         ^^^ ambiguous name
  |
note: `Foo` could refer to the enum defined here
 --> src/lib.rs:3:1
  |
3 | / pub enum Foo {
4 | |     Foo(i32),
5 | | }
  | |_^
note: `Foo` could also refer to the variant imported here
 --> src/lib.rs:1:9
  |
1 | pub use Foo::*;
  |         ^^^^^^
  = help: consider adding an explicit import of `Foo` to disambiguate