Include source node inferences in string literal completions

[Ron Buckton (rbuckton)]

This adopts the proposed fix mentioned in #49680 (comment). This is a different approach than the one taken by Mateusz Burzyński (@Andarist) in #52997, as that PR attempted to pre-filter results.

Fixes#49680
Supersedes #52997

[Jake Bailey (jakebailey)]

Code LGTM though I'll leave it to Andrew as to whether or not this is the better approach (I assume it is)

[Mateusz Burzyński (Andarist)]

A couple of my merged PRs related to completions are using a similar "double request" technique. One notable difference is that this PR here always performs the double request whereas those other PRs use the second request as a fallback - only if the first one didn't return anything useful.

Out of curiosity, I wonder:

• if this particular test case would work if "the second request" would be performed conditionally (in other words - is "the first request" returning anything here?)
• can we think of a good reason for this completion type here to always use results from both requests if other completion requests perform 2 requests conditionally?
• how does this PR compare with this PR of mine that implements the "double request technique" around the same getStringLiteralCompletionsFromSignature (that is transitively touched here)?

[Jake Bailey (jakebailey)]

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

[TypeScript Bot (typescript-bot)]

Heya Jake Bailey (@jakebailey), I've started to run the diff-based top-repos suite (tsserver) on this PR at ef50d45. You can monitor the build here.

Update: The results are in!

[TypeScript Bot (typescript-bot)]

Heya Jake Bailey (@jakebailey), I've started to run the diff-based user code test suite (tsserver) on this PR at ef50d45. You can monitor the build here.

Update: The results are in!

[TypeScript Bot (typescript-bot)]

Heya Jake Bailey (@jakebailey), I've started to run the tarball bundle task on this PR at ef50d45. You can monitor the build here.

[TypeScript Bot (typescript-bot)]

Hey Jake Bailey (@jakebailey), 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/153799/artifacts?artifactName=tgz&fileId=D9DBEDB481AEE9C8CA59301474984667DCA709E5AF3258C9390950189FBB5CAB02&fileName=/typescript-5.1.0-insiders.20230503.tgz"
}
}

and then running npm install.

---

There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.1.0-pr-54121-5".;

[TypeScript Bot (typescript-bot)]

Jake Bailey (@jakebailey) Here are the results of running the user test suite comparing main and refs/pull/54121/merge:

Everything looks good!

[TypeScript Bot (typescript-bot)]

Jake Bailey (@jakebailey) Here are the results of running the top-repos suite comparing main and refs/pull/54121/merge:

Everything looks good!

[Mateusz Burzyński (Andarist)]

I kinda already answered my own questions:

1. the first request returns 'a' | 'b' (although those don't end up being actually suggested to the user since they don't match the string in the argument) - so to satisfy this test case we kinda need the second request since it's that request that returns 'b.c' here
2. I think that it's a valid concern that this PR here always performs the "double request" (unlike Retry querying string completions from the inferred type if the original completions request doesn't return anything #52875Retry string completions from the inferred type by default #53481 and Improve contextual completions #53554 ). I'm not saying that it's incorrect - it's just inconsistent and might lead to different results based on the position associated with the request. This is actually shown in the expected results here (I created a PR with extra tests that targets this PR here, you can also add Validated completions available for string props are not available for shallow strings #53997 to the issues that this PR here fixes)
3. this is basically answered with 1. I think that my PR might have some nice refactors in it - but that's orthogonal to the issue fixed at hand. My PR doesn't fix the OP's case from with infer in template string, suggestion works in 4.6, but not work in 4.7 #49680 since it's doing the second request conditionally.

I think that there is a way to avoid the second request here by smartly providing any to conditional types (and thus probing both branches of the conditional type). Perhaps that wouldn't be ideal either so maybe "double request at all times" is the way to go here - but I feel like it's not perfect that it only happens here and not in other places.

[Mateusz Burzyński (Andarist)]

nit: other "double requests" are performed outside of the checker - it's the caller's responsibility to "probe" both type of contextual types (with and without inference blocking). Is this a problem? Perhaps that other code should be moved to the checker?

[Ron Buckton (rbuckton)]

• if this particular test case would work if "the second request" would be performed conditionally (in other words - is "the first request" returning anything here?)

1. the first request returns 'a' | 'b' (although those don't end up being actually suggested to the user since they don't match the string in the argument) - so to satisfy this test case we kinda need the second request since it's that request that returns 'b.c' here

Yes, the first request is returning candidates that result in "a" | "b". It's not that they aren't suggested to the user, they are in the suggestions we provide to VS Code. However, it is the editor that is supposed to make the decision whether to filter out suggestions based on what has been typed, not the language service.

• can we think of a good reason for this completion type here to always use results from both requests if other completion requests perform 2 requests conditionally?

This is the simplest solution to the problem. In essence, we want completions that take into account what the user has already typed, but not to the extent that we filter out valid completions such as those that #48410 addressed. We are also considering a more comprehensive solution long term, but that may require more in-depth change to inference and needs further time for consideration and discussion.

[Andrew Branch (andrewbranch)]

Let’s pull in the extra test cases from Mateusz Burzyński (@Andarist) and then I’m good with this.

