Post

Replies

Boosts

Views

Activity

Reply to Error reporting test coverage in Xcode 14.3.1
After a bunch of debugging in the llvm-profdata source code to understand how .profraw Version 8 files work, and then doing some hex editing of my corrupted output .profraw file in DerivedData to remove the corrupted section of the file, I think I have determined which framework we include that is breaking my project: MBProgressHUD. After all of that, I was able to see a simple way of determining the included frameworks that will corrupt the ProfData: Go to the Carthage/Build folder (or wherever your included .xcframework folders are) and look at the modified date of each framework's Info.plist. Any really old ones are likely to break, and the only one I have in this project before 2023 is the one for MBProgressHUD (which is from 2021, which is definitely way before XCode 14.3).
Dec ’23
Reply to Error in gathering code coverage in Xcode16
I have figured out what's happening here. Code Coverage will ONLY work if ALL upstream dependencies have also been built with the newer version of XCode (and therefore the newer version of clang). A single profraw file will have multiple sections from the many different binaries that make up your build and each of those sections will have a header containing the raw profile version format of the clang that built that binary. For example, my framework built in XCode26 that depends on a binary framework built in XCode16.2 will have profraw headers with both 8 and 10 as the version, meaning that the resulting profraw file cannot be read in XCode26 (which can only read version 10) nor in XCode16.2 (which can only read version 8).
Aug ’25