Skip to content

Conversation

cachemeifyoucan
Copy link
Contributor

@cachemeifyoucan cachemeifyoucan commented Apr 16, 2024

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

@cachemeifyoucan cachemeifyoucan requested a review from a team as a code owner April 16, 2024 19:59
@cachemeifyoucan
Copy link
Contributor Author

Please test with following pull request:
swiftlang/llvm-project#8583

@swift-ci please test

@cachemeifyoucan cachemeifyoucan requested a review from akyrtzi April 17, 2024 18:35
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)
@cachemeifyoucan cachemeifyoucan force-pushed the eng/PR-swift-caching-6.0-update branch from b460ea4 to 9d9d3e2 Compare April 18, 2024 15:58
@cachemeifyoucan
Copy link
Contributor Author

Please test with following pull request:
swiftlang/llvm-project#8583

@swift-ci please test

@cachemeifyoucan cachemeifyoucan merged commit 45198f0 into swiftlang:release/6.0 Apr 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants