-
Notifications
You must be signed in to change notification settings - Fork 13.3k
better mismatched types error message #3417
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
Comments
+1, except: is the multi-line version preferable even when the type names are short? |
Another possible option?
|
Maybe not lkuper: I did see an error afterwards that looked fine. Perhaps a heuristic can be used to split the error into multiple lines. Perhaps even a general heuristic that splits long error messages into multiple lines at places marked as line breakable. |
+1 for brson's version. |
accepted for P-low |
visiting for triage. This is still a problem today. I'm interested in fixing this, but I have no idea what I'm doing. Does this fix only require changing every instance of
in
? Or is it more complicated than that? |
presumably we'd want to update the API to take in multiple parts. I'd like for it to be able to diff the strings and highlight the differences, as well. |
I strongly believe this should be done by 1.0. Some of the type mismatch errors can get pretty ridiculous, especially because error messages don't use type aliases when they were used. Using type aliases in error messages probably entails a large undertaking in the compiler to make possible, but putting the expected and actual type on separate lines would be a very simple way to improve readability. I can imagine that if a user gets a very long type mismatch error that is difficult to parse, it can elicit or increase the feeling that the compiler is being wrestled with, and that "the types are getting in the way," when instead the compiler is helping. This is even more pronounced when using iterator types. Given a function which returns the keys of a hashmap field on a struct: pub fn nodes(&self) -> Keys<'a, &T, HashSet<&T>> {
self.edges.keys()
} If I change the return type from
The last parenthesized message,
Granted, the type is still long, but at least it's easier to spot the inconsistency. |
For this particular error currently have
which I believe is something this issue wanted to get (though it is implemented in a very hacky way). I think this can be closed. cc @steveklabnik |
Closing per @nagisa's comment. Thanks everyone! |
…lfJung we have to ignore RUSTC_WORKSPACE_WRAPPER as well This matches what we do with RUSTC_WRAPPER.
These are great error messages but most of the time they're quite hard to read because they are so long. They would be much more readable if they were six lines instead of one line.
So instead of
something like
The text was updated successfully, but these errors were encountered: