`Tracking` Error reporting improvements

[isaacabraham]

Related to #1102, this issue could act as an overall list for all the issues relating to error reporting from the compiler. I'll start the ball rolling by adding the ones mentioned in that issue plus a few more.

Up for grabs!

• [ ] #12341
• [ ] #1160
• [ ] #2739
• [ ] #2799
• [ ] #2828
• [ ] #2321
• [ ] #3302
• [ ] #3765
• [ ] #4233
• [ ] #4232
• [ ] #5476
• [ ] #5259
• [ ] #8127
• [ ] #10167
• [ ] #6873

More discussion / on hold

• [ ] #13014
• [ ] #13013
• [ ] #13012
• [ ] #1107
• [ ] #1120
• [ ] #1136
• [ ] #1348
• [ ] #1384
• [x] #1429
• [ ] #2277
• [ ] #1826
• [ ] #1511
• [ ] #1442
• [ ] #5236
• [ ] #5475
• [ ] #6687
• [x] #6712
• [ ] #6717
• [ ] #11234
• [ ] #12586
• [ ] #10564
• [ ] #11445

Implemented!

• [x] #1161
• [x] #6872
• [x] #11468
• [x] #1102
• [x] #1104
• [x] #1105
• [x] #1110
• [x] #1122
• [x] #1127
• [x] #1129
• [x] #1157
• [x] #1162
• [x] #1170
• [x] #1214
• [x] #1275
• [x] #1203
• [x] #1276
• [x] #1112
• [x] #1108
• [x] #1232
• [x] #1280
• [x] #1834
• [x] #1109
• [x] #2561
• [x] #1218
• [x] #326
• [x] #1905
• [x] #1933
• [x] #1430
• [x] #2268
• [x] #569
• [x] #4228
• [x] #5114
• [x] #4982
• [x] #8091
• [x] #1121
• [x] #2201 (more discussion?)
• [x] #2307 (should still be open for more "complete" fix)
• [x] #920
• [x] #1431

Rejected

• [x] #1106
• [x] #1128

Contributing

If you have ideas for other error messages, please adhere to the following standard for new issues: -

1. Title the issue "Improve Error Reporting: "

2. Each issue should have the following elements: -

   a. What - reproduction of the error through a code snippet and compiler error / warning. b. Why - why the current compiler error / warning is insufficient. c. How - how you would improve the current error / warning with an alternative example.

[enricosada]

i just want to add a ref to ocaml error reporting improvements, it's really nice

[isaacabraham]

Another good source for ideas of potential issues: http://fsharpforfunandprofit.com/troubleshooting-fsharp/

[vilinski]

Missing method XYFooBar --> may be you need an FSharp.Core redirect

[isaacabraham]

@vilinski can you raise an issue for this and maybe give a concrete example of where this happens?

[dsyme]

That's a good list.

I'd like to see each of the issues above have a few lines of justification addressing why we believe the error message is specifically a problem for beginners (e.g. they might be coming with expectations from Python or C#)

[isaacabraham]

@dsyme done.

[dsyme]

@isaacabraham One error you might like to consider is a much better error message when a C# or C++ programmer uses !expr to mean "not". F# interprets that at "dereference a ref cell".

Now, as of F# 4.0, the use of explicit ref cells is far less common because implicit promotion of let mutable is now so well supported. We could probably even consider deprecating the use of !expr as the default syntax and instead ask people to either use not expr or expr.Value.

But even without going that far, we could surely improve the error message for a misuse of !expr in the common case, asking people to use not expr instead (perhaps with parentheses as in not (f x))

Can I leave it to you to add the specific issue for this?

[forki]

@dsyme WIP: https://github.com/Microsoft/visualfsharp/pull/1275

[isaacabraham]

@forki what's the status of #1109 and #1218? Any way we can unblock these?

[forki]

I need help from @dsyme - I already contacted him

2016-08-15 18:46 GMT+02:00 Isaac Abraham notifications@github.com:

@forki https://github.com/forki what's the status of #1109 https://github.com/Microsoft/visualfsharp/issues/1109 and #1218 https://github.com/Microsoft/visualfsharp/issues/1218? Any way we can unblock these?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/visualfsharp/issues/1103#issuecomment-239856456, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNAYSq9iFBEHF3byxTkmp-oimwQTFks5qgJfqgaJpZM4IOdcd .

[isaacabraham]

Just done a quick review here. There are a few issues that seem to me to be "up for grabs" i.e. there's been a discussion on the issue and there seems to be consensus on what the outcome should be - someone "just" needs to do the work.

