Improve error reporting #1103

Open
isaacabraham opened this Issue Apr 24, 2016 · 10 comments

Projects

None yet

5 participants

@isaacabraham
Contributor
isaacabraham commented Apr 24, 2016 edited

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.

  • 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)
  • Smarter heuristics on incorrect return type of if / else branch (#1106) (rejected)
  • 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)
  • Function accidentally partially applied (#1107) (on hold)
  • Accidental use of , instead of ; as collection separator (#1120) (on hold)
  • Missing = on type declaration (#1121) (up for grabs)
  • Missing cast operator for subtype case (#1128) (up for grabs)
  • Add an url with more info for each warning/error (#1136) (more discussion?)
  • Suggest inlining when compiler constrains types to be less generic (#1160) (up for grabs)
  • Partially applied generic value vs function (#1161) (more discussion?)
  • Missing , from object initializer (#1218)
  • Report visibility issue between two assemblies (#1348) (more discussion?)
  • Better heuristics for identifying the code line with a type error (#1384) (more discussion?)
  • Ambiguous override method in object expression (#1429) (more discussion?)
  • Override method does not match abstract member (#1430) (more discussion?)
  • Using EntryPoint attribute in an F# script (#1431) (more discussion?)
  • Incorrect line number for warning within while loop statement (#326)
  • Confusing and ambiguous error (FS0368) when implementing an interface with overloads (#1905)
  • Property syntax can't be remembered (#2277)
  • Improve error when record is used like a ctor (#1933)
  • 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)
  • Accessing protected members within async blocks (#2307)
  • 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
  • Confusing error message for invalid member declaration #920
  • Unfixable FS0076 error from fsharpi when putting #r directive in .fs file #569

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
Contributor

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

@isaacabraham
Contributor

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
Contributor

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

@dsyme
Contributor
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
Contributor

@dsyme done.

@dsyme
Contributor
dsyme commented Jun 22, 2016 edited

@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
Contributor
forki commented Jun 22, 2016

@dsyme WIP: #1275

@isaacabraham
Contributor

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

@forki
Contributor
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
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment