Error on complex array literals #28707
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Nov 29, 2018
RyanCavanaugh
approved these changes
Jan 24, 2019
|
@RyanCavanaugh probably worth mentioning that #28727 fixes the same original bug with a smaller fallout of disabling-things-which-really-should-work. (it's not linked in this PR, but is mentioned in the bug this PR fixes) |
|
Closing in favor of #29435. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Large array literals containing object literals that all have distinct types (e.g. because each has a unique property name) end up producing union types with exponentially increasing complexity, due to subtype reduction and object literal normalization (#19513). Rather than "hanging" the type checker by consuming inordinate amounts of memory and time, we now issue an error when an array literal is deemed too complex. The metric we use is 500,000 or more failed subtype checks, which for example would be caused by an array literal containing 1000 or more object literals with distinct types.
The "Array literal type is too complex to represent" error we now report is easily squelched using a type assertion on the first element:
This causes the array literal to have the inferred type
any[].Fixes #28540.