F# and F# tools update for Visual Studio 16.10

Phillip Carter

We’re excited to announce updates to the F# tools for Visual Studio 16.10. For this release, we’re continuing our trend of improving the F# experience in Visual Studio to build upon what was released in the VS 16.9 update last February.

  • Support for Go to Definition on external symbols
  • Better support for mixing C# and F# projects in a solution
  • More quick fixes and refactorings
  • More tooling performance and responsiveness improvements
  • More core compiler improvements

Let’s dive in!

Go to Definition on external symbols

This one’s been a long time coming. We’ve had a feature request since 2016 and several trial implementations throughout the years. Now it’s here!

As shown in the video, you can either use the f12 key or ctrl+click to navigate to a declaration, just like in source code in your own solution.

When you navigate, Visual Studio generates a complete F# Signature File that represents the module or namespace that the symbol lives under, with XML documentation if it is present. This allows colorization, tooltips, and further navigation to work exactly as if they had been declared as signature files in your own codebase.

Better mixing of C# and F# projects in your solution

One of the biggest annoyances when working with C# and F# projects that interoperate in the same codebase is that you need to rebuild projects to see updates in other projects if they cross the C# <-> F# boundary.

Starting with the VS 16.10 release, if you make a change to a C# project, you don’t need to rebuild it to see changes in an F# project!

As shown in the video, I can make any modification and immediately see changes in the F# project.

The inverse is still not true today, and there remains more work to be done to make the C# <-> F# interop boundaries clean from a tooling standpoint. To summarize the current state of things, here’s a checklist:

  • ✔️ F# projects can “see” changes in C# projects without rebuilding
  • ✔️ You can Go to Definition on any C# symbol from F# and navigate to that spot in a C# codebase
  • ❌ C# projects cannot “see” changes in an F# project without rebuilding
  • ❌ You cannot Go to Definition on any F# symbol from C# and navigate to that spot in the F# codebase

We’re doing more work to turn the remaining crosses into green check marks. The work is quite low-level and starts with some changes to the F# compiler and will likely also involve changes in the C# tooling as well.

XML documentation scaffolding

At the start of Visual Studio 2019, we disabled a feature that allowed you to scaffold XML documentation in source due to performance concerns. The implementation was found to be a significant source of UI delays, which could be detrimental to an overall Visual Studio experience, especially if combined with large memory consumption.

Over the span of Visual Studio 2019, we’ve made big strides in performance for the F# tools, including changing the implementation of the XML documentation scaffolding feature so it doesn’t impact UI delays anymore. So it’s now re-enabled!

You can trigger it by typing the < character within a triple-slash comment at the top of a construct, like the following video will demonstrate.

More quick fixes and refactorings

Like the last release, we’re bringing in some more quick fixes and refactorings for the VS 16.10 release!

Remove unused binding quick fix

If you have an unused binding in any scope, we’ll offer to remove it for you if it’s considered removable:

Remove unused binding code fix

Use proper inequality operator quick fix

Some beginners from other languages might use != and get confused by the error it produces. This quick fix will correct their operator usage to use <>:

Use proper inequality operator code fix

Add type annotation to object of indeterminate type quick fix

The F# compiler can give a confusing error, where code technically doesn’t compile, but the F# tools can actually infer a type that the compiler can’t. This quick fix will bring that known type into a suggestion:

Add type annotation to object of indeterminate type quick fix, F# and F# tools update for Visual Studio 16.10

Add type annotation refactoring

Finally, we’ve added the first refactoring in the F# tools for Visual Studio. Refactorings are different from quick fixes in that they aren’t triggered by warnings or errors. Instead, lightbulbs (with no error icon next to them) indicate that a code refactoring is available at your cursor position.

Add type annotation refactoring

Even more tooling performance and responsiveness

Just like the past several Visual Studio releases, we’re continuing to chip away at tooling performance and responsiveness for larger codebases.

Reduced memory usage

We identified another “win” for memory usage for large solutions. When Visual Studio colors constructs in an open document, this is actually the result of a process known as “classification”. Classification runs in two passes:

  1. Syntactical classification
  2. Semantic classification

Syntactical classification can do things like identify keywords from non-keyworks. It’s very lightweight because it doesn’t require typechecking anything. You may notice for a very, very large file that keywords are colored before types are colored.

Semantic classification is an expensive operation. It does things like distinguish classes, structs, enums, methods, properties, etc. The end result is more nuanced colorization in a document. However, since it is typically the first semantic operation kicked off by a language service, it also fills caches.

One of the caches used by semantic classification is the actual classification information itself. This information used to be stored in one big array. This could consume significant RAM over time (especially if you have a lot of large documents open). To address this, we backed the data with a memory-mapped file, an approach we’ve taken for several other large stores of data in the F# tools for Visual Studio. This has lead to savings of up to 200MB in the F# codebase, depending on how many files are open in a Visual Studio session.

This change was contributed by Saurav Tiwary. Thanks, Saurav!

More IDE features respond immediately

Last release, we started some work in the F# language service to make requests for semantic information no longer serial. As a refresher, the machinery involved serializes requests that require semantic information because there may be a circumstance where a typechecking operation can have downstream effects. It uses a queue to process requests in order. In practice, however, this approach is rarely necessary. In this release, we’ve pulled even more operations off of this queue.

With these changes, you should notice that tooling features in larger codebases react to your inputs faster than before, especially in larger codebases.

Core compiler improvements

Finally, we’ve got some more compiler improvements to share!

Support for WarnOn in project files

Prior to this release, if you wanted to introduce warnings for specific compiler codes, you’d have to use --warnon:number in an OtherFlags property in your project file.

You can now just use WarnOn and pass the numbers directly in, just like in C#.

