Skip to content

fix(analysis): fall back to LLVM's demangler when the C++ runtime's fails - #241

Draft
SizzleUnrlsd wants to merge 5 commits into
mainfrom
240-demangle-fallback
Draft

SizzleUnrlsd wants to merge 5 commits into
mainfrom
240-demangle-fallback

Conversation

@SizzleUnrlsd

@SizzleUnrlsd SizzleUnrlsd commented Oct 21, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #240

Problem

ctrace_tools::isMangled and ctrace_tools::demangle read a symbol with the C++ runtime's abi::__cxa_demangle only. A runtime whose demangler predates a mangling rejects the symbol, and every caller then shows the symbol: diagnostics through formatFunctionNameForMessage, the function filters and the stack report. A C++23 explicit object member function, _ZNH6Reader4peekERKS_Pi, is one: macOS 14's runtime and Ubuntu 22.04's (libstdc++ of GCC 11) reject it, while Ubuntu 24.04's, macOS 27's and LLVM 20's demangler read it.

Change

src/mangle.cpp: isMangled and demangle share one reading. The runtime's __cxa_demangle comes first, then LLVM's llvm::itaniumDemangle when the runtime's fails. The fallback is generic: it does not depend on the platform or on the symbol. A name that neither reads stays a plain name. Where the runtime already reads a symbol, nothing changes.

include/mangle.hpp: isMangled becomes a declaration taking a std::string_view, defined in mangle.cpp. The StringLike concept, which only this template used, goes. LLVMDemangle already comes with LLVMSupport, so no dependency is added.

Tests

testSymbolDemangling (test/unit/analyzer_module_unit_tests.cpp) covers the explicit object member's symbol: it is recognized as mangled, shown demangled, and named demangled in a message. Three controls cover a member's symbol, a C function's name, and a name that no demangler reads.

Outside CI Ubuntu 22.04, libstdc++ of GCC 11, in Docker macOS 27, locally
main (f846712), without the fix the three explicit object checks fail; the controls pass all pass: its runtime reads the symbol
with the fix all pass all pass

The test was compiled on Ubuntu 22.04 as the unit test file has it, against the real src/mangle.cpp and src/analysis/AnalyzerUtils.cpp, in a Docker image with LLVM 20 that keeps GCC 11's runtime. On macos-14, which no longer runs (#258), #239's CI showed the defect through the fixture const-suggestion-explicit-object.cpp of #217's branch.

Validation

At 3027b09, fa16d43 updated with main at 703da23: the diff against main is still this change alone, include/mangle.hpp, src/mangle.cpp and the unit test (3 files, +55 −32). src/mangle.cpp, include/mangle.hpp and testSymbolDemangling are the same as at 270955e. Its CI passes (below).

At 270955e, on macOS (LLVM 20): built without warning; the unit tests and the ownership tests pass; the suite, as CI runs it, passes 2415/2415, as on main.

CI and code scanning

  • CI on 3027b09 (merge ref c0c470b, into main at 703da23; its tree is the branch's): every check passes; the release job is skipped, as outside tags. The suite passes 2467/2467 on ubuntu-24.04, macos-15 and macos-latest, and the six checks of testSymbolDemangling pass on each.
  • What this CI does not show: the fallback taken for _ZNH6Reader4peekERKS_Pi. On ubuntu-24.04 and macos-latest, the runtime reads that symbol itself (in Symbols that the C++ runtime's demangler predates, such as C++23 explicit object members, stay mangled in the output #240, before the fallback existed, only macos-14 failed the explicit object fixture; the other runners ran the Ubuntu 24.04 and macOS 26 images they run now), so the fallback is not taken for it; on macos-15, the runtime is not measured without the fallback. macos-14, whose runtime rejects the symbol, no longer runs (ci: build on macos-15 with Xcode 16.0 before macos-14 is retired #258). The defect is shown on Ubuntu 22.04's runtime, in Docker (Tests, above), and on macos-14 by feat(const-param): experimental Clang check of const suggestions, version 2 #239's CI; the fix, by the same Docker run and earlier by 270955e's CI on macos-14 (below).
  • Code scanning on c0c470b: coretrace-stack-analyzer reported 70 results and coretrace-concurrency-analyzer none, as on main at 703da23. New alerts: none. The 65 alerts open on refs/pull/241/merge are the 65 open on main, alert for alert.

Earlier:

  • CI on 270955e (merge ref 32771e6, into main at f846712): every check passed. On macos-14 (Xcode 15.4), whose runtime does not read _ZNH6Reader4peekERKS_Pi, the six checks of testSymbolDemangling passed, and the suite passed 2415/2415.
  • Code scanning: coretrace-stack-analyzer reported 71 results there and coretrace-concurrency-analyzer none, as on main at f846712. New alerts: none. The 66 alerts then open on refs/pull/241/merge were the 66 then open on main, alert for alert.

SizzleUnrlsd added a commit that referenced this pull request Nov 1, 2026
GitHub retires the macos-14 image on November 2, 2026, and fails its jobs
during the scheduled brownouts before that (actions/runner-images#13518):
"Build on macos-14" was cancelled before any step on #239 and #241 on
October 30.

The job moves to macos-15 with Xcode 16.0, the oldest Xcode of that
image: its AppleClang 16.0.0 is the oldest Apple compiler GitHub's
runners still provide. The step fails if the image no longer has Xcode
16.0, rather than building with another one.

Two things are then no longer tested: AppleClang 15, the compiler the
job was added for (#228), since macos-14 is the only image with Xcode
15; and the macOS 14 C++ runtime, whose demangler predates C++23
explicit object members (#240). These are losses of coverage, not a
decision to drop compatibility with either.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Symbols that the C++ runtime's demangler predates, such as C++23 explicit object members, stay mangled in the output

1 participant