LSP: Mechanism for keeping workspace/solution state

[0101]

Use ProjectQuery API to construct initial state + subscribe for updates.
Use incoming documentOpen / Closed / Changed notifications to keep track of solution state.
Try to build this on top of FSharpProjectSnapshot.

[nojaf]

Hi,

Yesterday, @0101, @auduchinok, and I had a chat about bringing the Transparent Compiler into Rider. We focused on how the new ProjectSnapshot setup changes the way we keep track of everything.

Here's the deal: When we make a ProjectSnapshot, each file gets a timestamp or version. This helps the system remember things, and when a file gets updated, it needs a fresh version in the snapshot. Updating a file means making a new FileSnapshot and using the .Replace function to refresh the snapshot.

This is okay but gets complicated when we talk about projects that depend on each other. Because snapshots include the projects they depend on, if you change one file, you theoretically need to update everything. Imagine having 300 projects; typing in one file would mean all those snapshots need an update every time you press a key.

From what I understand, Visual Studio doesn't rush to update everything right away when a file changes. It waits until the snapshot is needed for something before it updates it.

Our plan for now is to have a system on Rider's side that makes ProjectSnapshots from ProjectOptions. When a file changes, this system would get rid of the outdated snapshots, which helps us avoid making too many new ones. This might be a good first step for using the Transparent Compiler with Rider, but it seems like something all IDEs will have to figure out.

This is where the idea of a new Workspace comes in. It would be awesome if we could use this setup to ask for snapshots since the FSharpChecker should always work with snapshots. So, if I need type check info for a file, I could ask the Workspace for the snapshot using the project key (project name + TFM), get the snapshot, use FSharpChecker, and get my answers. And when a file changes, I just tell the Workspace. It would handle whatever needs to be done.

sequenceDiagram
    participant IDE as IDE
    participant Workspace as Workspace
    participant FSharpChecker as FSharpChecker

    IDE->>Workspace: Request ProjectSnapshot (project key)
    Workspace-->>IDE: ProjectSnapshot
    IDE->>FSharpChecker: Get information (ProjectSnapshot)
    FSharpChecker-->>IDE: Information results

    IDE->>Workspace: File changed
    IDE->>Workspace: Project options changed
    IDE->>Workspace: Assembly changed

Loading

This seems like a smart way to manage snapshots across different editors. The Workspace shouldn't be tied down to LSP; it should work with everything or be easy to plug into. Each editor (VS, Ionide, and Rider) could throw in their two cents on what they need from the Workspace, and we could build something that works for everyone.

@0101 had a cool idea yesterday about trying something called adaptive programming inside the Workspace. This could make handling changes across projects smoother. The thought is that the Workspace could know about file changes from the editor and only update things in a project when someone asks for that project's snapshot. It's just an idea, and I'm not sure if it's possible, but it's worth thinking about.

(//cc @TheAngryByrd & @baronfel for FSAC input)

[vzarytovskii]

Yeah, that was the general idea - abstract it away so it's easy to work with it in some abstract editor/IDE.

[0101]

Initial version of this it done, in the lsp branch. Further work on it can be done as we move along with all the LSP features and discover what else is needed there.

I propose to also merge FSharpWorkspace to main so it's easier for people to experiment with. It's not necessarily tied to LSP and can be used stand-alone as an alternative (and possibly more convenient) API for FCS.