You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Isolated repro (needs dom lib for ElementTagNameMap and associated types):
// @strict: true// Modified repro from #23977declare global {interfaceElementTagNameMap{[index: number]: HTMLElement}interfaceHTMLElement{[index: number]: HTMLElement;}}exportfunctionassertIsElement(node: Node|null): node is Element{letnodeType=node===null ? null : node.nodeType;returnnodeType===1;}exportfunctionassertNodeTagName<TextendskeyofElementTagNameMap,UextendsElementTagNameMap[T]>(node: Node|null,tagName: T): node is U{if(assertIsElement(node)){constnodeTagName=node.tagName.toLowerCase();returnnodeTagName===tagName;}returnfalse;}exportfunctionassertNodeProperty<TextendskeyofElementTagNameMap,PextendskeyofElementTagNameMap[T],VextendsHTMLElementTagNameMap[T][P]>(node: Node|null,tagName: T,prop: P,value: V){if(assertNodeTagName(node,tagName)){node[prop];}}
Expected behavior:
No crash.
Actual behavior:
OOM crash after a very long delay.
Preliminary investigation shows the OOM occurs when we try to get the distributed form of keyof <Large Union> - namely the process is defined recursively, so when the union has ~170 members, we create 170 intermediate types (flattening one member at a time, while also wasting time recalculating type flags and other bits we will never need) before getting the final, distributed result. Now, picture doing this on every relation comparison operation for P (this distribution is uncached), and multiplying it for V in assertNodeProperty - the complexity is huge. Our fast path doesn't fix this, since the numeric index signatures cause us to bail on the fast path as it currently is.
The text was updated successfully, but these errors were encountered:
Helps avoid exponential blowup for `keyof` large unions even when
`keyof` each type in the union is not a union of unit types (e.g.,
because there is an index signature or a type variable).
Remove the special handling of intersections of unions of unit types
because it's no longer needed. This reverts the code changes of pull
request microsoft#24137 (commit 3fc3df3 with
respect to 3fc727b) but keeps the test.
Fixesmicrosoft#24223.
Helps avoid exponential blowup for `keyof` large unions even when
`keyof` each type in the union is not a union of unit types (e.g.,
because there is an index signature or a type variable).
Remove the special handling of intersections of unions of unit types
because it's no longer needed. This reverts the code changes of pull
request microsoft#24137 (commit 3fc3df3 with
respect to 3fc727b) but keeps the test.
Fixesmicrosoft#24223.
Helps avoid exponential blowup for `keyof` large unions even when
`keyof` each type in the union is not a union of unit types (e.g.,
because there is an index signature or a type variable).
Fixesmicrosoft#24223.
Ref #23977 and discussion on #24137
Code
Isolated repro (needs
dom
lib forElementTagNameMap
and associated types):Expected behavior:
No crash.
Actual behavior:
OOM crash after a very long delay.
Preliminary investigation shows the OOM occurs when we try to get the distributed form of
keyof <Large Union>
- namely the process is defined recursively, so when the union has ~170 members, we create 170 intermediate types (flattening one member at a time, while also wasting time recalculating type flags and other bits we will never need) before getting the final, distributed result. Now, picture doing this on every relation comparison operation forP
(this distribution is uncached), and multiplying it forV
inassertNodeProperty
- the complexity is huge. Our fast path doesn't fix this, since the numeric index signatures cause us to bail on the fast path as it currently is.The text was updated successfully, but these errors were encountered: