-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Attach explanation message to diagnostic message #16787
Conversation
0ca3e21
to
a79c733
Compare
In the long run, should we pass the |
|
a79c733
to
18a8a09
Compare
This is indeed what I meant.
OK, good to know. I thought it could be useful to allow UIs to adapt the amount of information shown based on the available space. For instance, show first the But in practice I don’t really know if those explanations are really verbose or not. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd actually recommend not merging this unless I'm misunderstanding.
Regarding usage in scala-cli, wouldn't it be more appropriate to instead of relying on the message to rely on rendered
? This is what sbt does for example. By adding the explanation to the message we're essentially making rendered useless aren't we? I don't think we should do this. From my understanding this exact usecase is why rendered
was introduced.
On another note, @lwronski do you have a screenshot on what this looks like in VS Code? In some editors these errors will be gigantic and probably won't display that nicely. I think before we merge this we should ensure that it actually looks nice in the various supported editors. If i'm not mistaken that's why we didn't do this earlier. I'd also be curious to see how other editors that support LSP will display this. We don't want to introduce this and mutilate the way errors look in a handful of editors, even if it's for a minority of users.
I think if we wanted to carry this information forward a more appropriate way would be use use the explanation
field in the DiagnosticCode
. This would allow for that information to be structurally forwarded in a way that a client could choose how to display it. I'm not 100% sure without looking more deeper in dotty, but ideally the message
should be a minimal message whereas the explanation
should be the additional information associated with the diagnostic
. Right now I think there might be overlap as the message
is also contained in the explanation
here. So ideally that wouldn't be the case.
Is there any formal requirement on a Regarding IMO maybe |
I don't think so, but since using explain has a lot of "structured" output in the string we should probably make sure it looks alright in the actual editor since it will make many of them longer.
Gotcha, that makes sense. However with this approach then what ends up being the difference of
Ahhh, I didn't even realize it was only a
Yea, I'm not fully sold. Mainly because in LSP anyways it says:
Which doesn't really seem to apply here or would break assumptions about what it's meant to be used for. I guess if inside of |
Explanations can have various shapes but even if we keep them separate from basic messages, I wouldn't say they have much structure that we could handle in a special way (at least not more than basic messages generated without
It seems that rendered is mainly intended to be used in a REPL session or when compiling code from the command line. Rendering adds some fancy ways of displaying messages when all the information about an error have to be shown in a single piece of text, e.g. it reprints erroneous lines of code with underlined positions and wraps extra messages in ASCII frames just as shown here VirtusLab/scala-cli#1285 In general our main problem is that extra messages from |
But isn't this what we're trying to do with including the
Totally, agreed. |
I would say the compiler and tooling have slightly different understanding of |
@prolativ FYI - The data field is also available in the BSP. It was added some time ago in this PR https://github.com/build-server-protocol/build-server-protocol/pull/363/files. |
@lwronski good to know. However we still need to decide what structure |
True, but again I think we want to be careful what we stick in here since this |
When the
-explain
flag was turned on, an explanation message wasn't displayed in the Metals and Scala CLI. This was because both of these tools only print the message from the Problem.message field.To resolve this issue, I attached the explanation content to the
Problem.message
field, which will now be displayed in the Metals and Scala CLI.This PR addresses a issue from
scala-cli
.