Improving error messages

[ekuber]

@GolDDranks

1. Using non-fully qualified path names where the types are unambiguous makes the messages a LOT cleaner.
2. Using types as used in the codebase makes it easier to connect the dots. That means that if an alias is being used, use that alias.

I completely agree. This request has appeared multiple times, rightfully so. #21934 keeps track of the discussion around this. I can't promise anything in the short term, but I've been ruminating about how to implement this in such a way that will work with incremental compilation (the internal state of the compiler would allow you to keep a separate per scope mapping for local names, but this would depend on NodeIds which, as I understand it, change on subsequent compilations, so it is not suitable to do this).

@GolDDranks

3. Sometimes the error messages write associated types “over-carefully” open: <Type as Trait>::AssocType, where there is no ambiguity, and Type::AssocType would do. (Often it demands the author to write <Type as Trait>::AssocType to be sure, but sometimes not, and those times it shouldn’t use the verbose form in the error messages.) Edit: actually, it might be even better to demand the author to write the fully qualified trait path like it often does, since the code is more resistant to breakages that way, but when printing errors, it has the luxury of unambiguating only where needed, so it could be a lot more relaxed and not unambiguate so much.

This should be possible to do now with little effort. I can't come up with any objection to this, so I will look into writing mentoring instructions for it when I create this ticket.

@GolDDranks

5. There should be better tooling for pretty-printing complex types, indented if needs to be. I’m not saying that should be the default, as it could be visually very distracting and take space, but it should be an option.

Currently there's some type elision going on when possible (think Some(3) != Ok(3) => Option<_> != Result<_, _>, but there's plenty of improvement that can be done in this front. Some relevant tickets with plenty of background about some different alternatives: #21025 , #39906 , #43943 and #40186 .

@jsgf

Of course from there, what we’d really like to do is relate the types to the code. Why did the compiler infer the “expected” and “found” types - either (or both) could be wrong, so we need to try and work that out in context.

This is something I've looked into. The compiler would need to start tracking more information than it does now during typeck to keep the span for the first cause of the current type requirement. There is some tracking of this already, but it is lost in some boundaries. Having said that, the compiler should be pointing out with spans something that would read along the lines of expected X, found Y, because x was assigned foo() that returns type argument Z that impls Y but not X (contrived example). #14007 tracks this request.

@jsgf

And error messages around impl Trait could definitely do with some improvement.

I have filed #44530 to deal with the first issue you're likely to come across when trying impl Trait. Feel free to add comments and expand on desired output, as well as point out other cases that you would like addressed.