Dependency analysis: treat member operators as top-level "provides". #3986
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
We still do a global lookup for operators even though they are syntactically declared within types now, so for dependency-tracking purposes continue to treat that as declared at the top level. This isn't where we actually want to be---ideally we can use the types of the arguments to limit the dependencies to a member lookup (or pair of member lookups)---but since the operator overloads /themselves/ participate in type-checking an expression, I'm not sure that's 100% correct. For now, it's better to be conservative. (This means dependency analysis for operators remains as lousy as it was in Swift 2, but it's not a regression.) rdar://problem/27659972
|
@modocache Mind looking at this one, too? (The per-file side of dependency analysis.) @DougGregor, I'd also appreciate your eyes since you implemented this feature. @swift-ci Please test |
|
Again see DependencyAnalysis.rst for anyone looking for more information. |
|
LGTM. Some time we should talk more about how to limit this, because there's a nontrivial win to be had here if we can treat these as members rather than top level dependencies. |
|
Definitely. This is one of the worst bits of cross-file dependencies right now, because every type implements |
jrose-apple
added a commit
to jrose-apple/swift
that referenced
this pull request
Aug 4, 2016
…wiftlang#3986) We still do a global lookup for operators even though they are syntactically declared within types now, so for dependency-tracking purposes continue to treat that as declared at the top level. This isn't where we actually want to be---ideally we can use the types of the arguments to limit the dependencies to a member lookup (or pair of member lookups)---but since the operator overloads /themselves/ participate in type-checking an expression, I'm not sure that's 100% correct. For now, it's better to be conservative. (This means dependency analysis for operators remains as lousy as it was in Swift 2, but it's not a regression.) rdar://problem/27659972 (cherry picked from commit 91be25f)
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.
We still do a global lookup for operators even though they are syntactically declared within types now, so for dependency-tracking purposes continue to treat that as declared at the top level.
This isn't where we actually want to be---ideally we can use the types of the arguments to limit the dependencies to a member lookup (or pair of member lookups)---but since the operator overloads themselves participate in type-checking an expression, I'm not sure that's 100% correct. For now, it's better to be conservative. (This means dependency analysis for operators remains as lousy as it was in Swift 2, but it's not a regression.)
rdar://problem/27659972
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
A smoke test on macOS does the following:
device standard libraries are not built.
version of these tests are not run.
A smoke test on Linux does the following:
tests are not run.
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.