Skip to content

[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

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants