[Experimental] Sources supplied by VS instead of file system

[0101]

Added experimental FSharpChecker APIs:

New parameters to FSharpChecker.Create

• Optional getSource function filename: string -> ISourceText option
  • When this is provided it will be used to get the source text instead of reading it from the file system
• useChangeNotifications: bool switch
  • When this is set to true (default is false) then FSharpChecker will not be looking at the file system to check file timestamps. Instead it will expect NotifyFileChanged method to be called whenever a source file is changed. Or alternatively requesting parsing/checking of a changed file right away.

New method NotifyFileChanged

• To be used with useChangeNotifications = true to notify about file updates

New VS option to use these new APIs

When you opt-in, VS will use Roslyn Document API to supply the source text. Which means it will be coming from live buffers in case of open documents. And it will use the workspaceChanged event to notify about file changes, which covers even changes that happen outside VS in the file system, as it already has a watcher for that.

---

Changes to other dependencies that F# source files are handled the same way as before.

[auduchinok]

@0101 What do you think about having some public API that is similar toSetFileEditTimeStamp? FCS clients could use it when a source file is edited or an assembly is updated on disk. That would optionally allow not checking all the timestamps every time, if the client is going to notify FCS about all the changes.

[0101]

@auduchinok yeah I think that could make sense. At the moment it's checking the timestamps a lot. (Not really sure how expensive that is yet.)

But I was thinking for it to be pull based, where you can supply a filename -> timestamp function optionally. And if you don't we fallback to checking the filesystem, so that everyone is not forced to do that. (Or rather maybe filename -> FSharpSource)

At the same time if a file is changed, you're going to want to have it parsed/checked, so we will know anyway at that point. So the notification API would be more useful non-F#-source dependencies.

But I suppose another way could be that you would create an FSharpChecker( useChangeNotifications=true ) and then it would expect to be notified about everything.

[auduchinok]

But I suppose another way could be that you would create an FSharpChecker( useChangeNotifications=true ) and then it would expect to be notified about everything.

Yes, this is something I had in mind when writing that comment. 🙂

[0101]

I'm restarting this effort. Even though it's not really in line with our ultimate goal (immutable snapshot compilations), it can be achieved pretty easily and get functional improvements right away. Renaming especially is quite broken now if you forget to save your files.

• VS analyses with respect to saved files, not live buffers #5915
• Inline Rename does not work on non-private symbols on dirty buffers #2204

[0101]

The included benchmark shows that at least on the FCS level the performance wasn't affected by these changes. (Unfortunately I don't know how to do VS benchmarks yet.)

BenchmarkDotNet=v0.13.2, OS=Windows 10 (10.0.19045.2311)
AMD Ryzen 9 5900X, 1 CPU, 24 logical and 12 physical cores
.NET SDK=7.0.100
[Host] : .NET 7.0.0 (7.0.22.51805), X64 RyuJIT AVX2 DEBUG
Job-GXZWPY : .NET 7.0.0 (7.0.22.51805), X64 RyuJIT AVX2
InvocationCount=1 IterationCount=8 UnrollFactor=1
WarmupCount=1

Method	Use GetSource	Use Change Notifications	Mean	Error	StdDev	Gen0	Gen1	Allocated
ExampleWorkflow	False	False	3.688 s	0.0251 s	0.0131 s	8000	1000	3.33 GB
ExampleWorkflow	False	True	3.687 s	0.0391 s	0.0204 s	8000	1000	3.33 GB
ExampleWorkflow	True	False	3.738 s	0.0435 s	0.0228 s	8000	1000	3.34 GB
ExampleWorkflow	True	True	3.653 s	0.0955 s	0.0500 s	8000	1000	3.34 GB

[vzarytovskii]

@0101 if the api is experimental/temporary, please mark it with ExperimentalAttribute.

[0101]

@0101 if the api is experimental/temporary, please mark it with ExperimentalAttribute.

That's what I did!

[vzarytovskii]

@0101 if the api is experimental/temporary, please mark it with ExperimentalAttribute.

That's what I did!

Oh, my bad - I, as usual, looked only on the implementation file and ignored the signature.

[auduchinok]

When this is set to true (default is false) then FSharpChecker will not be looking at the file system to check file timestamps. Instead it will expect NotifyFileChanged method to be called whenever a source file is changed. Or alternatively requesting parsing/checking of a changed file right away.

Could we also notify FCS about referenced assemblies timestamp changes?

[0101]

When this is set to true (default is false) then FSharpChecker will not be looking at the file system to check file timestamps. Instead it will expect NotifyFileChanged method to be called whenever a source file is changed. Or alternatively requesting parsing/checking of a changed file right away.

Could we also notify FCS about referenced assemblies timestamp changes?

I'm actually not sure if we could use that to any benefit. Since that info needs to be passed via FSharpProjectOptions on each call to the checker. But I didn't really dig into how the referenced assemblies are processed yet.

[auduchinok]

I'm actually not sure if we could use that to any benefit.

Assembly timestamps are often checked the same way as sources IIRC, at least it's how it used to be and I don't remember any changes here. Not having to check hundreds of referenced assemblies could be good here.

[0101]

Assembly timestamps are often checked the same way as sources IIRC, at least it's how it used to be and I don't remember any changes here. Not having to check hundreds of referenced assemblies could be good here.

I'd probably try to look at that separately. The goal of this is to make it possible to work with unsaved files in the editor. I don't think there are even any noticeable performance benefits. The filesystem is still pretty fast compared to parsing / checking.

[T-Gro]

Looks good to me.