-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The compiler should report publicly exported type names if possible #21934
Comments
This happens a lot with |
Triage: it seems like a private type can no longer be exported as a public type at all
gives
So I believe this is effectively fixed? My
which gives
which is covered by another ticket whose number escapes me. |
The issue is relevant to "unnameable"
|
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:
So it does not report the private name but a name that does not exist. |
Notes from my attempt at solving this:
Also linking relevant internal's thread. |
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. |
@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. |
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>
.
|
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.) |
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>
.
|
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. |
There was an idea I noted down in a pull request: #70911 (comment). 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 |
diagnostics: shorten paths of unique symbols This is a step towards implementing a fix for rust-lang#50310, and continuation of the discussion in [Pre-RFC: Nicer Types In Diagnostics - compiler - Rust Internals](https://internals.rust-lang.org/t/pre-rfc-nicer-types-in-diagnostics/11139). Impressed upon me from previous discussion in rust-lang#21934 that an RFC for this is not needed, and I should just come up with code. The recent improvements to `use` suggestions that I've contributed have given rise to this implementation. Contrary to previous suggestions, it's rather simple logic, and I believe it only reduces the amount of cognitive load that a developer would need when reading type errors. ----- If a symbol name can only be imported from one place, and as long as it was not glob-imported anywhere in the current crate, we can trim its printed path to the last component. This has wide implications on error messages with types, for example, shortening `std::vec::Vec` to just `Vec`, as long as there is no other `Vec` importable from anywhere.
Rustdoc would benefit from work on this; see https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/To.20alias.20or.20not.20to.20alias. |
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):
As of nightly 2019-06-17, this issues the diagnostic:
The text was updated successfully, but these errors were encountered: