Fix one source of exponential behavior in the type checker. #6629
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.
|
@swift-ci Please test |
|
Build failed |
|
Failure appears to be due to #6624. I've started a PR to revert that PR to unblock. |
|
@swift-ci Please test |
|
@DougGregor If you have a moment it might be worth a peek. I made a subtle mistake earlier which only resulted in one failure in the test suite. |
DougGregor
reviewed
Jan 9, 2017
| ConstraintKind kind) { | ||
| OptionalTypeKind optionalKind1 = OTK_None; | ||
| if (auto boundGeneric1 = type1->getAs<BoundGenericType>()) | ||
| optionalKind1 = boundGeneric1->getDecl()->classifyAsOptionalType(); |
There was a problem hiding this comment.
FWIW, you can use TypeBase::getAnyOptionalObjectType() for this.
There was a problem hiding this comment.
ah, I knew that existed and was looking for it but didn't realize it had the same name as the version that just returns the object type. I'll put together a new patch that uses it.
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.