ICE when use-ing enum variant after glob-importing same-named enum

[oberien]

playpen

Reproduction code:

mod foo {
    pub enum Foo {
        Foo(i32),
    }
}
use foo::*;
use Foo::Foo;

thread 'rustc' panicked at 'assertion failed: directive.imported_module.get().is_none()', src/librustc_resolve/resolve_imports.rs:943:21
note: rustc 1.36.0 (a53f9df32 2019-07-03) running on x86_64-unknown-linux-gnu
note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib
note: some of the compiler flags provided by cargo are hidden

If I re-export pub use Foo::* in the module, it works as expected, having enum Foo in the type-namespace and variant Foo in the value-namespace (playpen).

[nikomatsakis]

Compiler team check-in:

I'm marking this as P-medium for now as it is not classified as a regression, although it seems like a fairly major problem. @petrochenkov appears to be on it, though.

[nikomatsakis]

Feel free to add the I-nominated label if you think it should be P-high

[estebank]

The assertion was added late last year.

@petrochenkov could you take a look at this to see if it is valid for the invariant being checked not to hold in this case? If I comment out the assert the output is reasonable:

error[E0432]: unresolved import `Foo`
 --> file7.rs:8:5
  |
8 | use Foo::Foo;
  |     ^^^ `Foo` is a variant, not a module

warning: unused import: `foo::*`
 --> file7.rs:7:5
  |
7 | use foo::*;
  |     ^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error: aborting due to 2 previous errors

Some errors have detailed explanations: E0432, E0601.
For more information about an error, try `rustc --explain E0432`.

[petrochenkov]

I'll see what happens (that's why I self-assigned).
The assert is there to catch the cases that resolve logic assumes to be impossible.
It may work ok if the assert is removed, but it may also mean some deeper issues, this needs a more detailed look.

[oberien]

The above error message without the assert looks a lot like #62768 and #62769.

[petrochenkov]

but it may also mean some deeper issues

...which was exactly the case here!
Thank you for reporting.

Fixed in #70236.