glob imports ignore private items

[nrc]

This is a bug if the importing module should be able to see the private items. E.g.,

struct Foo;

mod sub {
    import super::*;

    type Bar = Foo; // Error: use of undeclared type name Foo
}

I think there is a backwards compatibility hazard here, because if there is already an item called Foo in sub then we currently get no error, but we ought to get a name clash (unless we allow shadowing in this case).

triage: I-nominated

[alexcrichton]

This is currently intentional, there is specific code in resolve to reject any imports of private items. The reason for this is that if an import itself is considered a private item the semantics get really weird very quickly.

For example, all modules import the prelude, so can I import Option from any module? (yes I'll get an error, but those seem like unusual semantics). I believe this is also done to assuage the implementation of cyclically importing everything from a module to another, although I'm less sure about this.

[nrc]

That seems reasonable in general, but I think the rule ought to be that globs only import accessible items, rather than public items, so that if a module imports a glob and has access to a private item it is still imported. I kind of see the argument for weirdness - but nothing that doesn't apply to pub use (I think).

Since there are no cycles in the 'can access private member' graph, it doesn't seem like it should make a difference wrt cyclicity.

[pnkfelix]

P-high, not 1.0.

[bltavares]

Updating the code on the example:

struct Foo;

mod sub {
    use super::*;

    type Bar = Foo; // Error: use of undeclared type name Foo
}

[brson]

@jseyfried Does #35894 fix this?

[jseyfried]

@brson Yeah, once #![feature(item_like_imports)] is stable, that is.

[brson]

Depends on #35120.