Perf: async project invalidation + debounce script updateProjectOptions

[xperiandri]

Summary

Two perf fixes in FSharpProjectOptionsManager.fs:

1. Fixes Perf: .Result blocks MailboxProcessor thread in FSharpProjectOptionsManager #20125 — .Result blocking calls in hasDependentVersionChanged/isProjectInvalidated were blocking the single-threaded MailboxProcessor loop. Converted to async cancellableTask flow.
2. Fixes Perf: Debounce script updateProjectOptions (fires on every caret move) #20124 — script updateProjectOptions fired on every caret move. Added a 500ms debounce using a swapped CancellationTokenSource and Task.Delay.

Testing

Built successfully; deployed and validated in RoslynDev hive with CPU profiling.

[T-Gro]

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

Focused on the two perf changes. The async/debounce conversions look correct; the main concerns are around the new emitCache lifetime and a couple of concurrency/disposal details noted inline.

[T-Gro]

Unbounded memory growth (regression vs. the old ConditionalWeakTable). The inner ConcurrentDictionary<VersionStamp, FSharpReferencedProject> is only ever cleared when the whole project is removed (emitCache.TryRemove(projectId)) or on ClearAllCaches. There is no per-version eviction, so every distinct dependent version of a referenced C# project produced during a session adds a new entry that is retained for the lifetime of the reactor — and each entry strongly holds an FSharpReferencedProject whose DelayedILModuleReader can pin emitted metadata bytes. The original weakPEReferences (ConditionalWeakTable<Compilation, _>) was self-cleaning: entries died when the Compilation was GC'd. This change trades a churn problem for an unbounded leak while a C# project is actively edited. Consider bounding this (e.g. keep only the latest stamp per project, or an LRU of size 1–2), since only the most recent version is normally useful.

[T-Gro]

Race on cache initialization. emitCache.[projectId] <- versionCache unconditionally overwrites. createPEReference runs inside cancellableTask flows that can execute concurrently, so two threads racing on the same (or interleaved) projectId can each create a fresh versionCache and clobber the other's — losing already-inserted references and creating divergent caches. Use emitCache.GetOrAdd(projectId, fun _ -> ConcurrentDictionary<_,_>()) and then operate on the returned instance, so the whole method has a single get-or-add path rather than two duplicated branches.

[T-Gro]

createPEReference runs through work that the reactor mailbox awaits. The mailbox serializes this path, so the reported initialization race is not reachable. GetOrAdd can simplify the code, but it does not fix a verified race.

[T-Gro]

Final CancellationTokenSource is never disposed. Each updateProjectOptions call disposes the previous CTS when swapping, but the last CTS stored in debounceCts (after the trailing caret move / on teardown) is never cancelled or disposed, leaking a CancellationTokenSource (and its registrations) per script view. Consider disposing debounceCts when the subscription/view is torn down. Also note the delayed async swallows the TaskCanceledException from Task.Delay via Async.Start's cancellation handling, which is fine — but relying on that is worth a brief comment.

[T-Gro]

Async.Start does not make this cancellation safe. The next callback can dispose the source before the queued workflow reads cts.Token. This race terminates the process with ObjectDisposedException. Capture the token before the exchange and handle cancellation explicitly.

[T-Gro]

This cache key ignores the current Compilation. A source-generator refresh can change the public API without changing the dependent version. The cached PE then stays stale. Include compilation or generator state in the key.