This was implemented by Chet Husk. Thanks, Chet!

Support for ApplicationIcon in project files

Prior to this release, setting ApplicationIcon in F# project files would do nothing.

Now, you can set this property in a project file just like in C#. A compiler flag, --win32icon, was also added.

This was implemented by albert-du. Thanks!

More span optimizations

Jérémie Chassaing implemented a lovely optimization for looping over a Span/ReadOnlySpan.

The following F# code:

let sumArray (vs: int ReadOnlySpan) =
    let mutable sum = 0
    for i in 0 .. vs.Length-1 do
        sum <- sum + vs.[i]
    sum

Now emits cleaner IL that removes a bounds check, allowing the runtime to more aggressively optimize the loop. This optimization also applies to for x in xs do loops.

Looking forward

With this release, we’re officially shifting gears to support three initiatives:

  1. Great support for F# in .NET 6
  2. Great support for F# in .NET Interactive
  3. Great support for F# in Visual Studio 2022

For the first initiative, we’re going to lock down on the language features we intend on releasing with soon. We’re not intending on adding many language features this time. We feel that there is more value in core compiler improvements and core tooling improvements (F# interactive, Visual Studio) right now. .NET 6 is an LTS release, we’re prioritizing existing feature-completeness, performance, and reliability. That doesn’t necessarily mean a feature freeze. In fact, we may also end up releasing a “compiler feature” or two, especially when related to improving build times. But it does mean that the set of new language features will be smaller when compared to F# 5. When we have a finalized set of language changes going into .NET 6, we’ll announce it and the version number that we’ll assign the release.

For the second initiative, we’re focused mainly on making sure that F# code gives great output (plaintext, charting), has great tooling (intellisense, tooltips), and gives a good experience using a broad set of libraries, especially those tailored towards data science and machine learning. To that end, we’ve already accomplished much of what we intend to do, especially in supporting some exotic package layouts for bringing in different packages with native dependencies. But there is still work to be done, such as ensuring tooling experiences (completion, tooltips, etc.) all work well. We’re committed to delivering an incredible F# experience when .NET Interactive releases in GA.

Lastly, we’re heavily focused on making sure we deliver a great F# experience in Visual Studio 2022. Since Visual Studio 2022 is going to be 64-bit, that means that there will be higher memory usage when compared to today. We have a lot of performance analysis work ahead of us. Our preliminary builds indicate that memory usage is ~2x when loading the F# codebase and running an expensive operation like Find All References. We are committed to bringing this factor down as much as possible. On top of that, we want to continue to iterate on Visual Studio productivity features and bring features like Inline Hints, better C# interop, faster build times, and more.

Stay tuned, and happy F# coding!

9 comments

Discussion is closed. Login to edit/delete existing comments.

  • Gauthier Segay 0

    This update looks stellar (thanks to all contributors) and what’s ahead too!

    You cannot Go to Definition on any F# symbol from C# and navigate to that spot in the F# codebase

    There is a great loophole to escape that reality, that I’ve been using since I use Visual F#, it applies to all those who enjoy “develop with pleasure” (or adopted “the drive to develop” on the late) that have Resharper installed, it will bring you to the correct F# file, it is just a matter of copying the identifier and incrementally searching for it (since F# code is order dependendent, it will be first hit) before issuing the navigation and you’ll have you’ “go to definition” from C# to F# working.

    It also works both ways out of the box in Rider since it ships AFAIK, it is up to Roslyn and F# teams to go the extra remaining mile, and I kind of remember Don Syme offered something on twitter to whoever makes it happen in Visual Studio.

  • Jim Horvath 0

    I thought comments starting with 3 forward slashes (///) implied a summary tag? When I have comment docs that need additional tags, I add the tags and revert the comment to the 2-slash form (//). Is that all wrong?

    • Phillip CarterMicrosoft employee 0

      Triple slash comments imply a summary tag, but they don’t get you any other tag. That’s why pressing the

      <

      key will scaffold out the rest. If you only care about the summary, there's no need for this feature.

      • Jack Fox 0

        Just installed 16.10 and ///< does nothing.

        • Phillip CarterMicrosoft employee 0

          I just confirmed that it works on VS 16.10 in a quick test involving a function definition. Could you share a repro to clarify what’s not working?

          • Jack Fox 0

            I found the issue(s)

            It does not work on

            1) module declarations
            ///<
            module MyModule =

            2) super simple let bindings (there has to be some substance to the let binding)
            let x = 1 + 2 // this seems to be hit or miss, sometimes this works

            3) there must be a leading empty line

            let v3D = LinearAlgebra.Vector.Build.Dense(3)
            ///< //does not work
            let vector2 = System.Numerics.Vector2(1.f, 1.f)

            4) once it stops working in a file it seems to stop working even in places it worked before

            Seems to be kind of buggy. I’m not sure I’ve identified the real root causes.

  • Rita Jennings 0

    Has anyone reported F# Interactive no longer working after the Mac upgrade? Mine seems to have and I can’t figure out why.

  • Seref Arikan 0

    Thanks for the updates Phillip. Is this implementation within the set of changes to F# itself we can expect in .Net 6? One can hope, given its status is Candidate for F# next, but I’m not sure if that means making it to .Net 6. Any clues?

  • Luc Cluitmans 0

    I love the improvements in the C# – F# interaction! I’m a bit surprised though not to see my main pet peeve for that interaction in your bullet list of 4 points: doing a “Find usages” on a C# method currently doesn’t “see” that I am calling the C# method from my F# project. So that is the inverse of the “go to definition” that does appear in the bullet list in the article. And, probably related, the code lens above the C# method doesn’t count references from F#.

    Is that feature on the table?

Feedback usabilla icon