Summary
We have added SonarQube integration to a Mac app build pipeline (GitHub repo, Azure DevOps CI). Debug logging shows that CFamily fails to resolve size_t, wchar_t and NULL while parsing Apple’s own SDK headers on all but one of the 1000+ Objective-C translation units it analyses:
module '_c_standard_library_obsolete' requires feature 'found_incompatible_headers__check_search_paths'
This means that stddef.h’s types are never defined, and the failure cascades through 150+ distinct SDK headers. That produces more than one million diagnostics in a single run and leaves a third of our functions unparsed. None of the diagnostics are in our own code.
We believe this is a CFamily incompatibility with the Xcode 26.5 / macOS 26.5 SDK rather than a configuration problem on our side, and would like to know whether this is a known issue.
Environment
| Component | Version/Notes |
|---|---|
| SonarQube Server | Enterprise Edition 2026.1.5.126862 (LTA) |
| CFamily plugin | 6.77.0.95488 |
| Scanner | SonarScanner CLI 8.1.0.6389 |
| JRE | Homebrew OpenJDK 21.0.12.1 |
| Host | macOS 26.5.1, aarch64, 8 cores, 16 GB |
| Toolchain | Xcode 26.5, MacOSX26.5.sdk (reached through the MacOSX.sdk symlink) |
| Project | ~1,900 Objective-C translation units, mixed Objective-C and Swift, built by Xcode |
Setup
Analysis runs in Compile-Commands mode. compile_commands.json is produced with clang’s -gen-cdb-fragment-path, injected via OTHER_CFLAGS into an xcodebuild run. This is an approach shown among the third-party alternatives on the CFamily prerequisites page. After a clean build, the per-translation-unit fragments are concatenated. Build Wrapper is not used since that page notes that it does not work as expected with recent versions of Xcode.
We analyse in two places:
- Pull request: an
xcodebuild testbuild for the build server’s architecture. The run captured withsonar.verbose=trueis the source of the diagnostic counts below. developbranch: anxcodebuild archivefor Intel + ARM.
Diagnostics
These are the top seven of ~ 1,175,000 diagnostic lines from one pull-request run with
sonar.verbose=true, grouped by message:
508812 unknown type name 'X'
449738 unknown type name 'X'; did you mean 'X'?
59672 module 'X' requires feature 'X'
49983 function cannot return function type 'X' (aka 'X')
20913 use of undeclared identifier 'X'
20736 field 'X' declared as a function
10359 a parameter list without types is only allowed in a function definition
The remaining ~55,000 are spread across less frequent messages. They all originate inside the SDK, not in our sources. Two examples:
<repo>/path/to/our/class.m:
/Applications/Xcode-26.5.app/…/MacOSX.sdk/usr/include/arm/_types.h:85 - unknown type name 'size_t'
<repo>/path/to/our/class.m:
/Applications/Xcode-26.5.app/…/MacOSX.sdk/usr/include/alloca.h:35 - unknown type name 'size_t'; did you mean 'ssize_t'?
size_t is not merely unknown but misresolved, which causes the errors to cascade:
function cannot return function type 'size_t' (aka 'int (int * _Nonnull)')
The top six affected headers are:
362565 MacOSX.sdk/usr/include
110496 MacOSX.sdk/usr/include/xlocale
82872 MacOSX.sdk/usr/include/malloc
69060 MacOSX.sdk/System/Library/Frameworks/Security.framework/Versions/A/Headers
48342 MacOSX.sdk/usr/include/xpc
44889 MacOSX.sdk/usr/include/cups
Potentially related issues
Parse coverage: Every unit reports as fully analysed with nothing stopped on Parsing, but a third of our functions fail to parse:
1158 compilation units were fully analyzed
0 compilation units were partially analyzed: 0 stopped on Config, 0 stopped on Parsing, …
76.50% of classes were parsed successfully (937 of 3987 have parsing errors) [77.17%, 910 of 3986]
66.35% of functions were parsed successfully (4036 of 11994 have parsing errors) [66.37%, 4029 of 11982]
83.26% of statements were parsed successfully (22476 of 134294 have parsing errors)[83.26%, 22438 of 134051]
C and C++ analysis quality score: 81.53/100 [81.7/100]
We would like to understand how “fully analysed, 0 stopped on Parsing” and “4,036 functions with parsing errors” can both be reported for the same run.
Precompiled headers are never used: All 1,158 units declare a force-included prefix header, and none is precompiled:
PCH: unique=0 use=0 (forceInclude=0,throughHeader=0,firstInclude=0) out of 1158 (forceInclude=1158,throughHeader=0)
Our two prefix headers also appear in the unsupported bucket (see below). Since a prefix header that includes Cocoa transitively includes the C standard library, we suspect the PCH cannot be built for the same reason the headers cannot be parsed.
Time is mostly spent on parsing:
CFamily analysis done in: 2118054ms (35.3 minutes, 1158 units, 8 threads) [2200592ms]
parsingStage: 16547974ms, 14290ms avg, 98.53% [17167491ms, 14825ms, 98.43%]
symbolicExecutionStage: 151612ms, 130ms avg, 0.90% [ 164301ms, 141ms, 0.94%]
astRulesStage: 80026ms, 69ms avg, 0.48% [ 87522ms, 75ms, 0.50%]
Emitting ~1,000 diagnostics per unit might be the issue.
Questions
-
Is CFamily 6.77.0.95488 expected to support the Xcode 26.5 / macOS 26.5 SDK? Is
module '_c_standard_library_obsolete' requires feature 'found_incompatible_headers__check_search_paths'a known incompatibility? We are on 2026.1 LTA; the 2026.2 and 2026.3 release notes list no CFamily, Xcode, Apple-SDK or clang-modules entries, so we cannot tell from them whether upgrading would help. Is there a CFamily or SonarQube version that resolves this? -
Is there a workaround in the meantime? For example, an analysis property, an older SDK, or additional flags in the compilation database that would let the C standard library resolve?
-
How should “every unit fully analysed, 0 stopped on Parsing” be read alongside “4,036 of 11,994 functions have parsing errors”? Should a unit whose SDK headers fail to parse not be reported as partially analysed or failed?
-
Is Objective-C++ (
.mm) supported by CFamily at all? Six of our files are skipped as unsupported. We would like to know whether that is permanent or if we misconfigured something. -
Why does
Analysis cachereport no hits when the log shows that the cache has been loaded? Most caches do work after analysing the target branch, but the per-compilation-unitAnalysis cacheline still reports 0 of 1131 hits in the same run whose incremental symbolic execution cache hit ~40% and re-used ~500 path diagnostics. The decode statistics in that run may be related; they are all zero when nothing is decoded:Successful cache reads, writes: 1131, 1131 for 1131 target compilation unit(s) (100%, 100%) Unsupported cases in USR conversion decoding, encoding: 3731, 0 Unsupported cases in issue-relocation decoding, encoding: 41, 0 Top-level declarations dropped decoding, encoding: 1082, 1Is
Analysis cache: 0/1131expected alongside a working symbolic-execution cache, or is the per-unit cache being rejected? Do the unsupported USR conversions and dropped top-level declarations explain it? Unfortunately, the re-use improves almost nothing.
The full 374 MB debug log is available on request, and we can produce a sonar.cfamily.reproducer capture for one of the affected translation units if that would help.