Prevent substitution types from leaking out of non-deferred conditionals #54894
Conversation
typescript-bot
added
the
For Uncommitted Bug
Andarist
changed the title
Andarist
changed the title
typescript-bot
added
For Backlog Bug
There was a problem hiding this comment.
This doesn't quite feel like the right fix - I'm actually OK with substitution types exiting conditional boundaries, it's useful in many ways - in fact, it's sometimes the only way chained conditionals like SplitString<Cast<T, string>> typecheck. Naturally, using the intersection means these cases will still work... but the ux when you see these "narrowed" types will get a bit (ok, a lot) worse.
Honestly, a much better fix is noting that in getPropertyTypeForIndexType we use isTypeAssignableToKind to make these errors, which is... not great (any type-kind based analysis is suspect, given how generics work). But so long as we are, updating isTypeAssignableToKind to intersect substitutions is probably ok.
| @@ -17951,6 +17951,10 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
| result.aliasTypeArguments = aliasSymbol ? aliasTypeArguments : instantiateTypes(root.aliasTypeArguments, mapper!); // TODO: GH#18217 | |||
| break; | |||
| } | |||
| if (result.flags & TypeFlags.Substitution) { | |||
| const substitution = result as SubstitutionType; | |||
| result = getIntersectionType([substitution.baseType, substitution.constraint]); | |||
There was a problem hiding this comment.
Use getSubstitutionIntersection, if this sticks around.
|
superseded by #57113 |
fixes #54886