-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Make the expected/found notes a first class comment #38901
Comments
What’s the point of this. How is this would be an improvement enough to special case this error in particular, with us paying in inconsistency credits? |
Could you describe the problem and solution a bit clearer? Just wondering. |
@sanmai-NL, given a file
provide the following output error[E0308]: mismatched types --> file.rs:2:20 | 2 | let x: usize = ""; | ^^ expected usize, found reference | = expected type `usize` = found type `&'static str` instead of error[E0308]: mismatched types --> file.rs:2:20 | 2 | let x: usize = ""; | ^^ expected usize, found reference | = note: expected type `usize` = note: found type `&'static str` @nagisa, I feel that this is a common enough case that it should have its own presentation with (arguably) less clutter. Special casing this would also allow to express in the json for tooling to use as needed for specialization without having to inspect the notes to figure out which one contain the types they might want to use. Special casing these also opens the door to doing something like: error[E0308]: mismatched types --> file.rs:2:20 | 2 | let x: usize = ""; | ^^ expected usize, found reference | = expected type `usize` = found type `&'static str` With json output of
|
Both examples look identical to me? Unless I am missing something. |
@Mark-Simulacrum the proposed output is missing I still fail to see any benefit here. JSON output can easily avoid outputting "children": [
{
"message": "expected type `usize`",
"code": null,
"level": "note",
"spans": [],
"children": [],
"rendered": null
},
{
"message": " found type `&'static str`",
"code": null,
"level": "note",
"spans": [],
"children": [],
"rendered": null
},
{
"message": "here are some functions which might fulfill your needs:\n - .len()",
"code": null,
"level": "help",
"spans": [],
"children": [],
"rendered": null
}
], |
@nagisa: #38902 has a proposed implementation for this. The code with that PR produces the following colorized output: and json format: "children":[
{
"message":"type `usize`",
"code":null,
"level":"expected",
"spans":[],
"children":[],
"rendered":null
},
{
"message":"type `&'static str`",
"code":null,
"level":"found",
"spans":[],
"children":[],
"rendered":null
},
{
"message":"here are some functions which might fulfill your needs:\n - .len()",
"code":null,
"level":"help",
"spans":[],
"children":[],
"rendered":null
}] In contrast with the current colorized output: |
I guess instead of asking why (as I’m not receiving the answer anyway), I should say what I find wrong with this proposal (and associated PR).
So all in all, I feel like the idea is good, but it is misdirected. Rather than tweaking a single error, we ought be thinking about how to achieve all the desirables (even-more-structured errors, ability to add highlights to arbitrary parts of the error message, etc) for all the stuff compiler may report. cc @nrc @jonathandturner has there been any thinking done on machine parsable errors? Not the |
@nagisa, sorry if it seemed like I was evading the question, I was with sporadic time to dedicate to this :-/ The original reason to create the issue was a comment in PR #38605 by @nikomatsakis that made me remember that I had been thinking about the possibility to remove the
My thinking is removing as much text from the output as possible is a worthy goal, as with less text to read from the faster it is to figure out what is going on.
It's true, highlighting of parts of a message are more generally useful than this case in particular. I had filed #37532 sometime ago precisely for this feature, I'd forgotten to get back to it.
In my mind this shouldn't be (at least visually) a note, as the two lines are conceptually part of the same thing, so it'd be nice if it was seen that way in the output.
In the PR I used
I agree with this. Part of the intention was to be as undisruptive as possible while incorporating the new output. |
Thoughts:
|
I feel like that may apply to most of the messages… So why don’t we just remove |
I have a PR out to support multiline messages with a proper margin that might help find a compromise between the current proposal and the existing output. How would people feel with the following? error[E0308]: mismatched types --> file.rs:2:20 | 2 | let x: usize = ""; | ^^ expected usize, found reference | = note: expected type `usize` found type `&'static str` = help: here are some functions that might fulfill your needs: - len() That output would happen if that PR lands and we change the two notes with only one multiline note, instead of two notes. This way we deal with a couple of the problems I saw:
While also maintaining consistency with the other notes. This doesn't look into the json output side of things. |
My two cents: The multi-line version looks good to me (as does the one w/o the Another thing I have always wanted to do with these messages is to add richer type-diffs that server to draw the eye to the real distinction (often the types are long and the difference is just a small part). But I guess we can pursue that either way. |
Issue #21025 raises that point. |
Teach Diagnostics to highlight text Support styled `Diagnostic` output: <img width="469" alt="mismatched types error with colorized types in the note" src="https://cloud.githubusercontent.com/assets/1606434/21871227/93a84198-d815-11e6-88b1-0ede3c7e28ef.png"> Closes #37532 and #38901. r? @nikomatsakis CC @jonathandturner @nagisa @nrc
Instead of using notes for expected type/found type information when there are type mismatches, present something closer to:
The text was updated successfully, but these errors were encountered: