Don't use a cached union/intersection type if there is an aliasSymbol - #17349
Don't use a cached union/intersection type if there is an aliasSymbol#17349Deleted user (ghost) wants to merge 1 commit into
Conversation
86ea47f to
af108c0
Compare
ghost
changed the title
af108c0 to
82d68fc
Compare
| @@ -1,32 +1,32 @@ | |||
| === tests/cases/conformance/types/literal/booleanLiteralTypes1.ts === | |||
| type A1 = true | false; | |||
| >A1 : boolean | |||
There was a problem hiding this comment.
This behaviour is intended. I don't know that it's super important. It's probably even less important that
type A = { a }
type B = { b }
type T = A | B
type U = A | B
declare var t: T
declare var u: Ushould also print either T or U (or A | B) for both t and u.
It's more important that:
declare var x: true | falseprints 'boolean' for the type of x
There was a problem hiding this comment.
Anders Hejlsberg (@ahejlsberg) can you weigh in on true | false and boolean being equivalent to type B = true | false ?
|
|
||
| var a: false | true; | ||
| >a : boolean | ||
| >a : A1 |
There was a problem hiding this comment.
This change looked wrong until I realized that this is the fourth declaration of a, and the first declaration has type A1, which is the type shown here.
There is a test below showing that a variable whose only declaration is of type true | false will still print as boolean.
|
Andy (Andrewkraft) (@Andy-MS) Nathan Shively-Sanders (@sandersn) This PR doesn't look right to me. In numerous places we rely on the fact that a union of a given set of types is represented by a single object identity. Why are we trying to change this? I don't see an issue referenced here so I'm not clear on the motivation. |
|
Closing in favor of #17434. |
3 participants
It's not safe to cache the creation of a value based on only some of the inputs to that creation. This updates the code to not cache the creation of a type alias with
aliasSymboldefined. (Presumably we will never create a type for the same symbol twice?)