Problem matchers should restore problems on close

[dbaeumer]

For a detailed discussion see #47386

This branch https://github.com/Microsoft/vscode/tree/dbaeumer/47386 has still the correct start of work.

[dbaeumer]

I looked into this again and this is not fixable in the task / problem matcher land without coordination of the plugin providing life diagnostics. There reason is that I have no idea when to restore them since I don't know when the pluging takes the life diagnostics away and they have the same owner.

[dbaeumer]

@mjbvz we need to think about another solution. Have you checked with the TS team about their builder work. We could also leverage the new Custom task execution which would give the TypeScript plugin full control over this.

[mjbvz]

After syncing with TS, I am not confident that we will have usable full project errors for at least a few more months and possibly longer

[dbaeumer]

@mjbvz any proposal here. The problem is that the problem matcher doesn't know when the TypeScript extensions removes the problems when a file close. If I restore them to early you will remove them. If I restore them too late it will flicker.

[mjbvz]

My proposal was to track where diagnostics come from. Mark errors that come from the problem matcher and always keep those around but hide them if an extension provides its own set of errors for a given file. The vs code task/error logic would be responsible for de-duplicating these

[dbaeumer]

How would we generically do this withouyt the extension letting us know which ones to map (e.g. owner) or by annotation diagnostics as 'lively' (when the come from a server) and 'static' if the come from a problem matcher. I am not against this but it needs to my understanding additional API (an tag or property on diagnostics).

I also think that we shouldn't go down the path of deduping since it causes problems with timing and especially the use of different version (e.g. the build task running on a different version than the language server).

[dbaeumer]

I had a discussion about this with C/C++ folks and one idea they had is to clearly distinguish between problems that are reported from a builder (e.g. a task that runs or a full build performed by a language server) and problems reported by a reconciler that usually validates one file. If we had such a separation we could do the following:

• if reconciler problems come in for a file they always replace builder problems
• we remember builder problems with the version number of that file
• as long as the file is open we only update the reconciler problems and ignore builder problems
• if the file closes we remove the reconciler problems and apply builder problems.

This avoid deduping problems and removes problems around timings since it is clear who owns which kind of problems.

@mjbvz what do you think. Such an approach however would require additional API and work in the problem service.

[mjbvz]

Yes, I believe that would also solve the issue of duplicate problems for JavaScript and TypeScript

[dbaeumer]

That is great. I opened #74524

[russelldavis]

Just a note for reference: this is partially addressed by df97bc3 (and #183172) but it does involve some flicker.