Skip to content
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

Improve error reporting #1103

Open
isaacabraham opened this issue Apr 24, 2016 · 19 comments
Open

Improve error reporting #1103

isaacabraham opened this issue Apr 24, 2016 · 19 comments

Comments

@isaacabraham
Copy link
Contributor

@isaacabraham isaacabraham commented Apr 24, 2016

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.

Implemented!

  • Propose compatible record labels when compiler can't find label and doesn't know record type (#1102)
  • Propose compatible record labels when compiler can't find label in known record type (#1102)
  • Propose types inside of module / namespace (#1102)
  • Missing "else" branch for if expression (#1104)
  • If / else branches return different types (#1105)
  • Usage of <- operator on non mutable bindings (#1110)
  • Accidental use of , instead of ; as record field separator (#1122)
  • Wrong cast operator (:?> instead of :>) (#1127)
  • Provide better literal suffix description (#1129)
  • Missing "else" branch for if / elif expression (#1157)
  • Let as last line in block (#1162)
  • Recursive async functions (#1170)
  • Detect module declarations that incorrectly end with = (#1214)
  • Show better error when using ref cell instead of not (#1275)
  • Member implementation with tuple argument(s) (#1203)
  • Show better error when using ref cell instead of not (#1276)
  • Property setter in constructor expression (#1112)
  • Warning when expression result is ignored (#1108)
  • No abstract method matching implementation (#1232)
  • Record does not match type when using Record Expressions (#1280)
  • Add type info to errors (#1834)
  • Warning when the result of a comparison is ignored (#1109)
  • This expression was expected to have type 'A' but here has type 'A #2561
  • Missing , from object initializer (#1218)
  • Incorrect line number for warning within while loop statement (#326)
  • Confusing and ambiguous error (FS0368) when implementing an interface with overloads (#1905)
  • Improve error when record is used like a ctor (#1933)
  • Override method does not match abstract member (#1430)
  • Wrong error "type is not structurally comparable" if some fields of a record definition are unresolvable #2268
  • Puzzling error message in case of wrong indentation inside computation expression #2201 (more discussion?)
  • Unfixable FS0076 error from fsharpi when putting #r directive in .fs file #569
  • Accessing protected members within async blocks (#2307) (should still be open for more "complete" fix)
  • Improve warning for ignored values in sequence expressions (#4228)
  • Better expression errors (#5114)
  • When implementation is missing necessary overrides, report a list of them (#4982)
  • Better description for mismatched anonymous records (#8091)

Up for grabs!

  • Missing = on type declaration (#1121)
  • Suggest inlining when compiler constrains types to be less generic (#1160)
  • Missing cast operator for subtype case (#1128)
  • Inner expressions inside computations expressions (#2739)
  • do-keyword missing in a query (#2799)
  • Operator that has not been defined (#2828)
  • No warning or error is generated if a constructor calls itself (#2321)
  • Could not be generalized because it would escape its scope (#3302)
  • Improve Pattern Match warning (#3765)
  • Improve error message when yield! was used but yield is needed and vice versa (#4233)
  • Wrong indentation in list comprehension leads to unhelpful error message (#4232)
  • Passing arguments to a simple value gives a confusing error (#5476)
  • Inconsistent error when using "as alias" in binding when matching tuples (#5259)
  • Confusing error message for invalid member declaration (#920)
  • Forgetting | in anonymous record gives a confusing error message (#8127)

More discussion / on hold

  • Function accidentally partially applied (#1107)
  • Accidental use of , instead of ; as collection separator (#1120)
  • Add an url with more info for each warning/error (#1136)
  • Partially applied generic value vs function (#1161)
  • Report visibility issue between two assemblies (#1348)
  • Better heuristics for identifying the code line with a type error (#1384)
  • Ambiguous override method in object expression (#1429)
  • Using EntryPoint attribute in an F# script (#1431)
  • Property syntax can't be remembered (#2277)
  • Improve error reporting: message when defining record with open brace on separate line (#1826)
  • Match expressions with DUs missing parentheses around their tupled arguments (#1511)
  • Warn when pipe operators are incorrectly indented (#1442)
  • Struct DUs with duplicate field names (#5236)
  • Need parentheses on callsite (#5475)
  • Passing an argument to a function that is a result of a function call (#6687)
  • Match statement with a patterns referring to an out of scope identifier give incomplete warning (#6712)
  • No expression in computation expression (#6717)
  • Internal Error with badly defined anonymous record (#6872)
  • Missing "else" branch for if expression with elif (#6873)

Rejected

  • Smarter heuristics on incorrect return type of if / else branch (#1106) (rejected)

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
Copy link
Contributor

@enricosada enricosada commented Apr 24, 2016

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

@isaacabraham
Copy link
Contributor Author

@isaacabraham isaacabraham commented Apr 24, 2016

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

@vilinski
Copy link

@vilinski vilinski commented Apr 24, 2016

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

@isaacabraham
Copy link
Contributor Author

@isaacabraham isaacabraham commented Apr 24, 2016

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

@dsyme
Copy link
Contributor

@dsyme dsyme commented Apr 26, 2016

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
Copy link
Contributor Author

@isaacabraham isaacabraham commented Apr 26, 2016

@dsyme done.

@dsyme
Copy link
Contributor

@dsyme dsyme commented Jun 22, 2016

@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
Copy link
Contributor

@forki forki commented Jun 22, 2016

@dsyme WIP: #1275

@isaacabraham
Copy link
Contributor Author

@isaacabraham isaacabraham commented Aug 15, 2016

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

@forki
Copy link
Contributor

@forki forki commented Aug 15, 2016

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
#1109 and #1218
#1218? Any way we can
unblock these?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1103 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNAYSq9iFBEHF3byxTkmp-oimwQTFks5qgJfqgaJpZM4IOdcd
.

@isaacabraham
Copy link
Contributor Author

@isaacabraham isaacabraham commented Mar 30, 2017

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
Copy link
Contributor

@dsyme dsyme commented Mar 30, 2017

Thanks! Such great progress overall :)

@cartermp
Copy link
Contributor

@cartermp cartermp commented Dec 6, 2017

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

@ShalokShalom
Copy link
Contributor

@ShalokShalom ShalokShalom commented Jan 29, 2018

@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
Copy link
Contributor

@forki forki commented Jan 29, 2018

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

@cartermp
Copy link
Contributor

@cartermp cartermp commented Jul 21, 2018

Link #5114

@cartermp
Copy link
Contributor

@cartermp cartermp commented Jul 21, 2018

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

@isaacabraham
Copy link
Contributor Author

@isaacabraham isaacabraham commented Jul 21, 2018

Done

@cartermp
Copy link
Contributor

@cartermp cartermp commented Apr 19, 2019

#4982 closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.