The compiler should report publicly exported type names if possible

[pcwalton]

If a private type is reexported at some public location, the Rust compiler will report the private location when referring to the type. It'd be more helpful if the compiler reported the public alias for it.

This was reported by Coda Hale on Twitter.

---

Update by pnkfelix: here is a standalone bit of code illustrating the problem. (play):

mod a {
    mod m { pub struct PrivateName; }
    pub use m::PrivateName as PublicName;
}

fn main() {
    // a::m::PrivateName; // would error, "module `m` is private"
    a::PublicName;
    a::PublicName.clone();
}

As of nightly 2019-06-17, this issues the diagnostic:

> error[E0599]: no method named `clone` found for type `a::m::PrivateName` [...]
                                                        ^^^^^^^^^^^^^^^^^
                                                                 |
             (author of `fn main` wants to see `a::PublicName` here)

[steveklabnik]

This happens a lot with core/std.

[steveklabnik]

Triage: it seems like a private type can no longer be exported as a public type at all

pub mod A {
    struct Foo;
    pub use A::Foo as Bar;
}

fn main() {
    let b = A::Bar;
}

gives

hello.rs:5:13: 5:26 error: `Foo` is private, and cannot be reexported [E0364]
hello.rs:5     pub use A::Foo as Bar;
                       ^~~~~~~~~~~~~
hello.rs:5:13: 5:26 help: run `rustc --explain E0364` to see a detailed explanation
hello.rs:5:13: 5:26 note: consider marking `Foo` as `pub` in the imported module
hello.rs:5     pub use A::Foo as Bar;
                       ^~~~~~~~~~~~~

So I believe this is effectively fixed? My core/std comment is more about reexports where both are public:

pub mod A {
    pub struct Foo;
    pub use A::Foo as Bar;
}

fn main() {
    let b: i32 = A::Bar;
}

which gives

hello.rs:9:18: 9:24 error: mismatched types:
 expected `i32`,
    found `A::Foo`
(expected i32,
    found struct `A::Foo`) [E0308]
hello.rs:9     let b: i32 = A::Bar;
                            ^~~~~~
hello.rs:9:18: 9:24 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error

which is covered by another ticket whose number escapes me.

[petrochenkov]

The issue is relevant to "unnameable" pub types which are still allowed.

mod m {
    pub struct PrivateName;
}

pub use m::PrivateName as PublicName.

m::PrivateName is still used in error messages, while it's preferable to use PublicName.

[torkleyy]

It also reports names which don't exist:

Consider this library:

// lib.rs of crate foo

mod a {
    pub trait Foo {}
}

pub use a::Foo as Afoo;

pub fn foo<T: Afoo>() {}

And some binary crate using it:

extern crate foo;

use foo::foo;

fn main() {
    foo::<()>(); // Afoo is not implemented for `()`
}

The error message is:

error[E0277]: the trait bound `(): foo::Foo` is not satisfied
 --> src/main.rs:6:5
  |
6 |     foo::<()>();
  |     ^^^^^^^^^ the trait `foo::Foo` is not implemented for `()`
  |
  = note: required by `foo::foo`

So it does not report the private name but a name that does not exist.

[leoyvens]

Notes from my attempt at solving this:

• The module_exports query is helpful as it returns a list of Exports in a module, the ident field is the name or rename.
• Modifying item_path.rs directly is problematic because it is used in many different parts of the compiler. It's unclear where exactly the logic should go.

Also linking relevant internal's thread.

[Manishearth]

Do we need an RFC for this? My impression is that this is purely an implementation thing, and doesn't need to go through the actual RFC process. We could do that if we wanted to add configurability (It's not clear to me that that is necessary!), but I think the right way to go would be to implement it behind an env var first and then see what the compiler team thinks.

Like, this is something most folks working on the compiler have wanted for ages, the question is just about how to implement it, which doesn't need an RFC.

[da-x]

@Manishearth, previously, I was requested an RFC over a smaller change - #49898, and submitted it. This one has even a larger user impact, so it only made sense to go through some RFC process, even if most of the work is implementation.

[Manishearth]

This one has a larger user impact, but a smaller design one: that one was changing the actual UI layout which has been very carefully designed. Full paths in diagnostics, on the other hand, are not an intentional part of the design, and everyone has wanted to fix it forever. I'd start experimenting first and make an rfc if the compiler team asks you to, not the other way around. (I'll point out that @estebank is also experimenting with this without making an RFC and is on the compiler team)

…

On Mon, Nov 11, 2019, 4:09 AM Dan Aloni ***@***.***> wrote: @Manishearth <https://github.com/Manishearth>, previously, I was requested an RFC over a smaller change - #49898 <#49898>, and submitted it <rust-lang/rfcs#2777>. This one has even a larger user impact, so it only made sense to go through some RFC process, even if most of the work is implementation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21934?email_source=notifications&email_token=AAMK6SHGXQUU7542S4EGI7DQTFDRBA5CNFSM4A3OUJW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDWT45Q#issuecomment-552418934>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMK6SDUY7MFNL6TITBUG5TQTFDRBANCNFSM4A3OUJWQ> .

[pnkfelix]

Like @Manishearth , I do not think an RFC is required here.

It might be nice to have a T-compiler design meeting for it (but even that might be overkill here; at the very least it would require synchronous participation from the proposer, which again may not be necessary here.)

[da-x]

It's ok, as I prefer working on code than on RFCs anyway :) I can try fitting the draft implementation to whatever is decided there.

…

On Thu, Nov 14, 2019, 15:22 Felix S Klock II ***@***.***> wrote: Like @Manishearth <https://github.com/Manishearth> , I do not think an RFC is required here. It *might* be nice to have a T-compiler design meeting <https://rust-lang.github.io/compiler-team/about/steering-meeting/> for it (but even that might be overkill here; at the very least it would require synchronous participation from the proposer, which again may not be necessary here.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21934?email_source=notifications&email_token=AACON6IFXOX7JF6O2WO53CDQTVGKFA5CNFSM4A3OUJW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEBZ2RA#issuecomment-553884996>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACON6J2OTV5OQEK5SZXQVTQTVGKFANCNFSM4A3OUJWQ> .

[pnkfelix]

triage: I am downgrading this to P-medium. We have too large of a backlog of high priority items and this one does not warrant being visited every week at triage.

[eddyb]

There was an idea I noted down in a pull request: #70911 (comment).
In short, it involves shortening paths to a name that is unique to them (e.g. if there's only one Vec ever), and potentially doing some prelude-specific logic (but not necessarily, I guess?).

I don't know if #73996 is based on that comment or not, but it's really cool that it's happening, and I'm sorry I didn't leave a comment here when I suggested the idea in the str librarification PR.

[camelid]

Rustdoc would benefit from work on this; see https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/To.20alias.20or.20not.20to.20alias.