One eager diagnostic provider can influence others negatively

[hediet]

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:

[hediet]

This is for TypeScript:

And this for JSON:

This indicates that this is indeed a problem of TypeScript, and not diagnostics in general (@jrieken).

[jrieken]

@hediet how about a small TS repro sample?

[hediet]

console.log("" 


"test")

[jrieken]

Looks pretty normal here. Also just checked with @mjbvz that TypeScript uses plain diagnostics. Can be because of another setting/feature that interfers here?

Screen.Recording.2022-10-10.at.18.07.47.mov

[hediet]

Interesting. It also happens when I reset all my settings, but it only happens in the VS Code repository (but there every single time)...

[alexdima]

@jrieken I can't reproduce any problems when there is a single ts diagnostic present. Having a single ts diagnostic updates great:

Using the following sample in an untitled file in the vscode repo:

/*---------------------------------------------------------------------------------------------
 *  Copyright (c) Microsoft Corporation. All rights reserved.
 *  Licensed under the MIT License. See License.txt in the project root for license information.
 *--------------------------------------------------------------------------------------------*/

const x = 3;
console.log('' 
                       + x + '' / 3);

Kapture.2022-10-11.at.17.01.41.mp4

---

However, when removing the trailing ; such that eslint also creates a diagnostic, I can see that the ts squiggle gets out of sync. I suspect that eslint is constantly updating its diagnostic, while ts is not. Most likely, the fact that eslint updates its diagnostic results in IMarkerService.onMarkerChanged firing and the MarkerDecorationsService re-reading the markers from it and re-applying them. The eslint marker goes to the right spot since it was newly refreshed by eslint, but the ts marker goes to its original spot since ts didn't update it:

Kapture.2022-10-11.at.17.05.42.mp4

---

To tackle this and only update the decorations for a certain diagnostics provider, the IMarkerService events would need to be more fine-grained and then this code could selectively update decorations by owner.

[jrieken]

That's a nice find!

[alexdima]

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 MarkerDecorationsService could then read the markers and recreate squiggles only for the markers which are "fresh".