-
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
Shorter type-names on type errors #50310
Comments
cc #21934 |
As I said in #58088 , I would suggest banning all path names from types in error messages and to include use statements in the error message to avoid ambiguity and to allow the user to verify the path if needed. It's exponentially useful when the same types are referred to more than once, which is quite common. The problem seems also especially bad with generics, which are common in rust as well. |
Sorry, but I'm not the same oppnion as you are. Let's suggest you have to structs called I don't think that removing paths from the error is a good solution! |
@hellow554 That's why I'm suggesting use statements to be included in the error messages, with full, unambiguous paths. I don't know, but I feel that unfortunately the screenshot I posted speaks louder than a thousand words, and I mean literally speaking... that can't be a desirable UX, no? Maybe we can agree on that to start? I find myself writing post processing scripts to make any sense out of the error messages by removing all the paths. To make a more concrete proposition, it might look something like:
|
@najamelan Error messages like that would suggest that it is idiomatic to Furthermore there could be cases where multiple identical names show up in the same error message. (e.g. |
That's a non-issue, the compiler should just simplify the paths as much as possible without introducing ambiguities. For example:
Would become:
There's not much difference here, but it would help considerably in cases like this:
And errors like this are rather common while using futures. |
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.
Closed in #73996 |
Type errors (
E0308
) are a common occurrence in rustc. Whenever I confuse myself about the type of something, I tend to assign it to somex: i32
and let the compiler blame me with a hint about what typex
actually is. Thenote
-section attached to the error message contains the fully qualified type name, which is technically as correct as one can get. However, this also produces a lot of clutter, because the type-name that I'm actually interested in is much more concise if types in scope of the offending statement are taken into account. For example:The
note
saysAgain, while this is as precise as it can get, most of this is just clutter, especially with deeply nested types: I know that
HashMap
is fromstd::collections
, I also know thatOption
refers tostd::option::Option
. If I had some other type shadowing those names, I'd be aware of it. Reading the note, I have to demangle the type-name towhich is what the type-name would be if I wanted to write it down, considering all the
use
s.Could we at least have an option (or an extra note) for
E0308
where the type-names get uncluttered by considering the types that are in scope for the offending statement? This would reduce the intellectual burden and may enable one to just copy&paste the type-name from the note.The text was updated successfully, but these errors were encountered: