Union types are not expanded properly when checking if type satisfies generic constraint

[jabuj]

Bug Report

🔎 Search Terms

Union types expansion, generic constraints

🕗 Version & Regression Information

4.6, works fine in 4.5

⏯ Playground Link

Playground link with relevant code

💻 Code

type UnionType = {name: 'A'} | {name: 'B'}
type NotUnionType = {name: 'A' | 'B'}

type MyType<T extends UnionType> = number
// Errors here, because NotUnionType is presumably not assignable to UnionType
let d: MyType<NotUnionType>

// No error, because NotUnionType is assignable to UnionType
let check: NotUnionType extends UnionType ? true : false 
    = true

The error doesn't reproduce, however, if I change the order of lines:

let check: NotUnionType extends UnionType ? true : false 
    = true
// No error
let d: MyType<NotUnionType>

🙁 Actual behavior

Error when instanciating MyType<NotUnionType>

🙂 Expected behavior

No error. Also error trace seems to be missing some entries in the beginning (I would expect it to start with something like NotUnionType does not satisfy the constraint UnionType whereas in actuality is starts with Type 'NotUnionType' is not assignable to type '{ name: "B"; }').

[jabuj]

If it's indeed a bug, a temporary workaround could be something like

let d: MyType<NotUnionType extends UnionType ? NotUnionType : never>

The extends clause always evaluates to true, and apparently the cached result that NotUnionType is assignable to UnionType lets bypass the error

[fatcerberus]

This looks like two bugs, actually:

1. What seems like a caching bug, as you note
2. NotUnionType extends UnionType should not be true. In general { x: T | U } is not assignable to { x: T } | { x: U } (but the inverse is okay), and extends in this context means "is assignable to"

edit: I stand corrected on point 2. See Ryan's comment immediately below.

[RyanCavanaugh]

{ name: "A" | "B" } is assignable to { name: "A" } | { name: "B" } in cases where the total number of possible constituents in the right side is small (I believe it's 24 or under) and also literal types.

Changing error arity based on the order of lines is definitely a bug, though.

[fatcerberus]

In that case, repro:

type AObjOrBObj = { name: "A" } | { name: "B" };
type AOrBObj = { name: "A" | "B" };
type Generic<T extends AObjOrBObj> = T;

type T = Generic<AOrBObj>;  // error if here

declare let x: AObjOrBObj;
declare let y: AOrBObj;
x = y;  // ok
y = x;  // also ok

//type T = Generic<AOrBObj>;  // not an error if here

[jakebailey]

I was hoping this would be fixed by #49718 (because if you have type T = ... at the bottom, then comment out the assignments, they aren't related, and the behavior changes), but that doesn't seem to be the case.

[jakebailey]

It turns out that it was in fact fixed by #49718; not sure how I managed to make it fail in my comment above. Will send a PR which adds a test.