C++ Static Analysis Round-Table Notes — EuroLLVM 2026, Dublin

Clang Frontend
1

Originally proposed agenda: (based on the conference agenda)

  • Scalable Static Analysis Framework (SSAF): whole-program analysis
  • clang-reforge: whole-codebase refactoring
  • clang-tidy: custom tidy checks
  • Nullability attributes, and their adoption at scale
  • Lifetime safety and [[clang::noescape]]
  • Clang diagnostics at scale: backslide prevention for adoption
  • Clang Static Analyzer

The “C++ static analysis” round-table at EuroLLVM 2026 in Dublin brought together contributors from Apple, Ericsson, Google, Siemens, and other organizations. Most proposed topics saw lively discussion; lifetime safety did not come up.

Attendees

Organisers: Balázs Benics, Gábor Horváth
Andrea Guarino (SonarSource) Gleb Gladilov (Intel)
Anna Zaks @AnnaZaks (Apple) Jan Korous @jkorous (Apple)
Balázs Benics @steakhal (Apple) Jan Voung @jvoung (Google)
Branham Mouata Kristóf Umann @Szelethus (Ericsson)
Dániel Krupp @dkrupp (Ericsson) Kuba Mracek @kubamracek (Apple)
Dave Barolomeo @dbartol (Apple) Panagiotis Karouzakis @karouzakisp
David Tarditi @dtarditi (Apple) Petr Hosek @petrhosek (Google)
Donát Nagy @DonatNagyE (Ericsson) Philipp Niethammer (Vector Informatik)
Egor Zhdan @egor.zhdan (Apple) Tom James @TomJ (Siemens)
Gábor Horváth @Xazax-hun (Apple)

Clang-Tidy Custom Checks as Plugins

  • Clang-tidy custom checks as plugins rely on static initialization happening at a certain point — problematic on Windows
  • Siemens works around this by linking against the clang-tidy binary and providing their own main function
  • SSAF also has a documented plugin system that runs into similar Windows issues
  • Long-term goal: ensure cross-platform support so plugin mechanisms work reliably on all platforms
  • What should we do about making plugins easier?

Clang Static Analyzer Pain Points

Visibility and adoption:

  • One of the biggest problems may be that many developers simply do not run the analyzer — the community should do a better job advertising it
  • What should we do about making it easier to adopt and make our tooling more visible?

Alpha checkers:

  • Several checkers (e.g., iterator checks) have remained in the alpha package for many years without graduating to production
  • Only a few checkers model C+±specific features, and those are complicated because the engine does not model C++ natively
  • How should we improve C++ support?
  • What’s the plan for the alpha checkers, such as the iterator and container checks?

Loops and memory safety:

  • Growing interest in catching more memory safety errors, but CSA’s loop handling during symbolic execution is a bottleneck
  • The number of “unknown” symbolic iterations was recently changed from 3 to 2, but many problems remain
  • Would be valuable to more precisely simulate the last iteration symbolically
  • Loop widening: off by default, incomplete — the hard part is figuring out which memory locations the loop writes to and should be invalidated
  • Loop unrolling: also off by default; real-world testing suggests it is not worth enabling

Analysis Modes and Tradeoffs

  • CSA has a shallow mode (fast, fewer bugs) and a deep mode (thorough but draws complaints about speed)
  • A one-size-fits-all approach may not exist — different users need different tradeoffs between compilation time, FP/FN rates, and bug severity
  • Possible approaches: analysis profiles, opportunistic bug finding, severity-based prioritization (e.g., buffer overruns are more critical than stylistic issues)
  • More profiling of the analyzer is needed to understand where time is being spent

SSAF and Whole-Program Analysis

Function summaries:

  • Apple is developing SSAF (Scalable Static Analysis Framework) openly in upstream Clang — following the LLVM RFC process 1 2 3
  • SSAF creates function summaries at the translation unit level, aggregated at the linked unit level for whole-program reasoning
  • Iterative summaries are out of scope for now due to runtime complexity, but the framework can express them
  • First prototype analysis: whole-program CallGraph construction
  • Some of it is already upstream, but still requires patches to run as of today [04/15/2026].
  • SSAF summaries can also be used in CSA e.g. for less conservative pointer escape handling, or better conditional noreturn function modeling.

