Signature help suppresses arity error in editor

[andrewbranch]

Bug Report

🔎 Search Terms

signature help missing errors

🕗 Version & Regression Information

Saw this for the first time a few months ago, but could be older.

⏯ Playground Link

Playground link with relevant code

💻 Code

declare function f(x: string, y: number): any;

// 1. Put cursor inside call parens
// 2. Request signature help with cmd+shift+space
// 3. Type a quote mark
// 4. Observed behavior: no squigglies
f()

🙁 Actual behavior

No error after following instructions, until making another edit elsewhere / with signature help closed

🙂 Expected behavior

Arity error on the call

[RyanCavanaugh]

I'm pretty sure we have an incremental parser bug. If I move atomically (with pasting) from

fun('a', 3, 3, 'a', 3)

to

fun('a', 3, 3, 'a', 3, 3)

then the error is always presented.

If I insert the comma, then the argument, with delays, then it's a reliable repro that the error doesn't appear. More tellingingly, atomic edits from that point forward don't present an error unless I remove the line and put it back again

[andrewbranch]

Could be, but I’m pretty sure signature help is also related somehow. I have automatic signature help turned off in my editor but frequently invoke it manually. By default, signature help appears when you type a comma, so that creates another difference vs. pasting. But in my editor, I can’t repro without invoking signature help.

[DanielRosenwasser]

Fairly certain it's not related to incremental parsing. If you dismiss signature help and start typing, errors show up again. Manually triggering and typing makes it disappear.

signatureHelpPoisoningTypeCheckerCache.webm

Here's my theory from #52369:

What are the mechanics here that're making this happen? If you're using VS Code, that initial , will start a signature help session. Every subsequent character will likey be used as a retrigger for signature help prior to requesting diagnostics. And so signature help (which I recall is checked in a specific way to handle overloads that differ slightly in arity) keeps getting requested for a specific expression before the rest of the type-checker gets to walk over it to report errors.

I believe that because signature help gets checked in a special way, it is likely poisoning the type-checker state we use for reporting errors as well.

[Andarist]

This might be the same problem as the one that I'm trying to fix here. The problem recognized there is only relevant for one of the issues but we were discussing with @andrewbranch that the problem is likely to be much broader. I'm investigating the related issues to learn more about the scope so I can repurpose that PR to fix those kinds of issues holistically.

[Andarist]

After all, this feels a little bit different from the other case - the other case is strongly related to inference blocking and this doesn't look anything like that (so far).

I've managed to create a test file for this:

///<reference path="fourslash.ts"/>
// @strict: true
////
//// declare function f(x: string, y: number): any;
////
//// /*1*/f(/*2*/)/*3*/

goTo.marker("2");
verify.signatureHelp({
    triggerReason: {
        kind: "invoked"
    }
})
edit.insert(`"`)
edit.insert(`"`)
verify.signatureHelp({
    triggerReason: {
        kind: "retrigger"
    }
})
verify.not.codeFixAvailable() // trigger typecheck
verify.errorExistsBetweenMarkers("1", "3");

If we remove the second verify.signatureHelp call then this test passes. For some reason, the code fix-related thing after the signature help doesn't end up checking the file or doesn't end up reporting this error. I'm gonna continue investigating this some time later.

[sandersn]

If #52679 is a correct fix, the likely cause was #48410.

[Andarist]

I don't think this is related - the problem can already be observed in builds from before this PR has been merged: [email protected] playground.

I identified a similar regression here to be caused by #36747 . We can also confirm that this issue here doesn't happen in a build from before this PR ([email protected] playground) and that is happens in a build after that has landed ([email protected] playground)