-
Notifications
You must be signed in to change notification settings - Fork 13.2k
Fixed member completions for NoInfer-wrapped unions
#60271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -6349,6 +6349,8 @@ declare namespace ts { | |
| * and the operation is cancelled, then it should be discarded, otherwise it is safe to keep. | ||
| */ | ||
| runWithCancellationToken<T>(token: CancellationToken, cb: (checker: TypeChecker) => T): T; | ||
| unwrapNoInferType(type: Type): Type; | ||
| unwrapNoInferType(type: Type | undefined): Type | undefined; | ||
|
Comment on lines
+6352
to
+6353
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would drop these from the API.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IIRC, I made them public because - as the things stand... the user is actually forced to handle those types manually when using the API and they don't have good means to do so. Truth to be told, the fix here is also targeting a specific path but there are 14 |
||
| } | ||
| enum NodeBuilderFlags { | ||
| None = 0, | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| /// <reference path='fourslash.ts' /> | ||
|
|
||
| // @strict: true | ||
| // @jsx: preserve | ||
|
|
||
| // @Filename: /a.tsx | ||
| //// /// <reference path="/.lib/react18/react18.d.ts" /> | ||
| //// /// <reference path="/.lib/react18/global.d.ts" /> | ||
| //// | ||
| //// interface A { | ||
| //// type: "a"; | ||
| //// value: string; | ||
| //// } | ||
| //// | ||
| //// interface B { | ||
| //// type: "b"; | ||
| //// size: number; | ||
| //// } | ||
| //// | ||
| //// type Union = A | B; | ||
| //// | ||
| //// function accept1<T extends Union>(union: NoInfer<T>) {} | ||
| //// accept1({ /*1*/ }); | ||
| //// accept1({ type: "a", /*2*/ }); | ||
| //// | ||
| //// function accept2<T extends Union>(arg: { prop: NoInfer<T> }) {} | ||
| //// accept2({ prop: { /*3*/ } }); | ||
| //// accept2({ prop: { type: "a", /*4*/ } }); | ||
| //// | ||
| //// function Accept3<T extends Union>(props: NoInfer<T>) {} | ||
| //// <Accept3 /*5*/ />; | ||
| //// <Accept3 type="a" /*6*/ />; | ||
|
|
||
| verify.completions({ | ||
| marker: ["1", "3", "5"], | ||
| exact: ["size", "type", "value"], | ||
| }); | ||
| verify.completions({ | ||
| marker: ["2", "4", "6"], | ||
| exact: ["value"], | ||
| }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first, I considered unwrapping it in the public
getContextualType(and alikes). But sinceNoInfers are not unwrapped when they contain structured types etc it wouldn't really address everything.My line of thinking was that the API user likely shouldn't be concerned with
NoInfertypes all that much and it would be simpler if they just wouldn't be observable by the API users. But currently they will always be - we can obtain{ prop: NoInfer<A> }, then get that property and end up with aNoInfertype easily.So it's pretty impractical to unwrap those in the API layer, there are just too many places where the user interacts with the types and, perhaps, my initial instinct that
NoInfers should be hidden from the API users wasn't good anyway.So I decided I might very well just uwrap it here since that's something than an external API user would have to do anyway. It feels utterly annoying to deal with those
NoInfers though. I'd expect most of the "get me a type" calls have to be wrapped with this unwrapping call. It's such an easy mistake to make.But, in general,
NoInfer<Structured>types behave almost the same as their wrapped base types. So I'm thinking now that maybe it's just the union case that gets in a way as that's not a union per-se but yet it's also a union for actual practical purposes.So perhaps a better fix would be to distribute
NoInferover unions? That has some drawbacks for huge unions as we'd produce an equally huge distributed output union though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does feel like we should turn
NoInfer<T> | NoInfer<U> | VintoNoInfer<T | U> | V, but, I don't think this PR is actually all that bad as is as a simple workaround for seeing apparent properties.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, what you're saying is the opposite of what I'm saying, I think... Anyway, I think this minimal hack for completions is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The normalization into
NoInfer<T | U> | Vdoesn't ensure a type would be treated as a union because you could end up withNoInfer<T | U>and now any logic that wants to target unions won't target this.