The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
Перейти к файлу
Gauthier Segay acd7cfd251
improve compiler error message for failed overload resolution (#6596)
* migrate (as a separate copy) fsharpqa tests that are going to be impacted by #6596

the baseline files are empty on purpose, expecting CI failure reporting those tests, I intend to update the baseline and clean up the comments / xml tags from fsharpqa syntax in later commit, and then remove those specific tests altogether from fsharpqa if this is OK with the maintainers.

* update the .bsl files

* remove comments that are handled by baseline files, update baseline files

* remove the migrated tests from fsharpqa tests

* need to be more careful when migrating those

* testing if running the test with .fs instead of .fsx makes them work on .netcore

* exclude migrated fsharpqa from dotnet core run

* sample test in fsharpqa (can't run locally for now)

* trying to make it green now.

* checking if this path is covered by a test, trying to identify how to trigger this other overload related error message

* * [MethodCalls.fs] Defining CallerArgs<'T> in, this replaces passing of callerArgsCount, uncurriedCallerArgs and other variants in the overload resolution logic happening in ConstraintSolver & TypeChecker
* [TypeChecker.fs] pass CallerArgs instace at call sites for overload resolution + some commented code as we'll be building a list of given argument types (probably moving as a CallerArgs method or property)
* [ConstraintSolver.fs/fsi] pipe the overload resolution traced callback to `trace.CollectThenUndoOrCommit` as that expression is long and more important in that context

* bit of refactoring of error message building logic during failed overload resolution

[ConstraintSolver.fsi]

* define OverloadInformation and OverloadResolutionFailure, those replace workflow where `string * ((CalledMeth<_> * exn) list)` values were created at call site mixed with message building and matched later in non obvious fashion in `failOverloading` closure
* adjust UnresolvedOverloading and PossibleOverload exceptions

[ConstraintSolver.fs]

* get rid of `GetPossibleOverloads`, this was used only in `failOverloading` closure, and just being passed the same parameters at call site
* give `failOverloading` a more meaningful signature and consolidate the prefix message building logic there
* fix `failOverloading` call sites

[CompilerOps.fs] adjust pattern matching

Expecting behaviour of this code to be identical as before PR

`

* (buildfix) harmonizing .fsi/.fs right before commit doesn't always work with simple copy paste.

* trying to check what kind of things break loose when I change this

I'm trying to identify why we get `(CalledMeth<Expr> * exn list)`, I'm making a cartesian product through getMethodSlotsAndErrors for now, trying to figure out if we can get other than 0 or 1 exception in the list for a given method slot.

I may revert that one if it doesn't make sense make from a reviewer standpoint and/or breaks fsharpqa tests surounding overload resolution error messages.

* (minor) [ConstraintSolver.fs] revert space mishapps to reduce diff, put back comments where they were

* toward displaying the argument names properly (may fail some fsharpqa tests for now)

* missing Resharper's Ctrl+Alt+V "introduce variable" refactoring @auduchinok :)

* pretty print unresolved overloads without all the type submsumption per overload verbose messages

* Overload resolution error messages: things display like I want in fsi, almost like I want in VS2019, this is for the simple non generic method overload case.

I want to check if user experience changes wrt https://github.com/Microsoft/visualfsharp/issues/2503 and put some time to add tests.

* adjust message for candidates overload

* Hijack the split phase for UnresolvedOverloading, remove the match on PossibleOverload.

It consolidates some more of the string building logic, and it now shows as a single compact and exhaustive error message in VS

Thinking I'll change PossibleOverload to not be an exception if going this way is OK

* updating existing failing baseline files that looks correct to me

* quickfix for update.base.line.with.actuals.fsx so that it skips missing base line files in the loop

* (minor) minimize diff, typos, comments

* fix vsintegration tests affected by overload error message changes

* merge issue unused variable warning

* update the 12 fsharpqa migrated baseline with new error messages

* (minor) baseline update script

[update.base.line.with.actuals.fsx]
* add few directories
* error handling (when tests are running, the .err files are locked

* move System.Convert.ToString and System.Threading.Tasks.Task.Run tests from QA

* * moving 3 fsharpqa tests to new test suite
* bring back neg_System.Convert.ToString.OverloadList.fsx which I mistakenly removed during merge

* consolidate all string building logic in CompileOps.fs, fix remaining cases with missing \n (the end result code is less whack-a-mole-ish)

* update base lines

* remove the migrated tests from fsharpqa

* fix vstest error message

* fix env.lst, removed wrong one...

* update baselines of remaining tests

* adding one simple test with many overloads

* appropriate /// comments on `CalledMeth` constructor arguments

* minimize diff / formatting

* trim unused code

* add simple test, one message is interesting, mentioning parameter count for possible overloads

* comment flaky test for now

* code review on the `coerceExpr` function from @tihan, we can discard first `isOutArg` argument as the only hardcoded usage was guarded by `error` when the value is true, and passing an explicit false which is now guaranteed equivalent to `callerArg.IsOptional`

* code formatting remarks on ConstraintSolver.fs/fsi

* (minor) formatting

* format known argument type / updating .bsl

* update missing baseline

* update missing baselines

* update missing baseline

* minor: make TTrait better in debugger display

* [wip] pass TraitConstraintInfo around failed overload resolution error, and try to display some of it's info

* minimize diff

* signature file mismatch

* removing duplicate in fscomp.txt

* surfacing initial bits of TraitConstraintInfo, roughly for now

* formatting types of known argument in one go, the formatting is still wrong:

* unamed type arguments aren't relabelled (still show their numerical ids)
* SRTP constraints are dismissed, not sure how they should be lined up to pass to SimplifyTypes.CollectInfo

* rework of overload failure message to prettify *ALL* types in a single go, not only argument types, but return types and known generic argument types (this info was never displayed originally but is useful for scenario similar to FSharpPlus implementation)

added `PrettifyDiscriminantAndTypePairs` in TastOps, this allow to weave extra information with the complete list of types, to help reconstituting the several types from their origin (in the usage spot: argument types, return type, generic parameter types)

* fixup the tests and add two tests

* one checking on the new information of known return type and generic parameter types
* one checking we don't leak internal unammed Typar and that they don't all get named 'a despite being different

* updating baselines that got tighter.

* simplify handling of TraitConstraintInfo

* naming couple of fields and turning a property to a methods as it triggers an assert in debugger when inspecting variables

* comments in the assembling of overload resolution error message

* Add information about which argument doesn't match
Add couple of tests
Updating bunch of baselines

* minor updates to testguide and devguide

* fix PrimitiveConstraints.``Invalid object constructor`` test

* fix(?) salsa tests

* minimize diff

* put back tests under !FSHARP_SUITE_DRIVES_CORECLR_TESTS

* missing updated message

* minor adjustments to TESTGUIDE.md

* return type was missing prettifying in prettyLayoutsOfUnresolvedOverloading

* address code review nits / minimize diff / add comment on PrettifyDiscriminantAndTypePairs

* minimize diff

* proposed work around the flaky error message until https://github.com/dotnet/fsharp/issues/6725 has a fix

we keep the fsharpqa test around (but removing the overload error messages from what is asserted out of it) in the meantime

* fixing baselines of new tests from master

* sisyphus round of baseline update

* removing type which isn't in use and popped back up after rebase

* minimize diff

* tidy inconsistent tuple literal

* * removing TTrait properties that end up not being used
* renaming tys and returnTy fields to better match convention (`tys` is used, so no underscore prefix)
* minimizing diff

* minimize diff

* minimize diff

* minimize diff

* link to usage example in same file

* revert converting CallerArg single cased DU into Record

* minimize diff

* minimize diff

* minimize diff

* fix rebase glitches

* fix rebase glitch

* update baseline

* fix base lines / new tests base lines

* edge case: needs a new line after "A unique overload for method '%s' could not be determined based on type information prior to this program point. A type annotation may be needed." if there are no optional parts.

* updating base line for edge case of missing new line

* missing baseline

* removing comment
2020-02-18 16:40:22 -08:00
.github/ISSUE_TEMPLATE Update issue templates (#6784) 2019-05-20 18:09:51 -07:00
.vscode
benchmarks normalize package version variables (#6733) 2019-05-14 14:16:38 -07:00
eng Merge pull request #8572 from dotnet/darc-master-8c0009a0-7f5d-49fe-b1e7-af16a5498bf1 2020-02-13 21:44:32 -08:00
fcs Optimized find all references and reduced memory usage in VS (#8339) 2020-02-13 16:43:09 -08:00
mono
scripts Dependency Manager 2019-09-09 12:07:31 -07:00
setup normalize package version variables (#6733) 2019-05-14 14:16:38 -07:00
src improve compiler error message for failed overload resolution (#6596) 2020-02-18 16:40:22 -08:00
tests improve compiler error message for failed overload resolution (#6596) 2020-02-18 16:40:22 -08:00
vsintegration improve compiler error message for failed overload resolution (#6596) 2020-02-18 16:40:22 -08:00
.gitattributes replace deprecated nuspec `iconUrl` element with `icon` 2019-09-27 13:56:28 -07:00
.gitignore merge 2019-10-15 12:43:21 -07:00
.vsconfig Trim vsconfig (#6789) 2019-05-21 11:54:25 -07:00
Build.cmd
CODE_OF_CONDUCT.md Update several links (#7055) 2019-06-25 10:13:01 +01:00
CoordinateXlif.targets
DEVGUIDE.md improve compiler error message for failed overload resolution (#6596) 2020-02-18 16:40:22 -08:00
Directory.Build.props
Directory.Build.targets
FSharp.Profiles.props Relax --noframework for mscorlib, netstandard and system.runtime (#7612) 2019-09-24 18:29:09 -07:00
FSharp.sln Even more refactoring of DependencyManagerIntegration (#8518) 2020-02-10 13:27:41 -08:00
FSharpBuild.Directory.Build.props [master] Update dependencies from dotnet/arcade (#7706) 2019-11-05 15:18:09 -08:00
FSharpBuild.Directory.Build.targets fix registered packagedef (#8126) 2020-01-08 11:01:57 -08:00
FSharpTests.Directory.Build.props migrate all `netcoreapp2.x` to `netcoreapp3.0` 2019-10-23 12:16:06 -07:00
FSharpTests.Directory.Build.targets Dependency Manager 2019-09-09 12:07:31 -07:00
INTERNAL.md update insertion link to reflect URL shape change 2019-12-20 10:46:04 -08:00
License.txt
Makefile migrate all `netcoreapp2.x` to `netcoreapp3.0` 2019-10-23 12:16:06 -07:00
NuGet.config add internal package feed (#7951) 2019-12-10 16:07:53 -08:00
README.md [RFC FS-1075] Improve interop to C# nullable-typed optionals (#7989) 2020-02-05 15:35:15 -08:00
Restore.cmd
RoslynPackageVersion.txt Roslyn Shim - Round 2 (#6734) 2019-06-13 12:14:13 -07:00
TESTGUIDE.md improve compiler error message for failed overload resolution (#6596) 2020-02-18 16:40:22 -08:00
Test.cmd
VisualFSharp.sln Even more refactoring of DependencyManagerIntegration (#8518) 2020-02-10 13:27:41 -08:00
attributions.md
azure-pipelines.yml re-enable end-to-end type provider tests (#8539) 2020-02-10 19:54:29 -08:00
build.sh Merge remote-tracking branch 'upstream/dev16.0' into merges/dev16.0-to-master 2019-04-04 15:20:07 -07:00
global.json Update dependencies from https://github.com/dotnet/arcade build 20200213.5 2020-02-14 00:13:37 +00:00
icon.png [master] Update dependencies from dotnet/arcade (#7706) 2019-11-05 15:18:09 -08:00
proto.proj migrate all `netcoreapp2.x` to `netcoreapp3.0` 2019-10-23 12:16:06 -07:00
release-notes.md Update several links (#7055) 2019-06-25 10:13:01 +01:00
restore.sh
test.sh

README.md

The F# compiler, F# core library, and F# editor tools

You're invited to contribute to future releases of the F# compiler, core library, and tools. Development of this repository can be done on any OS supported by .NET Core.

Contributing

Quickstart on Windows

Build from the command line:

build.cmd

The build depends on an installation of Visual Studio. To build the compiler without this dependency use:

build.cmd -noVisualStudio

After it's finished, open either FSharp.sln or VisualFSharp.sln in your editor of choice. The latter solution is larger but includes the F# tools for Visual Studio and its associated infrastructure.

Quickstart on Linux or macOS

Build from the command line:

./build.sh

After it's finished, open FSharp.sln in your editor of choice.

More options and information

See DEVGUIDE.md and TESTGUIDE.md for more details on additional configurations for building and testing, how to update compiler error messages, and more.

No contribution is too small

Even if you find a single-character typo, we're happy to take the change! Although the codebase can feel daunting for beginners, we and other contributors are happy to help you along.

Build Status

Branch Status
master Build Status

Using nightly releases in Visual Studio

You can use the latest master build of the F# compiler and tools for Visual Studio via our nightly releases if you are a Visual Studio user. See details on setup here:

https://blogs.msdn.microsoft.com/dotnet/2017/03/14/announcing-nightly-releases-for-the-visual-f-tools/

Even more nightly than the nightly

Alternatively, if you really want to live on the bleeding edge, you can set up a nightly feed for the Visual Studio preview releases, which use the latest commit in the preview branch. To do so, follow the same instructions as the above blog post, but instead with these links:

Branches

These are the branches in use:

  • master

    • Most contributions go here.
    • Able to be built, installed and used in the latest public Visual Studio release.
    • May contain updated F# features and logic.
    • Used to build nightly VSIX (see above).
    • Gets integrated into https://github.com/fsharp/fsharp to form the basis of Mono releases
    • Gets integrated into https://github.com/fsharp/FSharp.Compiler.Service to form the basis of FSharp.Compiler.Service releases
  • dev15.9

    • Long-term servicing branch for VS 2017 update 15.9.x. We do not expect to service that release, but if we do, that's where the changes will go.
  • dev16.x

    • Latest release branch for the particular point release of Visual Studio.
    • Incorporates features and fixes from master up to a particular branch point, then selective cherry-picks.
    • May contain new features that depend on new things or fixes in the corresponding forthcoming Visual Studio release.
    • Gets integrated back into master once the corresponding Visual Studio release is made.

F# language and core library evolution

Evolution of the F# language and core library follows a process spanning two additional repositories. The process is as follows:

  1. Use the F# language suggestions repo to search for ideas, vote on ones you like, submit new ideas, and discuss details with the F# community.
  2. Ideas that are "approved in principle" are eligible for a new RFC in the F# language design repo. This is where the technical specification and discussion of approved suggestions go.
  3. Implementations and testing of an RFC are submitted to this repository.

Additional project documentation

The following links can help you get an overview of some technical aspects of the F# language and compiler:

License

This project is subject to the MIT License. A copy of this license is in License.txt.

Code of Conduct

This project has adopted the Contributor Covenant code of conduct to clarify expected behavior in our community. You can read it at CODE_OF_CONDUCT.

Get In Touch

Members of the F# Software Foundation are invited to the FSSF Slack. You can find support from other contributors in the #compiler and #editor-support channels.

Additionally, you can use the #fsharp tag on Twitter if you have general F# questions, including about this repository. Chances are you'll get multiple responses.

About F#

If you're curious about F# itself, check out these links: