-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[6.0][Caching] Add swift caching changes to swift 6.0 #73064
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
cachemeifyoucan
merged 6 commits into
swiftlang:release/6.0
from
cachemeifyoucan:eng/PR-swift-caching-6.0-update
Apr 18, 2024
Merged
[6.0][Caching] Add swift caching changes to swift 6.0 #73064
cachemeifyoucan
merged 6 commits into
swiftlang:release/6.0
from
cachemeifyoucan:eng/PR-swift-caching-6.0-update
Apr 18, 2024
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
Please test with following pull request: @swift-ci please test |
Improve swift dependency scanner by validating and selecting dependency module into scanner. This provides benefits that: * Build system does not need to schedule interface compilation task if the candidate module is picked, it can just use the candidate module directly. * There is no need for forwarding module in the explicit module build. Since the build system is coordinating the build, there is no need for the forwarding module in the module cache to avoid duplicated work, * This also correctly supports all the module loading modes in the dependency scanner. This is achieved by only adding validate and up-to-date binary module as the candidate module for swift interface module dependency. This allows caching build to construct the correct dependency in the CAS. If there is a candidate module for the interface module, dependency scanner will return a binary module dependency in the dependency graph. The legacy behavior is mostly preserved with a hidden frontend flag `-no-scanner-module-validation`, while the scanner output is mostly interchangeable with new scanner behavior with `prefer-interface` module loading mode except the candidate module will not be returned. rdar://123711823 (cherry picked from commit 0e12f20)
Teach scanner to pick and choose binary modules correctly based on if it is testable import or not. Some situations that scanner need to be careful when testable is involved: * When it is a regular import, it should not import binary modules that are built with -enable-testing, it should prefer interfaces if that is available. * When testable import, it should only load binary module and it should make sure the internal imports from binary modules are actually required for testable import to work. If a testable import only find a regular binary module, dependency scanner currently will just preceed with such module and leave the diagnostics to swift-frontend, because the alternative (failed to find module) can be confusing to users. rdar://125914165 (cherry picked from commit d4c90d6)
Preliminary caching support for macro: * Inserting the plugin into the CASFS * Lookup plugin via physical file system For future better support, we should teach dependency scanner to resolve macros and return the resolved plugins to swift-frontend. rdar://121873571 (cherry picked from commit daa1065)
When caching is enabled with include-tree, the bridging header PCH is created from the include tree directly. Setup the rewriter correctly when embedding the bridging header into swift binary module. rdar://125719747 (cherry picked from commit 7a68d36)
The binary module built from a CAS build will have the embeded bridging header info with 0 modTime. Allow a regular build to import such a module with the same behavior as if the module is built from a regular build. rdar://126221616 (cherry picked from commit e654e37)
If a testable module is loaded from a non-testable import, ignore its optional dependencies because the consumer should not use them. This matches the behavior of the implicit build or the behavior how forwarding module is created. (cherry picked from commit 77fefe9)
b460ea4
to
9d9d3e2
Compare
Please test with following pull request: @swift-ci please test |
akyrtzi
approved these changes
Apr 18, 2024
nkcsgexi
approved these changes
Apr 18, 2024
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.
Explanation: Cherry-pick swift caching changes to swift 6.0
Original PR: #72291 #70724 #72908 #72804 #73087
Risk: Low. The part that affects non-caching build is qualified with SWB and the remaining part only affects experimental caching feature.
Testing: UnitTests + SWB
Reviewer: @artemcm