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.

[nham]

This is still an issue as of:

rustc 1.1.0-nightly (da623844a 2015-04-25) (built 2015-04-26)

The error with glob imports is:

test_6477.rs:8:10: 8:13 error: use of undeclared type name `Foo`
test_6477.rs:8      x : Foo
                        ^~~
error: aborting due to previous error

Without is:

test_6477.rs:6:8: 6:16 error: type `Foo` is private
test_6477.rs:6    use foo::Foo;
                      ^~~~~~~~
error: aborting due to previous error

[pmarcelll]

I seems to be fixed:

error[E0412]: type name `Foo` is undefined or not in scope
 --> <anon>:8:10
  |
8 |      x : Foo
  |          ^^^ undefined or not in scope
  |
  = help: you can import it into scope: `use foo::Foo;`.

error: aborting due to previous error

[Mark-Simulacrum]

This is still not fixed, and indeed we now suggest to import Foo into scope -- even though this is impossible!

[Mark-Simulacrum]

E-needstest.

error[E0603]: struct `Foo` is private
 --> test.rs:6:8
  |
6 |    use foo::Foo;
  |        ^^^^^^^^

error: aborting due to previous error(s)

[Mark-Simulacrum]

gar, no, that was the wrong code sample..

[steveklabnik]

Today:

error[E0412]: cannot find type `Foo` in this scope
 --> .\foo.rs:8:10
  |
8 |      x : Foo
  |          ^^^ not found in this scope
help: possible candidate is found in another module, you can import it into scope
  |
6 |    use foo::Foo;
  |

Closing!