Improve error reporting: property setter in constructor expression

[smoothdeveloper]

What

Sometimes, user wants to assign properties in a constructor expression:

type MyClass() =
    member val MyProperty = "" with get, set

let c = MyClass(Property = "")

gives:

The member or object constructor 'MyClass' has no argument or settable return property 'Property'. The required signature is new : unit -> MyClass.

Why

Given the compiler has exact information about MyClass, it could yield more information about what is possible to do in context of constructor expression.

How

The member or object constructor 'MyClass' has no argument or settable return property 'Property', did you mean to assign 'MyProperty' or (*) instead. The required signature is new : unit -> MyClass.

(*) list X other properties (see discussion) that aren't already listed in the constructor expression in decreasing order of likeliness.
#1103

[KevinRansom]

Would you limit the listed alternatives or list them all?
Do you think the experience would be improved if there were 30 alternatives?

I actually think this is one of our clearer error messages, it actually says exactly what is wrong. The part of this error message that bothered me when I started was the "The member or object constructor 'MyClass' ". However I can't think of a better alternative.

My preference would be to use the Roslyn integration to enable code fixers for these sorts of errors. It would seem relatively straightforward to offer all of the alternatives using intellisense in the IDE with a fixes.

The work that @otawfik-ms is currently doing will lay out a framework that enables code analyzers and code fixers inside the IDE.

[isaacabraham]

@KevinRansom I doubt one would want to list all of them - perhaps just the one (or two) most likely candidates. Surely that's a richer experience than currently exists?

Roslyn + VS integration is not the way to go for this stuff IMHO. Code fixes yes, actual compiler errors / messages - I'm not so sure. We want x-platform support for this without forcing Roslyn as a dependency onto other tooling.

[smoothdeveloper]

@KevinRansom thanks for inquiry, I think a list of 5 maximum would be definitely better than all the alternatives 😄

I agree the error message is already helpful and clear, but when I'm trying to fix the error and intellisense doesn't pickup somehow, getting the nearest match is great.

Haskell compiler does that as well and always felt it was helpful and friendly to have the compiler tell me what is known about that type.

I agree that roslyn integration seems like a good spot for implementing fixers, and hopefully make them work outside of VS too. Thanks for the update on @otawfik-ms work!

I'll let people put their comments if the proposal seems appropriate, it gives me nice feeling when compiler is more personable and helps me for next step editing the code but this is subjective, and I also believe that the consistency and tone of all the error/warning messages has to be reviewed / adjusted by the maintainers at MS.

It feels that those contributions can be taken by the community with relatively low impact, and I guess the concern on performance is not as stringent when the compilation is failed anyways (warnings is in another league).

[dsyme]

I agree that roslyn integration seems like a good spot for implementing fixers.

I suggest we do both:

1. We improve error messages fromm fsc.exe to be "best in class" as a command-line tool, so it is at least as good as Elm and other highly-regarded command-line systems. If this means offering some suggestions in error messages, then I think we have to do it.
2. Equally, each time we put any new non-trivial logic into error messages (e.g. information which would be useful as a the basis for a code-fixer), we should also, as a matter of principle, also make sure that the logical content is also available via the FSharp.Compiler.Service API. See my comment here for example. Elm-like compiler errors for name resolution #1102 (comment)

My working assumption is that roughly 50% of users are using a rich IDE (powered by FCS or Roslyn), and 50% are using tooling that's based purely on the command-line compiler.

Basically I agree with @isaacabraham that one should not come at the expense of the other.

[forki]

WIP PR in #1228