[Mateusz Burzyński (Andarist)]

Andrew Branch (@andrewbranch) perhaps it would be good to pull this into 5.1? I have some further improvements in mind for this, my tests might very well just get merged as part of those - I'm just waiting for this one to land to start working on a follow-up

[Andrew Branch (andrewbranch)]

5.2*

It’s Ron Buckton (@rbuckton)’s PR to merge whenever he’s ready.

[Mateusz Burzyński (Andarist)]

Since this PR has conflicts and I was working on the code that created them, I resolved them cause I knew exactly how they should be resolved - but since I can't push to this branch I prepared a PR for you here: #54668

[Mateusz Burzyński (Andarist)]

Ron Buckton (@rbuckton) friendly 🏓

[Jake Bailey (jakebailey)]

Is there anything left to do here? It's got conflicts, but it's approved by two people.

[Mateusz Burzyński (Andarist)]

Ron Buckton (@rbuckton) did u check the PR in which i resolved the conflicts ( #54668 )? Iirc i already fixed it there but it has been a while so my memory around that is a little bit foggy

[Ron Buckton (rbuckton)]

This issue appears to be that we no longer skip type argument inference from arguments when checking for string literal completions, and end up inferring never from an argument instead of string from the constraint.

Ron Buckton (@rbuckton) did u check the PR in which i resolved the conflicts ( #54668 )? Iirc i already fixed it there but it has been a while so my memory around that is a little bit foggy

That PR lists 5000+ file changes and is too large for GitHub to render in the UI, so I'm not sure what changes you may have made. At least, that was an immediate difference that I noticed between when this PR was drafted and main. The change is here: https://github.com/microsoft/TypeScript/pull/53996/files#diff-d9ab6589e714c71e657f601cf30ff51dfc607fc98419bf72e04f6b0fa92cc4b8L32511-R32515

[Mateusz Burzyński (Andarist)]

That PR lists 5000+ file changes and is too large for GitHub to render in the UI, so I'm not sure what changes you may have made.

We can compare that branch directly against main (diff) and manually~/visually compare it with the diff visible here. I only focused on test cases and it seems actually they expected results there are slightly different than here.

The only difference is in this expectation. This is basically the same test case that was introduced in #53996 and it could be removed from this PR to avoid duplication.

I understand that perhaps the current expactation from this PR might be considered better but it isn't noticeable for the majority of end users. So maybe it's worth landing this PR without fixing it (as the PR's focus was to fix a different case anyway) and to open an issue about it? The expected results are at least consistent right now between both markers (see here) and I think that the ideal result is that they always should be the same. The only reason why they are different here is that the code path used for object property values completions is quite different from the code path used for string completions directly at argument positions. It's not because they should behave differently - they just happen to behave differently (maybe because it's a design limitation since it might be more complex to do what argument completions do within objects but still).

[Ron Buckton (rbuckton)]

I had to make other changes than what you've illustrated to get the expectations from the tests I added to pass, reverting a number of places where CheckMode.IsForStringLiteralArgumentCompletions was dropped in checker, but I have something that's working now.

[Ron Buckton (rbuckton)]

Or not, it looks like it's still not quite correct.

[Mateusz Burzyński (Andarist)]

this file can be removed since this test already got its way to the main branch:
https://github.com/microsoft/TypeScript/blob/main/tests/cases/fourslash/stringCompletionsFromGenericConditionalTypesUsingTemplateLiteralTypes.ts

[Mateusz Burzyński (Andarist)]

That's interesting! It turns out that for this one test the wildcardType used in place of a blocked string performed better. I had to replace it with blockedStringType just 4 days ago (and my merge didn't include this change), see #55552 .

[Mateusz Burzyński (Andarist)]

I had to make other changes than what you've illustrated to get the expectations from the tests I added to pass, reverting a number of places where CheckMode.IsForStringLiteralArgumentCompletions was dropped in checker, but I have something that's working now.

I managed to get it working again without those reverts. The proposed change also brings back your expected results for the
stringCompletionsFromGenericConditionalTypesUsingTemplateLiteralTypes test case. The changes can be found on my Andarist:get-rid-off-for-string-literal-arg-completions branch which is stacked on top of the simplification from #55624 . It's best to see those changes in isolation though and this is the commit that tweaks the algorithm: Andarist@26c1127

That change is somewhat significant and perhaps bikesheddable so it might be best to leave it for a follow-up PR that I can open once this one lands.

[Ron Buckton (rbuckton)]

Mateusz Burzyński (@Andarist):

That change is somewhat significant and perhaps bikesheddable so it might be best to leave it for a follow-up PR that I can open once this one lands.

The change in Andarist@26c1127 doesn't seem too complex, but I agree we can tackle it in a follow-on PR.

Andrew Branch (@andrewbranch) can you take a quick look at this again before I merge?

[Ron Buckton (rbuckton)]

Andrew Branch (@andrewbranch), Jake Bailey (@jakebailey) can one of you take a look over the latest changes?

[Ron Buckton (rbuckton)]

I'll fix the merge conflict with checker shortly

[Jake Bailey (jakebailey)]

Still seems good to me.