[6.0 🍒][Dependency Scanning] Disable validation of Swift dependency modules' existing pre-built candidate binary module files in the scanner, on a non-caching build. #75570
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
… existing pre-built candidate binary module files in the scanner, on a non-caching build. As-is, this default interferes with the incremental build machinery which conservatively assumes that binary module dependencies must cause dependents to be re-built.
|
@swift-ci test |
nkcsgexi
approved these changes
Jul 30, 2024
|
This PR has fixed a recent incremental build regression. We should take it. |
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: [Dependency Scanning] Disable validation of Swift dependency modules' existing pre-built candidate binary module files in the scanner, on a non-caching build. #75556 moved validation of up-to-date binary module dependencies into the dependency scanner, versus being done in interface compilation jobs. This means the scanner now produces "binary module dependency" for discovered textual Swift modules for which an existing up-to-date binary module is found. Unfortunately, this behavior interacts poorly with the incremental build machinery which relied on textual swift dependencies showing up as "textual module dependency" in order to check if they are out-of-date w.r.t. their interface file. Now that such dependencies are only binary modules, the driver's logic conservatively insists on rebuilding their dependents. We need to enhance the driver logic, but in the meantime, simply revert the switch for this logic to disable it for non-caching builds.
Scope: Compiles using the opt-in Explicit Module Builds feature.
Risk: Low. This change reverts build behavior for opt-in Explicit Module Builds back to the known build model that was used for a long while prior to [ScanDependency] Move binary module validation into scanner #72291. This prior build model is not unsound, but rather performs validation of up-to-date modules in the interface compilation task, rather than the scanner itself. Paying the price of launching said task which may be a quick no-op.
Original PR: [Dependency Scanning] Disable validation of Swift dependency modules' existing pre-built candidate binary module files in the scanner, on a non-caching build. #75556
Testing: Test suite contained existing tests which were modified to exercise both the new default and changed configuration flags for this behavior.
Issue/Radar: rdar://132340493
Reviewed By: @cachemeifyoucan