Fixes #30507

[Tim Suchanek (timsuchanek)]

Fixes #30507

I saw, that when the object expression has incorrect properties, that don't exist on the type, the autocompletion works fine.
The decision, if the constraint type should be taken as the default or not is being made in checker.ts:15733 and as this is about 10 function calls deep when coming from https://github.com/microsoft/TypeScript/blob/master/src/services/completions.ts#L1457 I had to introduce a parameter in all these functions that can be passed down.
I saw, that there was already a ContextFlags type, which can be passed in to getContextualType, so I extended it and to make it accessible from the completions.ts, I had to add it to the TSChecker types in https://github.com/microsoft/TypeScript/compare/master...timsuchanek:genericObjectExpressionCompletion?expand=1#diff-4b8bd1eea29904f1be39cd864e1a45c0R3335

Let me know if I could have achieved this in a different way, but after many hours of debugging, this looked like the "most minimal" change to achieve the goal.

I added 2 tests, all tests are green.

[Microsoft Contribution License Agreements (msftclas)]

All CLA requirements met.

[Johannes Schickling (schickling)]

Very excited to see this fix! Thanks for your work on this Tim Suchanek (@timsuchanek)!

[Tim Suchanek (timsuchanek)]

Sorry to bother, but maybe Anders Hejlsberg (@ahejlsberg) you can have a look as you introduced the ContextFlags. Not sure if I'm "misusing" them.

[Avi Vahl (AviVahl)]

Does it also fix #28470?

[Tim Suchanek (timsuchanek)]

Avi Vahl (@AviVahl) from my understanding yes! I'll fix the new conflicts tomorrow, then it's again ready to get merged.

I'll also add your example as a test case.

[Tim Suchanek (timsuchanek)]

Avi Vahl (@AviVahl) I added a fix so that your use-case with the constructor arguments is also supported and also added the 2 examples from #28470 as test cases.

Wesley Wigham (@weswigham) Anders Hejlsberg (@ahejlsberg) can you prioritize this PR so that it doesn't get conflicts with master again? Thanks 🙏

[Daniel Rosenwasser (DanielRosenwasser)]

Tim Suchanek (@timsuchanek) would you also be able to add a test for string literal completions too?

declare function get<T, key: K extends keyof T>(obj: T, key: K): T[K];

get({ hello: 123, world: 456 }, "/**/");

This is one of the most-maddening and longest-standing issues we've had in completions. It would be really great to get this reviewed Anders Hejlsberg (@ahejlsberg) Wesley Wigham (@weswigham) Andrew Branch (@andrewbranch).

[Tim Suchanek (timsuchanek)]

Daniel Rosenwasser (@DanielRosenwasser) I just simplified the "binary and" statement and also added your example as a test.

Important to note: Your example also worked before my PR, I added it to the tests nonetheless. I didn't touch the code path for string literals, just the code path for object expressions when coming from the completion service.

[Andrew Branch (andrewbranch)]

Looks good to me, so long as others are happy with the public API changes. The failed builds are just API baseline issues after the latest merge with master.

[Tim Suchanek (timsuchanek)]

Thanks Andrew Branch (@andrewbranch)! Is there a way that I can accept the baselines and add a commit for that?
Locally on my machine the tests succeed, can't reproduce the baseline failure.

[Wesley Wigham (weswigham)]

Pass --skipPercent=0, and, failing that, set the CI environment variable.

[Wesley Wigham (weswigham)]

(also rebase/merge with master)

[Andrew Branch (andrewbranch)]

I fixed the baseline merge. Wesley Wigham (@weswigham) Anders Hejlsberg (@ahejlsberg) any reservations about exporting ContextFlags in the public API?

[Johannes Schickling (schickling)]

Thanks a lot Andrew Branch (@andrewbranch). Can’t wait to see this merged! (This is a big deal for us at Prisma (@prisma).) 🎉

[Sheetal Nandi (sheetalkamat)]

I think this as well as new signature need to be internal

