Uh oh!
There was an error while loading. Please reload this page.
Prevent substitution types from leaking out of non-deferred conditionals - #54894
Prevent substitution types from leaking out of non-deferred conditionals#54894Mateusz Burzyński (Andarist) wants to merge 2 commits into
Conversation
Wesley Wigham (weswigham)
left a comment
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.
| } | ||
| 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.
Mateusz Burzyński (Andarist)
commented
Jul 13, 2024
superseded by #57113 |
fixes#54886