Elm-like compiler errors for name resolution

[forki]

Introduction

This PR is a starting point for making the F# compiler emit error messages that are more user friendly. Newcomers to Elm report that the excellent compiler errors [read http://elm-lang.org/blog/compiler-errors-for-humans] help so much to get started quickly. We should do our best to improve our error messages as well.

I think this can be done as community effort. This PR will start and bring some infrastructure in place. After that we can create a list with possible optimizatons and divide the work. This approach worked very well when we "regularized" the collections.

Sample: Propose compatible record labels when compiler can't find label and doesn't know record type

Let's consider a small sample to see what we can improve:

Microsoft (R) F# Interactive version 14.0.23413.0
Copyright (c) Microsoft Corporation. All Rights Reserved.

For help type #help;;

> type A = { Hello:string; World:string }
type B = { Size:int; Height:int }
type C = { Wheels:int }
type D = { Size:int; Height:int; Walls:int }
type E = { Unknown:string }
type F = { Wallis:int; Size:int; Height:int; }

let r = { Size=3; Height=4; Wall=1 };;

  let r = { Size=3; Height=4; Wall=1 };;
  ----------------------------^^^^

stdin(8,29): error FS0039: The record label 'Wall' is not defined

So the compiler can't find the record label Wall and complains about that. After applying the PR we will get the following:

As you can see the compiler proposes record labels that might work here. In this case it looks for all records that are compatible with what you already have (Size, Height labels). It then computes the edit distance (Damerau Levenshtein) to the labels of these records and proposes the top 5.

Sample: Propose compatible record labels when compiler can't find label in known record type

Here we only predict labels that are in same record type, ordered by edit distance.

Sample: Propose types inside of module / namespace

Changes in this Pull Request

• Add Edit Distance function
• Propose compatible record labels when compiler can't find label and doesn't know record type
• Propose compatible record labels when compiler can't find label and knows record type
• Propose types inside of module / namespace

[forki]

/cc @dsyme I think we want to compare full qualified names of the types. How can I do that?!

[forki]

@KevinRansom @enricosada @dsyme I want to test for the multi line error message here. How can I do that?

[enricosada]

@forki about multiline, just use more Expect, like there

[TIHan]

This is awesome. :D

[forki]

I think something seriously bad happened to nuget. This doesn't even start to build anymore because restore failed. See http://dotnet-ci.cloudapp.net/job/Microsoft_visualfsharp/job/master/job/debug_windows_nt_prtest/261/console

/cc @KevinRansom @maartenba

[maartenba]

@forki I may be missing it in the build log but where does it go wrong? If it's that first restore, it seems it's somehow not hitting the correct feed(s)

[forki]

04:16:05 The path is not of a legal form.
04:16:05 Error: dotnet publish failed

This all worked yesterday. I only pushed a change that is related to unittests that come much later.

[maartenba]

Possible change on the build machine? (the error is kinda vague :))

[forki]

The same happens on appveyor. Both (unrelated) build servers report this issue

[maartenba]

Definitely no server-side changes on NuGet since yesterday. Client side no idea. @KevinRansom

[forki]

In 98a329a I commited older version of dotnet cli. This seems to work.

/cc @KevinRansom @enricosada is there a way to make it download a pinned version of dotnet cli? and who do we have to ask to fix it!?

[forki]

Implemented first round of feedback.

[forki]

I think this is ready and merging this would help me to work on similar issues.
(appvevor seems to be broken, but unrelated)

[forki]

WTF!? appveyor reporting something unrelated:

Errors and Failures

1) Failed : FSharp.Core.Unittests.FSharp_Core.Microsoft_FSharp_Control.AsyncModule.OnCancel.RaceBetweenCancellationHandlerAndDisposingHandlerRegistration
  Expected: True
  But was:  False
at <StartupCode$FSharp-Core-Unittests>.$AsyncModule.test@280-22(Unit unitVar0) in C:\projects\visualfsharp-3dtit\src\fsharp\FSharp.Core.Unittests\FSharp.Core\Microsoft.FSharp.Control\AsyncModule.fs:line 293
at FSharp.Core.Unittests.FSharp_Core.Microsoft_FSharp_Control.AsyncModule.OnCancel.RaceBetweenCancellationHandlerAndDisposingHandlerRegistration() in C:\projects\visualfsharp-3dtit\src\fsharp\FSharp.Core.Unittests\FSharp.Core\Microsoft.FSharp.Control\AsyncModule.fs:line 294

[forki]

is there anything I can do to get this in? I would need that infrastructure for other similar cases

[forki]

that test was flaky. it's green now

[dsyme]

I'm OK with this change (up to the caveats I mentioned up above about also eventually making the information available through the compiler service)

[isaacabraham]

Something I've just noticed about this - if you create a record via let x = { RecordType.FieldName = "blah" } syntax, the new and improved suggestions don't appear (compared to let x : RecordType = { FieldName = "blah" }

[isaacabraham]

Also the "suggest types" one (e.g. Lst instead of List) doesn't work on the RHS of the equals e.g. let x = System.Collections.Generic.Lst()

[forki]

please create separate issues with repro and set me cc