RangeError: Maximum call stack size exceeded with union type

[cyrilletuzi]

TypeScript Version: 2.7.2 and 2.9.0-dev.20180430

Search Terms:
RangeError: Maximum call stack size exceeded

Code

• git clone https://github.com/cyrilletuzi/angular-async-local-storage.git
• cd angular-async-local-storage
• git checkout newschema
• npm test > OK
• Uncomment test in src/lib/src/service/validation/json-validation.spec.ts lines 570-576
• npm test

Actual behavior:
RangeError: Maximum call stack size exceeded

Expected behavior:
Should not crash.

Context:
Trying to do an union type for JSONSchema.

When giving a wrong type value with a primitive, it's OK (error reported in VS Code but tsc not crashing):

const test = jsonValidator.validate('test', { type: 1 });

But when giving a wrong type value with an array or object, no error is shown in VS Code (as if typings were valid) and tsc crashes with the error above:

const test = jsonValidator.validate('test', { type: ['string', 'number'] });

What is strange is when doing the same in a more simpler file the typing error is reported.

[mhegazy]

Looks like the types are deep enough to run out of stack. on my box, raising the stack limit from default (984) to 1001 gets the types to check.

We can look and see if there are unnecessary calls that we can remove and limit the factor we add to the stack size. but ultimately, in a structural type system, eventually there is a limit to hit.

[cyrilletuzi]

What I try to achieve is a simple exclusive union type: it's just a few interfaces with different type values. Is there a particular reason it reaches the stack limit? Something I can simplify?

[ahejlsberg]

@sandersn @mhegazy The culprit here appears to be some logic in getApparentTypeOfContextualType that tries to narrow the contextual type based on a discriminant in the source type. The way that code is written we reach back down into the type for which we just reached up to the parent and we go into what appears to be an infinite loop (or something that is very, very deep). The logic that attempts to narrow based on a discriminant needs to be more selective (or should I say discriminating) about when calls checkExpression as it is reaching down. Perhaps we should only do it when the expression is a literal. Certainly we shouldn't when the expression is an array literal as that could never be a discriminant.

[cyrilletuzi]

@ahejlsberg An array or an object (same issue with an object as type).

[ahejlsberg]

@cyrilletuzi I'm not sure I understand what you mean.