Remove empty intersection types in union types

[ahejlsberg]

An intersection of distinct unit types (such as 'a' & 'b' & 'c') is effectively the same as never because it has en empty set of possible values. We allow such types to exist primarily to make it easier to discover their origin (e.g. an intersection of object types containing two properties with the same name). However, when intersecting unions of unit types, the normalization introduced by #11717 ends up making the types very noisy. For example (0 | 1 | 2) & (1 | 2 | 3) becomes 1 | 2 | (0 & 1) | (0 & 2) | (0 & 3) | (1 & 2) | (1 & 3) | (2 & 1) | (2 & 3).

Likewise, when intersecting {a: string } | undefined and {b: number } | undefined (similar to #18210), normalization produces a union of {a: string } &{b: number }, {a: string } & undefined, undefined &{b: number } and undefined. The middle two have empty sets of values, but trip up property accesses through values of the union type.

With this PR we now remove an intersection type from a union type if

• the intersection type contains more than one unit type, or
• the intersection type contains an object type and a nullable type (null or undefined).

Some examples:

typeT1=(0|1|2)&(1|2|3);// 1 | 2typeT2=(0|1|2)&(3|4|5);// nevertypeT3={a: string}|undefined;typeT4={b: number}|undefined;typeT5=T3&T4;// ({a: string} &{b: number }) | undefined

We could in theory be more aggressive about removing empty intersection types, but we don't want to break code that uses intersections to "tag" primitive types.

This implements parts of what is suggested in #16386 and fixes#18210.

[weswigham]

Rather than checking if every type is unit, is it not sufficient to check if any two members are unit? number & 3 & 4 is as vacuous as 3 & 4, right?

[zpdDG4gta8XKpMCd]

what about tag types #4895?

typeCustomerId=number&'customer-id';

[mhegazy]

Use type CustomerId = number &{'customer-id' : any}; instead

[vsiao]

Is {a: number } & void also considered an empty type?