error/warning message style configuration

[smoothdeveloper]

It seems there are diverging opinions about compiler error messages, they can be formulated to the shortest, and in some case, not disclose enough information, especially in context where the tooling is not available, or just not super user friendly, and they can also provide expansive output, with details about the call site, and the symbols being used or reported.

The rust compiler is known to be really good for showing the actual code, over a whole snippet, and pinpointing which symbol cause issue, both the definition and usage, for the borrow checker, and many other messages. I know from experience that through this extensive details, it made it easier for me to learn the language.

• Messages should always start with the one concise sentence summary, but some user may want to have options.
• There should be infrastructure to achieve the same as Rust is doing, in terms of quoting code, and pretty printing precisely in it.
• There should be an option and knobs for the tooling, to display the error messages in different styling, based on user preference, and / or tooling design choices.
• Some of the long message that currently exist should leverage such setting to provide only the one sentence summary.

[T-Gro]

"especially in context where the tooling is not available"

More specifically, is this sentence about CI scenarios which are running a build?
And the derived suggestion would mean rendering code snippets (each diagnostics carries a range as of now already) into the compiler process's standard output?

I can see this suggestion is framed more like a general capability/infrastructure, but I think it will be better to specify clear user scenarios in mind.

[smoothdeveloper]

@T-Gro fair point:

• Improve error message for: "The type 'int' does not support the operator 'DivideByInt'" dotnet/fsharp#83 some users want just one line, other like me want full detail about the constraint that fails to resolve
• improve compiler error message for failed overload resolution dotnet/fsharp#6596 before, the overload resolution message was repeating same multiline message for each overload, now it gives a short summary at the top, and list all the overload with the reason they don't match, some users want only the top message, other want the full list to simply assess the choices without clicking in tooling

CI scenarios are another consideration: if we can print to console with syntax coloring, and have the same kind of code snippets that Rust emits, as an option, to bring the context of few lines before and after.

Also, in more sophisticated cases, having very precise pointers drawn in ascii (for example mutating a variable that is not mutable, it would connect the definition and mutation usage, and give all details that are similar to a code gesture).

The intent was just to host discussions along those lines, for errors in general.

Regarding the in IDE tooling, the tooltips should always allow scrolling and resizing, moving, pinning, and avoid reformatting the message (given what we have).

I assume those things will improve the experience for all users, and make F# even more approachable (I personally believe the error messages are better than in C# for example).

[Martin521]

Detailed error messages are of course great to have.
I just wonder if the current string-typed API should be (mis)used for it.
Consumers (like IDEs) should be able to format the error message in a suitable way (tooltips, terminals, error lists all have different needs).
To provide some aspects of formatting by putting spaces and newlines into a plain string seems not to be the right way for me.
I would prefer to keep the current API for a simple unformatted message and provide more / additional / structuring information separately.

[smoothdeveloper]

I just wonder if the current string-typed API should be (mis)used for it.
To provide some aspects of formatting by putting spaces and newlines into a plain string seems not to be the right way for me.

In wait for better days / tooling APIs, I think it should, as refactoring to improve on better prettifying infrastructure is an added step on top of the logic that needs to pretty print to textual output (which always, will be there, for all messages, while the converse is not true), not reinventing from scratch, AFAIU.

I would prefer to keep the current API for a simple unformatted message and provide more / additional / structuring information separately.

It would be exciting to have design discussions that are closer to specifics you have in mind in actual focused suggestions in this repo!

[Xyncgas]

Consumers (like IDEs) should be able to format the error message in a suitable way

We can define message in ABI for consumption

[vzarytovskii]

One thing to keep in mind is infrastructure. Meaning what canand can't msbuild and VS consume and display.

[smoothdeveloper]

Things to revisit:

• [WIP] fix for #4956 (TP error reporting) dotnet/fsharp#4978 stack traces when TP fails, I'm considering it could use an environment variable to check, to allow troubleshooting this properly
• [FSharp.Editor] Tooltips are broken in project file but not in script file, and message shown twice. dotnet/fsharp#16360 multiline tooltip works fine in script, but not in project file, and duplicate information is shown
• [wip] error message suggesting Type Provider static parameters names dotnet/fsharp#11451 suggested progress, but blocks against better message because it doesn't come with bells & whistles in the editor (but for end users, they still can't figure out how to adjust the code easily, depending how things are broken in the code being edited, the tooling or parser recovery)

I'm wondering, if it is possible to go past those blocks; it is a bit like git commit messages, first line is short, and then the rest is descriptive, and it is the infrastructure to adapt, the infrastructure serves the users and compilers, without those, msbuild and VS would be much less useful.

I don't see why the tooling which somehow couldn't handle more than a line would not be able to cut it gracefully, and the tooling which can (printing to the output pane, console, build log, tooltip which can scroll), to actually help the user rather than mess with the format.

[Martin521]

We should really discern between what I will now call the "historical error message" (a succinct unformatted one-liner string) and an "extended error message".

1. The historical error message is still very useful in a number of scenarios. These include problem lists displayed in a grid in an IDE; tooltip headers; Compiler and build output printed to a terminal. The latter may be a matter of taste, but I definitely prefer overview over clutter.

2. Putting control characters such as LF into the historical error message is a breaking change.

3. Clearly, there are cases where the historical error message is not sufficient because the problem can simply not adequately be expressed in a succinct one-liner. Therefore modern systems should provide extended information for these cases.

It would be exciting to have design discussions that are closer to specifics you have in mind in actual focused suggestions in this repo!

Here are some initial ideas

For F#, the compiler service should continue to provide the historical error messages.
In addition, the compiler service could provide extended information.
This information should come in a way that supports both terminal output and modern GUI.
It should support paragraphs, bullet lists etc. It could be a F# type, or some sort of markup.
A CLI can then (perhaps dependent on the verbosity level) display the historical error message or request the extended error message and show it on the terminal by inserting LF and spaces. And IDEs can display the extended error message properly (also with proportional fonts, themes etc).

[smoothdeveloper]

Putting control characters such as LF into the historical error message is a breaking change.

I don't think this is the case; https://github.com/dotnet/fsharp/blob/ee4a810ffe9e984e2ec8c55a9cb6d1c6631dd0b3/src/Compiler/FSStrings.resx#L154

there are many messages in F#, probably from day one, that are multiline, maybe not always for great reason in context of ... assembling a mutliline (and pretty printed) message which is information dense.

IMO all the discussion about "multiline message shouldn't exist" "has to conform to tooling" are taken the wrong end.

It feels the same about "code formatting would break on rename with different identifier length", making things worse because it is more convenient for the tooling (while for code that uses alignment for legibility and updatability, it makes things worse when you have code that has better layout in a grid formatting turned into something that can't be read but parsing each individual line, just think if you prefer to read csv in notepad or in spreadsheet).

In same way we should introduce ;, it makes parsing statements easier :)

Anyway, your reflexion brings good understanding and suggestions, it would indeed be nice to make an AST for composing error messages, and have the FCS API return this, I think this is the right direction, and an effort the community can contribute to, once the right infrastructure occurs, even if initially, it just conveys the "historical message" as a value with a raw string in it.

[Martin521]

I was not aware of the long history of multi-line messages. Sorry for not checking.

BTW here is another piece of information on line separators in error messages. It seems there is (or has been at some point) a way to sort of have single-line messages with hidden markup (Unicode group separator chars) for multiline display.

[smoothdeveloper]

support for multiline error message in msbuild terminal logger: dotnet/msbuild#9699