Repository navigation
Duplicate errors in editor produced on language server initialization #49437
Description
Weird symptoms/tips I've already collected.
- Possibly only happens on early hovers when the language service first starts.
- Only happens when the editor (i.e. VS Code) first starts. Restart TS Server does not seem to produce this, but it definitely does not seem to be a VS Code issue given the trace output of the server.
- Server logs available here.
- Seems to only repro on
typescript@4.7.0-dev.20220325and doesn't repro on the previoustypescript@4.7.0-dev.20220323.- This query may give a hint here
- Merge diagnosticsProducing and nonDiagnosticsProducing checkers into a single checker supporting lazy diagnostics #36747 seems possibly related
The following code:
let lololol = 123;
lololoSeems to produce two duplicate errors:
Activity
DanielRosenwasser commentedon Aug 16, 2022
I figured out the failing test case. It has to do with whether semantic classification is requested before diagnostics come back. Here's a failing test case.
If you comment away the semantic classifications call
then the test passes.
DanielRosenwasser commentedon Aug 16, 2022
Okay, here's what I think happened:
TypeScript has a bug around not deduplicating diagnostics that have related spans. Andrew Branch (@andrewbranch) discovered that independently 1-2 weeks ago, but QuickFix:
Fix all detected spelling errorsnot working #50243 was recently filed and Ignore related info in diagnostic deduplication #50309 aims to fix the problem.Often this was not noticed because every program had two type-checkers. On the command line, the type-checker ran in a relatively predictable fashion on entire files. In editing scenarios, any type-checking diagnostics were ignored (I think - or maybe there was a memory leak). However, in Merge diagnosticsProducing and nonDiagnosticsProducing checkers into a single checker supporting lazy diagnostics #36747, Wesley Wigham (@weswigham) switched to just one type-checker. It seemed suspicious when I bisected, but ultimately I don't think anything went wrong here. It just uncovered this bug in our deduplication code.
So what I believe is happening is that an operation like semantic classification is walking/checking the visible region of the editor, and that adds new errors to the error list. When the server starts serving the
geterrrequest, then it has that leftover error.This bug only shows up in certain scenarios because what part of the file you're viewing tends to affect when a semantic classifications request may come in. If you scroll away fast enough, you might not see the dupes. If you restart TS Server, the editor doesn't re-request semantic classifications right now (I touched on this at Inlay hints should be requested on all open files (similarly to diagnostics) vscode#130430 (comment) - I'm not sure if Matt Bierner (@mjbvz) and Johannes Rieken (@jrieken) want to take an optimistic view on semantic classification, though I understand if we want to given that it can be relatively costly to recalculate on all editors).
I do think that #50309 should fix this though.