Change:
return this.map.has(value); } } <ins> /** * A map that allows access both by keys and values. * **NOTE**: values need to be unique. */ export class BidirectionalMap<K, V> { private readonly _m1 = new Map<K, V>(); private readonly _m2 = new Map<V, K>(); constructor(entries?: readonly (readonly [K, V])[]) { if (entries) { for (const [key, value] of entries) { this.set(key, value); } } } clear(): void { this._m1.clear(); this._m2.clear(); } set(key: K, value: V): void { this._m1.set(key, value); this._m2.set(value, key); } get(key: K): V | undefined { return this._m1.get(key); } getKey(value: V): K | undefined { return this._m2.get(value); } delete(key: K): boolean { const value = this._m1.get(key); if (value === undefined) { return false; } this._m1.delete(key); this._m2.delete(value); return true; } forEach(callbackfn: (value: V, key: K, map: BidirectionalMap<K, V>) => void, thisArg?: any): void { this._m1.forEach((value, key) => { callbackfn.call(thisArg, value, key, this); }); } keys(): IterableIterator<K> { return this._m1.keys(); } values(): IterableIterator<V> { return this._m1.values(); } } </ins>

Discussion:
I wonder why all of line 14 becomes gray (i.e. unused) after I remove line 13. I guess this is because the decorations of line 13 get applied to line 14 which becomes line 13. I think we can improve this by listening to text edits and updating the cache accordingly - when a line is deleted, its decorations should be deleted too and not just applied to whatever lines becomes the deleted line. ! Another example: !
This is for TypeScript: ! And this for JSON: ! This indicates that this is indeed a problem of TypeScript, and not diagnostics in general (
how about a small TS repro sample?
!
Looks pretty normal here. Also just checked with that TypeScript uses plain diagnostics. Can be because of another setting/feature that interfers here? https://user-
Interesting. It also happens when I reset all my settings, but it only happens in the VS Code repository (but there every single time)...
I can't reproduce any problems when there is a single diagnostic present. Having a single diagnostic updates great: Using the following sample in an untitled file in the repo: ts /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ const x = 3; ('' x + '' / 3); https://user- However, when removing the trailing such that also creates a diagnostic, I can see that the squiggle gets out of sync. I suspect that is constantly updating its diagnostic, while is not. Most likely, the fact that updates its diagnostic results in firing and the re-reading the markers from it and re-applying them. The marker goes to the right spot since it was newly refreshed by , but the marker goes to its original spot since didn't update it: https://user- To tackle this and only update the decorations for a certain diagnostics provider, the events would need to be more fine-grained and then could selectively update decorations by owner.
That's a nice find!
A cheap solution here would be for markers to record a model version id at the time they are set in the marker service. The could then read the markers and recreate squiggles only for the markers which are "fresh".
Yeah, that will work but there is no guarantee for this - since markers can be pushed for any resource.

Tho, in this case it will help
adds (which can be undefined tho)
Added the version to markers, un-assigning myself to leave the remaining work to