[Tim Suchanek (timsuchanek)]

Do you mean we should use something different than the ContextFlags when calling the code from the completion service to prevent this type being exposed?

[Andrew Branch (andrewbranch)]

I think Sheetal means to move ContextFlags into one of the ts namespaces that’s already marked /** @internal */ and then to mark the second parameter of TypeChecker['getContextualType'] as /* @internal */ (or declare it as an internal overload, but the linter might call that an unnecessary overload)

[Tim Suchanek (timsuchanek)]

Ok, makes sense! The overload option indeed makes the linter complain:

ERROR: /Users/tim/code/TypeScript/src/compiler/types.ts:3224:61 unified-signatures These overloads can be combined into one signature with an optional parameter.

The non-overload option, which I wrote like this:

        getContextualType(
            node: Expression,
            /* @internal */ contextFlags?: ContextFlags
        ): Type | undefined;

spits out an invalid typescript.d.ts:

        getRootSymbols(symbol: Symbol): ReadonlyArray<Symbol>;
        getContextualType(node: Expression, 
: Type | undefined;
        /**
         * returns unknownSignature in the case of an error.
         * returns undefined if the node is not valid.
         * @param argumentCount Apparent number of arguments, passed in case of a possibly incomplete call. This should come from an ArgumentListInfo. See `signatureHelp.ts`.
         */

Is there a way to ignore the linter in this case?
Or what is the right way to add @internal to a specific argument?

[Andrew Branch (andrewbranch)]

Just filed #33350. I think it would be ok to ignore the line from the linter. Sheetal Nandi (@sheetalkamat)?

[Sheetal Nandi (sheetalkamat)]

Yes in past we have marked the overload internal and disabled the rule for that line.

[Tim Suchanek (timsuchanek)]

Done. Had to adjust the tests because of #32266

Anything else you need from my side to get this merged?
Sheetal Nandi (@sheetalkamat) Andrew Branch (@andrewbranch)

[Andrew Branch (andrewbranch)]

Cool, this doesn’t even touch the public API baselines now. Would be good to get an approval from another person on the team but I think this is good.

[Wesley Wigham (weswigham)]

This doesn't seem like the right place to do this - rather than passing the flag all the way thru signature resolution, if this flag is set, we should just look at the "base signature" (getBaseSignature) rather than starting inference at all, I think. Then again, if we did that we wouldn't get an instantiated constraint which reports more detailed information on circular constraints. Then again again, I'm pretty sure as-is this is caching into the resolvedSignature of a node, which this very much is not - which means requesting completions poisons the cache with incorrect types for later checking.

[Tim Suchanek (timsuchanek)]

Thanks for the feedback Wesley Wigham (@weswigham)! Do you have a suggestion how we still could fix the autocompletion for this? This was, unfortunately, the only way I found (with my limited knowledge of the codebase).

Maybe introducing a new method as an alternative to getContextualType just to be used by the completion service?

[Wesley Wigham (weswigham)]

I think getContextualType is still right, we just need to avoid using any resolved signature caches.

[Orta Therox (orta)]

TypeScript Bot (@typescript-bot) pack this

[TypeScript Bot (typescript-bot)]

Heya Orta Therox (@orta), I've started to run the tarball bundle task on this PR at 96a782e. You can monitor the build here. It should now contribute to this PR's status checks.

[Andrew Branch (andrewbranch)]

Hey Tim Suchanek (@timsuchanek), I took a stab at addressing Wesley Wigham (@weswigham)’s concerns with some guidance from Daniel Rosenwasser (@DanielRosenwasser). I didn’t want to push a more substantial change here so I branched off of this PR and pushed a new one up at #33937. Would greatly appreciate your input there. Thanks!

[Andrew Branch (andrewbranch)]

Tim Suchanek (@timsuchanek), thanks for championing this through! Your commits here have been merged into master via #33937. 🏆

[Tim Suchanek (timsuchanek)]

Thanks a lot, Andrew Branch (@andrewbranch) for pushing this over the finish line!