Dataflow Framework in Clang-Tidy

  • Clang-tidy has an experimental dataflow framework with an optional checker
  • Currently very unstable — on some projects, even the example checker never finishes
  • Google has a nullability attribute checker built on this framework; there is a recent upstream crash fix that may address reverse-null checker issues too
  • The framework is used in production by Google, so it is not abandoned

Reverse-null checker:

I just want my warnings…

  • Clang users find the experience confusing: multiple overlapping tools implement static analysis checks and emit output in different formats
  • In CSA, modeling checkers are invisible but their configurations have very visible effects — this should be more streamlined for end users
  • Open questions: how do we configure checks, and how do users actually run them?
  • Ericsson’s CodeChecker simplifies this by providing a unified interface for running CSA, clang-tidy, Infer, and the GCC static analyzer
  • clang has compiler warnings — can be produced part of compilation
  • clang static analyzer has it’s own CLI flags — and can’t be run part of compilation
  • clang-tidy is a separate tool, own CLI flags
  • The clang ecosystem should provide a more unified way to invoke different checks
  • Discussed checker names, and configurations — see later.

SARIF

  • Apple is driving SARIF support in Clang
  • The SARIF output option is somewhat unstable and not uniform across CSA and clang diagnostics and clang-tooling in general
  • The basics are covered; an upcoming patch will emit reports even when suppressed
  • Clang-tidy does not yet have a SARIF emitter
  • Fingerprinting/issue hashing:
    • Needs to be unified across tools and made more resilient
    • Tricky for clang-tidy or compiler diagnostics where a function declaration is not always available
    • Even checker renames can change the fingerprint, breaking result tracking across builds

Checker Names and Packages

  • CSA’s package-based naming system is outdated and no longer appropriate
  • Renaming every checker is desirable but must not break existing configuration files
  • Clang-tidy has a similar problem; the SEI-CERT aliases are a particular offender
  • Package names make it easy to see relevance, but labels can achieve the same thing — and a checker can have many labels vs. only one group
  • Pre-made checker sets (security, default, etc.) would let users opt in at a high level, with new checkers automatically included in the relevant sets
  • Consensus: flat checker names with labels is the preferred direction

Backslide Prevention

  • Apple has been working on backslide prevention — preventing regressions when rolling out diagnostics at scale
  • Once a diagnostic is enabled and existing violations are addressed, new code should not reintroduce violations
  • Briefly discussed in the latter half of the session

Miscellaneous

  • Conditional abort functions: not well supported in CSA, because it doesn’t know that for example log would never return if the first argument is ABORT: log(ABORT, cond, "some message");
  • Header-only file checkers: include-fixer style checkers (also in clangd) — adding includes is almost always safe, but removal can be dangerous, especially in header files
  • Multiple consumers during compilation: it would be great to attach CSA, clang-tidy, and custom tools in a single pass. This would mean that the source code parsing would only happen once.
    However, CSA and clang-tidy expose the __clang_analyzer__ macro which alters the AST, preventing the reuse of the AST across all of these ASTConsumers in a pipeline. We should find a way to have this “pipeline” flow for the users not using this macro. We should develop alternatives to migrate users away from using this macro.

Next Steps

The round-table attendees agreed to set up a Static Analysis Working Group to meet regularly and continue these discussions. Balázs Benics will organize this. Schedule is TBD.

You can also find the EuroLLVM 2025 Static Analysis Round-Table notes here.
To unsubscribe, click on the bell icon and switch from Watching to either Normal or Muted.

6 Likes
LLVM Weekly - #644, May 4th 2026
2

How do I request to join the working group?

3

I’ll create the RFC probably next week. I’ll cross-reference it from here as well.

1 Like
4

Here is the RFC proposing the working group.