Migrate F# to LSP pull diagnostics

[tmat]

Currently F# uses FSharpDocumentDiagnosticAnalyzer, which implements Roslyn's DocumentDiagnosticAnalyzer.

The goal is to replace this with LSP pull diagnostics.

[dsyme]

What is the benefit of doing this? Does it give any advantages?

[tmat]

We are removing DocumentDiagnosticAnalyzer and related legacy diagnostic reporting infrastructure from Roslyn

[dsyme]

We are removing DocumentDiagnosticAnalyzer and related legacy diagnostic reporting infrastructure from Roslyn

Why?

F# spent about 2 years aligning with Roslyn to get win-win, among other things so we didn't have to re-implement an analysis engine. What's the gain here?

[tmat]

Because LSP is the modern architecture and we do not want to maintain alternative legacy implementation that has performance and correctness problems.
This is just the first step on the roadmap to LSP. We will be moving all editor-related Roslyn features to LSP and removing the legacy APIs in future. F# is using a lot of these APIs via External Access layer.

[dsyme]

I see. I know very little about LSP, but never heard of it as "the modern architecture" - I thought it was a bit of a mess from what the Ionide folk have told me. Roslyn seems to give us everything we need doesn't it? What advantages does LSP bring?

I just want to understand what positive customer-facing benefits we're going to see here. How do F# customers gain from something like this? It sounds like an awful lot of work but maybe it's straight-forward. Do we have a model implementation of LSP available anywhere, one that gives the quality and perf characteristics beyond Roslyn?

[tmat]

Roslyn already implements many editor features via LSP. We are currently working on switching our diagnostic reporting fully to LSP. In some scenarios like new ASP.NET Razor editor all editor features are running via LSP. TypeScript, XAML, Python and C++ are also moving to LSP.

The main advantage of LSP is client-server separation. This will allow us to move Roslyn services fully to a separate process and reuse the same implementation on all platforms and for all IDEs we support (VS, VS Mac, VS Code).

[dsyme]

I see, so this solves the out-of-proc question, and we can use the Roslyn LSP implementation as a guide. There are big advantages for F# here, yes. This also matters for F# analyzer support (#11057)

Do you think there is any worth in sharing core parts of the code needed to implement LSP on the LSP-server-side?

Please at some point write us a brief how-to-implement-LSP-server guide (e.g. 5 or 10 links to the core of the Roslyn LSP implementation), to help us get more comfortable with the concept. We've never taken any components out-of-process before and we're not very familiar with that kind of programming in this repo.

[dsyme]

Aside: F# does have an LSP implementation in Ionide. For clarity and community cohesion we'd need to be able to understand whether the long term trajectory is:

1. unite with that
2. provide an equivalent LSP implementation from this repo (and would that be used in Ionide)
3. provide a deliberately trimmed-down LSP implementation only suitable for diagnostic analysis in VS.

Sounds like #3 initially - any LSP implementation would be for VS only - and we'd keep language service features in-memory

[tmat]

Do you think there is any worth in sharing core parts of the code needed to implement LSP on the LSP-server-side?

Possibly. We'll definitely try to help F# team to transition as much as we can.

Please at some point write us a brief how-to-implement-LSP-server guide (e.g. 5 or 10 links to the core of the Roslyn LSP implementation), to help us get more comfortable with the concept. We've never taken any components out-of-process before and we're not very familiar with that kind of programming in this repo.

We'll provide guidelines for each LSP feature as we work on the transition.

[dsyme]

Do you expect this to be limited to diagnostics in the initial iteration? I can see the customer-facing case for pulling other things out-of-proc (reduce VS memory usage) but I'm wondering whether you think of those as necessary from the Roslyn perspective.

Also is there anything coupled here, in the sense forcing this at any particular pace?

[tmat]

The diagnostic reporting is the most important for Roslyn at this point. The other features will follow later on. The timeline is hard to predict.

There are various prerequisites involved. E.g. we need to make sure LSP works on VS Mac and that the LSP protocol has enough features that we can achieve 100% parity with current VS functionality. We are working with other partner teams who use Roslyn APIs as well (TypeScript, Unit Testing, XAML). They will also need to make the switch in order for us to be able to remove the old implementation.

[dsyme]

Ah I see. Yes big long term plan, ok.

[tmat]

F# spent about 2 years aligning with Roslyn to get win-win, among other things so we didn't have to re-implement an analysis engine

BTW, moving F# to LSP does not mean F# can't continue using Roslyn Solution, Projects, Documents, etc. to represent F# source code and projects. Those APIs will continue to be available (they will be running purely out-of-proc though).

We will also provide remote services running in Roslyn's process (where the solution is loaded) that F# LSP server implementation will be able to query for information. The server itself may run in Roslyn's process as well.

Specifically, re diagnostics - the main difference between the current solution crawler infrastructure is following.
The solution crawler is a stateful service that implements rather complex logic that gathers diagnostics from the solution (and to which F# plugs into using FSharpDocumentDiagnosticAnalyzer) and also many layers of caching to optimize for memory and time. Pull diagnostics on the other hand are stateless on the server side. The client is in control of prioritization of requests for diagnostics and sends pull requests to the server as it sees fit. E.g. it sends requests for latest diagnostics for the current view of the focused open document very frequently, while it requests diagnostics for closed documents less frequently. The server's only job is to reply with a set of diagnostics for specific document(s) in very functional way (with no side-effects).

FSharpDocumentDiagnosticAnalyzer currently calls to IFSharpDocumentDiagnosticAnalyzer implementation. It seems like this implementation would work in the new model as well. It's mostly the infrastructure how the diagnostics flow that would change around it.

[dsyme]

Thank you for the notes! It helps so much

. The client ...sends requests for latest diagnostics for the current view of the focused open document very frequently, while it requests diagnostics for closed documents less frequently.

Would we have to implement this logic on the client-side, or would VS/Roslyn/someone-else implement this?