There are also some that need some discussion to review them and decide the best way forward.

[dsyme]

Thanks! Such great progress overall :)

[cartermp]

Removing the discussion label as this is really an all-up tracking issue

[ShalokShalom]

@enricosada Thanks hundred times for this link:

http://www.chargueraud.org/research/2015/ocaml_errors/ocaml_errors.pdf

This is so true and especially to me as a newbie currently very challenging;

"In many cases, error messages cannot be interpreted without a sufficiently-precise model of the type inference algorithm."

You have to study computer science with a special focus on ML, in order to get a drift about these type issues. I love F-Sharp really a ton and this is by far the most distracting thing to me yet, simply because I often lack any idea how this can be solved.

In truth, I think it starts even with the term "error messages". It should be not an error message only, it should contain an actual solution. Like Elm does that. And Reason and Rust. It seems to get quite standard. Which is, IMHO, overdue since decades.

I like to translate these solutions and I suggest a public announcement like in the form of a blog/twitter/slack post, which invites to the public contribution on this issue.

Thanks a lot ^-^

[forki]

@ShalokShalom look at the "Contributing" part. That's what we already aim for. To give a hint on how to fix things

[cartermp]

Link #5114

[cartermp]

@isaacabraham Can you add #5114 to the original issue please?

[isaacabraham]

Done

[cartermp]

4982 closed.

[kerams]

This might be a bit orthogonal, but I really like that for some code fixes ReSharper also includes "Why is ReSharper suggesting this?" in the lightbulb tooltip. Clicking on that opens a help page in the browser, like this https://www.jetbrains.com/help/resharper/2020.3/ReturnTypeCanBeEnumerable.Local.html. I believe having an equivalent in VS tooling would prove very helpful for errors like #3302, whose background is too complex to explain in a compiler error message. An alternative would be having a (clickable?) HTTP link for further details in the error message itself, but I'm not sure how you feel about having links in compiler error messages. Either way, a dedicated section for in-depth error/warning analysis in the vein of ReSharper somewhere under https://docs.microsoft.com/en-us/dotnet/fsharp/ that, most importantly, the user can quickly access from VS would go a long way in my opinion.

[smoothdeveloper]

@kerams, I think this would lean very well for errors even without code fixes, if we had a canonical script file showcasing the error, with additional "literate" contents which can be processed by fsdocs or similar.

Such contents could be both part of microsoft and fsharp.org documentations.

This is also a good approach to have every compiler error message (over time) covered under tests using the baseline files with an emphasis on creating good contents to help users not quite grasping the error message.

@baronfel had some effort invested in that direction, although it was manually authored content that isn't put under compuler testing infrastructure, maybe he could bring back a pointer to what he did around that topic.

[baronfel]

Yep, we have a set in progress that can be found in the docs here. Brett Rowberry wrote a blog post back in December about the process of authoring these files, and yes it was manually generated content for each error/warning. I do think having these as a reference is great for editors (and even verbose CLI messages like the rust compiler does!) and that was part of the idea here: provide some kind of anchor that IDEs can link to.

[LyndonGingerich]

Is #1431 still in state "More discussion / on hold"? It is closed as completed.

[0101]

@LyndonGingerich it's done. I moved it into the Implemented list.

[jkone27]

sorry if this is a not relevant remark or already adressed, maybe is already adressed by one of the proposals, but checking Rust error messages now and they are really awesome

but maybe is the same already referenced here? support code previews? Rust is really nice on error messages https://github.com/dotnet/fsharp/issues/14832

[ShalokShalom]

sorry if this is a not relevant remark or already adressed, maybe is already adressed by one of the proposals, but checking Rust error messages now and they are really awesome

but maybe is the same already referenced here? support code previews? Rust is really nice on error messages #14832

I know that we spoke about this in the F# Discord, and it was said that the implementation of something like this relies on dotnet tooling, that is still in the works.

[voronoipotato]

@vzarytovskii hello, I made a suggestion about a confusing error message https://github.com/fsharp/fslang-suggestions/issues/1324 here. Bent redirected me here. Trying to make sure I do this right. Should this suggestion be an dotnet/fsharp issue here?

[vzarytovskii]

Yeah, I think diagnostics improvements are fine in this repo

[voronoipotato]

Okay I'll probably have to tackle this after work, running out of lunch time :), also could you fix the title :( improvenets should be improvements, I can't stop thinking about it. Unless it's a pun, in which case 'ha'.