Fixed string completions from generic conditional types that match typed argument against template literal type#52997
Conversation
…ped argument against template literal type
typescript-bot
added
the
For Milestone Bug
| return type.isUnion() ? flatMap(type.types, t => getStringLiteralTypes(t, uniques)) : | ||
| type.isStringLiteral() && !(type.flags & TypeFlags.EnumLiteral) && addToSeen(uniques, type.value) ? [type] : emptyArray; | ||
| return type.isUnion() ? flatMap(type.types, t => getStringLiteralTypes(t, uniques, alreadyTyped)) : | ||
| type.isStringLiteral() && !(type.flags & TypeFlags.EnumLiteral) && type.value.startsWith(alreadyTyped) && addToSeen(uniques, type.value) ? [type] : emptyArray; |
There was a problem hiding this comment.
Based on those few test failures it seems that I can't just simply discard the already matched strings at this stage. Those are still useful for creating replacement spans here:
TypeScript/src/services/stringCompletions.ts
Line 266 in 178acd9
However, I'm not exactly sure what is the relation between what is being returned by TS and what is displayed by VS Code. VS code tends to skip some completions... like even if we take a look at the added test case: before this change TS returns "a" | "b" but VS Code doesn't display anything.
The goal behind this change here was for the logic to fallback to the fromContextualType() here:
TypeScript/src/services/stringCompletions.ts
Line 419 in 178acd9
I tried to avoid doing both requests unconditionally and concatenating their results but perhaps that is the way to go here? Or perhaps this filtering should happen on a different level (like before doing the second request) but it doesn't affect the returned types? Maybe it should just test out if anything "interesting" was returned from the first request?
…s-from-conditional-types
|
This was superseded by #54121 |
3 participants
fixes #49680 , cc @andrewbranch