Avoid caching resolved signatures for language service requests like signature help

[Mateusz Burzyński (Andarist)]

fixes #49624

cc Andrew Branch (@andrewbranch)

[Mateusz Burzyński (Andarist)]

perhaps this blocking wrapper should be moved to getResolvedSignatureWorker (to be called conditionally)? I didn't want to incur a closure penalty there though (maybe that's negligible?)

[Nathan Shively-Sanders (sandersn)]

Does it need to be conditional? Currently 2 out of 3 callers of getResolvedSignatureWorkers need to skip the cache, so I suspect that the 3rd caller also needs to. It's worth checking out and trying.

The wrapper-like nature of runWithInferenceBlockedFromSourceNode might also be better if inlined, although it's used in getContextualType as well. I would inline and duplicate the wrapper functions to see if it looks better (and perhaps, runs faster).

[Mateusz Burzyński (Andarist)]

Does it need to be conditional? Currently 2 out of 3 callers of getResolvedSignatureWorkers need to skip the cache, so I suspect that the 3rd caller also needs to. It's worth checking out and trying.

The 3rd call doesn't look LSP-related - more like a type-checking one. So I assumed that this one doesn't need this and might actually don't want this as for "real" type-checking purposes we want to cache things.

Admittedly, I confused myself and thought that getResolvedSignatureWorker is the getResolvedSignature (*Worker functions are often used within the "core" type checking algorithm) and that the "core" type checking calls into that. I considered this to be a hot path and thus wanted to avoid adding extra things there.

The wrapper-like nature of runWithInferenceBlockedFromSourceNode might also be better if inlined, although it's used in getContextualType as well. I would inline and duplicate the wrapper functions to see if it looks better (and perhaps, runs faster).

Since this blocking~ is only relevant for LSP requests - does perf matter that much here? I would consider this to be less of the hot path (maybe I'm wrong though) and wouldn't be bothered as much with inlining and comparing perf. Let me know what you think.

[Nathan Shively-Sanders (sandersn)]

Nice fix for a tricky bug! Couple of suggestions.

[Nathan Shively-Sanders (sandersn)]

Does it need to be conditional? Currently 2 out of 3 callers of getResolvedSignatureWorkers need to skip the cache, so I suspect that the 3rd caller also needs to. It's worth checking out and trying.

The wrapper-like nature of runWithInferenceBlockedFromSourceNode might also be better if inlined, although it's used in getContextualType as well. I would inline and duplicate the wrapper functions to see if it looks better (and perhaps, runs faster).

[Mateusz Burzyński (Andarist)]

Nathan Shively-Sanders (@sandersn) Daniel Rosenwasser (@DanielRosenwasser) I pushed out some changes to the structure of the code. Overall, I don't think we need to juggle things more - but that's subjective. Yes, there is some duplication of the work done in runWithInferenceBlockedFromSourceNode and in runWithoutResolvedSignatureCaching but that's a fairly simple ancestry lookup and this is only relevant for LSP requests~. I think that it's not exactly a hot path and that we don't have to be worried about it. Let me know what do you think.

[Andrew Branch (andrewbranch)]

Very excited to have this fixed 🌟

[Daniel Rosenwasser (DanielRosenwasser)]

TypeScript Bot (@typescript-bot) pack this
TypeScript Bot (@typescript-bot) user test tsserver
TypeScript Bot (@typescript-bot) test tsserver top100

[TypeScript Bot (typescript-bot)]

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the diff-based user code test suite (tsserver) on this PR at 7b79e1a. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the diff-based top-repos suite (tsserver) on this PR at 7b79e1a. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the tarball bundle task on this PR at 7b79e1a. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Hey Daniel Rosenwasser (@DanielRosenwasser), I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/146368/artifacts?artifactName=tgz&fileId=B7E8D7117C23D25F0EE586E6B738A2C09AC0E1F6775B9ECFEACAE51482EB6B9302&fileName=/typescript-5.0.0-insiders.20230216.tgz"
    }
}

and then running npm install.