Enable code coverage in Xcode for clang-built targets #491
+61
−0
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
This was referenced Dec 3, 2025
aaronsky
requested review from
adincebic,
brentleyjones,
keith,
luispadron and
mattrobmattrob
as code owners
keith
approved these changes
Dec 5, 2025
aaronsky
added a commit
to bazelbuild/rules_swift
that referenced
this pull request
Dec 5, 2025
This is the second in a stack of PRs across three repositories. - bazelbuild/apple_support#491 - #1623 <-- you are here - MobileNativeFoundation/rules_xcodeproj#3250 It takes the approach suggested in MobileNativeFoundation/rules_xcodeproj#1119 and applies it to our swift toolchain. By breaking sandboxing rules and remapping a derivable path to the source root, we can to allow Xcode, which bookkeeps all code coverage representations in the IDE as absolute paths, to present code coverage information in the gutters and test results.
brentleyjones
pushed a commit
to MobileNativeFoundation/rules_xcodeproj
that referenced
this pull request
Dec 10, 2025
This is the third in a stack of PRs across three repositories. - bazelbuild/apple_support#491 - bazelbuild/rules_swift#1623 - #3250 <-- you are here It takes the approach suggested in #1119 and applies it in a way that scales better between codebases. By breaking sandboxing rules and remapping a derivable path to the source root, we can to allow Xcode, which book-keeps all code coverage representations in the IDE as absolute paths, to present code coverage information in the gutters and test results. It creates a new config, `rules_xcodeproj_coverage`, and enables a set of features unconditionally when it is enabled by the scheme setting that controls the `ENABLE_CODE_COVERAGE` build setting. This implementation requires #3111 in order for its assumptions to make sense and be testable. --- Notes for reviewers, and TODOs: - This PR requires the changes in those other PRs to work. - [x] I have tested what happens when you try to use this but those features don't exist, and **the result was a no-op**. - This PR does not provide feedback to users that their build will not be well-cached. - [x] I have produced a warning diagnostic as part of the build to inform users, if the features are not set. --------- Signed-off-by: Aaron Sky <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This is the first in a stack of PRs across three repositories.
It takes the approach suggested in MobileNativeFoundation/rules_xcodeproj#1119 and applies it to the xcode-clang toolchain. By breaking sandboxing rules and remapping a derivable path to the source root, we can to allow Xcode, which bookkeeps all code coverage representations in the IDE as absolute paths, to present code coverage information in the gutters and test results.