Cache DocumentDiagnosticAnalyzer results by version stamp to avoid redundant typecheck on unchanged documents

[xperiandri]

Fixes #20120

Summary

FSharpDocumentDiagnosticAnalyzer.GetDiagnostics previously recomputed syntax/semantic diagnostics (parse, typecheck, UnusedParentheses) on every crawler pass, even when the document text and project state had not changed since the last computation.

This adds a version-stamp-aware cache keyed by struct (DocumentId * DiagnosticsType), storing the last computed (textVersion, projectVersion, ImmutableArray<Diagnostic>) tuple:

• For Syntax diagnostics, only the document textVersion is tracked (projectVersion uses VersionStamp.Default).
• For Semantic diagnostics, both textVersion and document.Project.GetDependentVersionAsync() are tracked.
• If the current versions match the cached entry, the cached diagnostics are returned directly, skipping parse/typecheck/UnnecessaryParenthesesDiagnosticAnalyzer work entirely.

This mirrors the versioned-cache pattern used for referenced-project compilation emission in FSharpProjectOptionsManager.fs (emitCache).

Testing

• dotnet build vsintegration/src/FSharp.Editor/FSharp.Editor.fsproj -c Debug — succeeded.
• Deployed to RoslynDev hive (Build.cmd -c Debug -deployExtensions) and validated with a CPU trace of devenv.exe.

[T-Gro]

🤖 This review was generated by AI (@expert-reviewer agent). Findings may contain inaccuracies — please verify independently.

[T-Gro]

Unbounded static cache / memory retention. This static ConcurrentDictionary is keyed by struct (DocumentId * DiagnosticsType) and has no eviction path. Edits to the same document overwrite their own key, so growth is bounded by the number of distinct documents ever opened (×2 for Syntax/Semantic) — but entries for documents that are closed or removed from the solution are never freed and persist for the entire lifetime of the devenv.exe process. Each retained entry holds an ImmutableArray<Diagnostic> (with Location/file-path data), so in a long-running session over a large solution this is steady, unbounded retention.

Consider evicting on workspace changes — e.g. subscribe to Workspace.WorkspaceChanged and drop entries on DocumentRemoved/DocumentRemovedFromSolution (and optionally when a document is closed), or cap the cache size. The referenced emitCache in FSharpProjectOptionsManager.fs is keyed by project reference and thus has far smaller cardinality than per-document diagnostics, so the retention surface here is larger.