Better error messages for unresolved imports due to privateness when using `use foo::*`

[kud1ing]

In #6443 @cmr made rustc for the following code

mod foo {
   struct Foo;
}

mod bar {
   use foo::Foo;
   struct Bar {
     x : Foo
   }
}

explain error: unresolved import: found "Foo" in "foo" but it is private.

When the module members however are imported using * this way:

mod foo {
   struct Foo;
}

mod bar {
   use foo::*;
   struct Bar {
     x : Foo
   }
}

rustc only says error: use of undeclared type name "Foo".

I think the most prominent use case could be use super::* in unit-test modules.

[emberian]

This is going to need some deeper changes, I think. Might be a while, I'm not familiar with this part of rustc.

[kud1ing]

No worries.

[emberian]

I think the way to implement this is to add, at https://github.com/mozilla/rust/blob/incoming/src/librustc/middle/resolve.rs#L4035, iteration over all external types and checking if they exist or are private. Not really sure how to do this or if it's possible, but I think going through a similar process as (or maybe even just calling) resolve_definition_of_name_in_module with xray could do the trick.

[emberian]

(that is, check if they have the same name)

[Aatch]

A quick study of the code, suggests to me that doing this: (roughly)

let orig_xray = self.xray_context;
self.xray_context = Xray;
match self.resolve_path(path, TypeNS, true, visitor) {
    Some(def) => {
        // Found it, but it's private
    }
    None => {
        // Straight-up doesn't exist
    }
}
let self.xray_context = orig_xray;

Which is similar to your idea. I'm not too familiar with the resolver though, so there may be a better way.

[emberian]

This doesn't work, unfortunately. Not familiar enough with the resolver to figure out why. The log shows:

rust: ~"(resolving item) resolving Bar"
rust: ~"(resolving item in lexical scope) resolving `Foo` in namespace TypeNS in `bar`"
rust: ~"(resolving item in lexical scope) found import resolution, but not in namespace TypeNS"
rust: ~"\"(resolving item in lexical scope) unresolved module: not searching through module parents\""

though.

[emberian]

Triage bump. I've made no progress with this.

[kud1ing]

I tend to close this, because of the glob feature gate and the chance of glob imports going away.

[Aatch]

I opened #11825 to cover glob imports going away, so this is contingent on that issue.