Fix one source of exponential behavior in the type checker. #6730
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
For collection literals that contained implicitly unwrapped optionals, we were attempting three different conversions per element of the collection, resulting in exponential type checking time. We should only ever attempt one of these conversions for any pair of types where one or both is optional. We had several reports of this as it seems quite common for people to write expressions that create a collection of IUOs from class/struct elements, and then either return the collection or some variation that has been filtered and mapped. I am looking at adding the appropriate instrumentation to the type checker so that I can add a scale-test for this and other type checker test cases related to slow type checking so that we can avoid regressing in the future. (cherry picked from commit 1efafbc)
|
@swift-ci Please test |
|
Build failed |
|
The test failures appear to be unrelated to my change, and happening on master as well. |
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.
For collection literals that contained implicitly unwrapped optionals,
we were attempting three different conversions per element of the
collection, resulting in exponential type checking time.
We should only ever attempt one of these conversions for any pair of
types where one or both is optional.
We had several reports of this as it seems quite common for people to
write expressions that create a collection of IUOs from class/struct
elements, and then either return the collection or some variation that
has been filtered and mapped.
I am looking at adding the appropriate instrumentation to the type
checker so that I can add a scale-test for this and other type checker
test cases related to slow type checking so that we can avoid regressing
in the future.
(cherry picked from commit 1efafbc)