-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Circular validation cleanups, part 3 #27546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
slavapestov
merged 9 commits into
swiftlang:master
from
slavapestov:circular-validation-cleanups-3
Oct 8, 2019
Merged
Circular validation cleanups, part 3 #27546
slavapestov
merged 9 commits into
swiftlang:master
from
slavapestov:circular-validation-cleanups-3
Oct 8, 2019
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
Instead of depending on a prior call to setOpaqueResultTypeDecl(), we can instead just build the decl if we need one.
28a23af
to
a86acad
Compare
a86acad
to
6edecd4
Compare
@swift-ci Please smoke test |
@swift-ci Please test source compatibility |
6edecd4
to
c3c70f3
Compare
@swift-ci Please test source compatibility |
This will be used as a transitional aid in refactoring getInterfaceType() to always return a valid type, instead of silently returning Type() when there is circularity.
Remove the early return in the case where one of our parent contexts was being validated, and replace it with a simpler check that is only performed in some callers related to associated type inference; we want to bail out in one specific case only, which is that the declaration is inside an extension whose generic signature is in the process of being computed.
c3c70f3
to
52cf365
Compare
apple/swift-lldb#2035 |
apple/swift-lldb#2035 |
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.
This PR continues refactoring validateDecl() with the goal of replacing it with a request for computing a declaration's interface type.
One of the main differences between validateDecl() and requests is that on circularity, requests diagnose an error. On the other hand, validateDecl() would begin by checking if the declaration or any of its parent contexts were already being validated, and return silently without setting the declaration's type.
This PR refactors the circularity checking so that validateDecl() now only concerns itself with the declaration being validated, and not any of its parent contexts. A new method,
ValueDecl::isRecursiveValidation()
can be used to check if parent contexts are being validated. This is only meant to be a temporary fix, since all of its usages should be refactored to break cycles in a more principled manner.For now,
getInterfaceType()
still returns an empty type if the declaration is being validated. The next PR will change this.Another refactoring in this PR is that synthesizing opaque type declarations is now done using requests as well, instead of a side effect of calling
validateDecl()
.