Enable code coverage in Xcode #3250
Open
+60
−1
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
Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>
This was referenced Dec 3, 2025
Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>
aaronsky
force-pushed
the
aaronsky/enable-code-coverage-in-xcode
branch
from
bcbfc88 to
a54c242
Compare
aaronsky
added a commit
to bazelbuild/apple_support
that referenced
this pull request
Dec 5, 2025
This is the first in a stack of PRs across three repositories. - #491 <-- you are here - bazelbuild/rules_swift#1623 - MobileNativeFoundation/rules_xcodeproj#3250 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.
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.
|
Very excited for this! |
Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>
adincebic
approved these changes
Dec 6, 2025
aaronsky
commented
Dec 6, 2025
…ompromises with this approach to users Signed-off-by: Aaron Sky <aaronsky@skyaaron.com>
brentleyjones
approved these changes
Dec 9, 2025
Contributor
|
Do we need to mention in the docs the minimum apple_support and rules_swift versions needed to make this work? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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 third in a stack of PRs across three repositories.
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 theENABLE_CODE_COVERAGEbuild setting.This implementation requires #3111 in order for its assumptions to make sense and be testable.
Notes for reviewers, and TODOs: