Description
Building a CodeQL database from current Chromium main fails in the C++ extractor on
libc++ headers that Chromium now ships. The database is still created, but many
translation units are only partially extracted and the resulting database is not
usable for Chromium analysis. I have reproduced this with CodeQL CLI 2.23.8,
2.25.1 and 2.26.4 (the latest release at the time of filing).
The docs currently list C/C++ Clang extension support "up to Clang 21"
(https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/),
while Chromium main is on Clang 24. In addition to that toolchain gap, the
extractor also rejects two constructs that the actual Chromium compiler accepts
with -std=c++23, so I'm reporting both here.
Environment
- OS: Linux x64
- CodeQL CLI: 2.23.8 / 2.25.1 / 2.26.4
- Chromium: main @
cdcb642e42ae541a7681f38b24d4cf4d1fbbcb0c (2026-09-03)
- Chromium clang revision:
llvmorg-24-init-3796-g20e97c4b (binary reports clang version 24.0.0git)
- libc++ revision in Chromium DEPS (
libcxx_revision):
97b436da4c33663581d394f4ee0a5977fc38c2f4
Expected behavior
codeql database trace-command completes and the database contains the
Chromium/libc++ code that the real Clang 24 toolchain accepts.
Actual behavior
Extractor diagnostics, seen for many translation units:
../../third_party/libc++/src/include/tuple, line 991:
error: pack expansion does not make use of any argument packs
../../third_party/libc++/src/include/__math/abs.h, line 74:
error: expected a ";"
The offending tuple code (from libc++ 97b436da, include/tuple, lines 985-991):
template <class _Tuple>
static constexpr bool __can_compare_equal = false;
template <class... _Up>
static constexpr bool __can_compare_equal<tuple<_Up...>> = __all<requires(const _Tp& __t,
const _Up& __u) {
{ __t == __u } -> __boolean_testable;
}...>::value;
The offending abs code (from libc++ 97b436da, include/__math/abs.h, lines 70-77):
#if defined(__BITINT_MAXWIDTH__)
// _BitInt does not integer-promote, so without a same-type overload a narrow
// signed _BitInt would be an ambiguous call against abs(int/long/long long).
template <int _Np>
[[__nodiscard__]] _LIBCPP_HIDE_FROM_ABI _BitInt(_Np) abs(_BitInt(_Np) __x) _NOEXCEPT {
return __x < 0 ? -__x : __x;
}
#endif
Both snippets compile cleanly with Chromium's bundled Clang 24 using -std=c++23.
How to reproduce
Check out Chromium main (current DEPS must contain
libcxx_revision: '97b436da4c33663581d394f4ee0a5977fc38c2f4') and sync its
dependencies, then:
gn gen out/codeql --args='is_official_build=false is_debug=false symbol_level=0
v8_symbol_level=0 blink_symbol_level=0 is_component_build=false proprietary_codecs=true
ffmpeg_branding="Chrome" v8_enable_sandbox=true dcheck_always_on=false target_os="linux"
target_cpu="x64" use_clang_modules=false chrome_pgo_phase=0'
codeql database init --language=cpp --source-root=/path/to/chromium/src /path/to/chromium-
codeql-db
codeql database trace-command --working-dir=/path/to/chromium/src /path/to/chromium-codeql-db
-- ninja -j8 -C out/codeql chrome/browser:browser content/browser:browser
codeql database finalize /path/to/chromium-codeql-db
The extractor errors appear during the trace-command step. Extractor logs are
under /path/to/chromium-codeql-db/log/. I can provide the full extractor log
from one failing translation unit if needed; the full Chromium build log is also
available on request.
Related issues
This is the same class of Chromium database build problem previously reported in
#16783 and
#16901. Being able to build a complete
database from current Chromium main would unblock real-world C++ analysis on the
largest continuously-updated C++ codebase, and these libc++ errors currently make
that impossible.
Description
Building a CodeQL database from current Chromium main fails in the C++ extractor on
libc++ headers that Chromium now ships. The database is still created, but many
translation units are only partially extracted and the resulting database is not
usable for Chromium analysis. I have reproduced this with CodeQL CLI 2.23.8,
2.25.1 and 2.26.4 (the latest release at the time of filing).
The docs currently list C/C++ Clang extension support "up to Clang 21"
(https://codeql.github.com/docs/codeql-overview/supported-languages-and-frameworks/),
while Chromium main is on Clang 24. In addition to that toolchain gap, the
extractor also rejects two constructs that the actual Chromium compiler accepts
with
-std=c++23, so I'm reporting both here.Environment
cdcb642e42ae541a7681f38b24d4cf4d1fbbcb0c(2026-09-03)llvmorg-24-init-3796-g20e97c4b(binary reportsclang version 24.0.0git)libcxx_revision):97b436da4c33663581d394f4ee0a5977fc38c2f4Expected behavior
codeql database trace-commandcompletes and the database contains theChromium/libc++ code that the real Clang 24 toolchain accepts.
Actual behavior
Extractor diagnostics, seen for many translation units:
../../third_party/libc++/src/include/tuple, line 991:
error: pack expansion does not make use of any argument packs
../../third_party/libc++/src/include/__math/abs.h, line 74:
error: expected a ";"
The offending tuple code (from libc++
97b436da,include/tuple, lines 985-991):Both snippets compile cleanly with Chromium's bundled Clang 24 using -std=c++23.
How to reproduce
Check out Chromium main (current DEPS must contain
libcxx_revision: '97b436da4c33663581d394f4ee0a5977fc38c2f4') and sync its
dependencies, then:
gn gen out/codeql --args='is_official_build=false is_debug=false symbol_level=0
v8_symbol_level=0 blink_symbol_level=0 is_component_build=false proprietary_codecs=true
ffmpeg_branding="Chrome" v8_enable_sandbox=true dcheck_always_on=false target_os="linux"
target_cpu="x64" use_clang_modules=false chrome_pgo_phase=0'
codeql database init --language=cpp --source-root=/path/to/chromium/src /path/to/chromium-
codeql-db
codeql database trace-command --working-dir=/path/to/chromium/src /path/to/chromium-codeql-db
-- ninja -j8 -C out/codeql chrome/browser:browser content/browser:browser
codeql database finalize /path/to/chromium-codeql-db
The extractor errors appear during the trace-command step. Extractor logs are
under /path/to/chromium-codeql-db/log/. I can provide the full extractor log
from one failing translation unit if needed; the full Chromium build log is also
available on request.
Related issues
This is the same class of Chromium database build problem previously reported in
#16783 and
#16901. Being able to build a complete
database from current Chromium main would unblock real-world C++ analysis on the
largest continuously-updated C++ codebase, and these libc++ errors currently make
that impossible.