[all-commits] [llvm/llvm-project] f0088e: [analyzer] Delay the checker constructions after p...

[Balazs Benics via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f0088ee87cecfb442921251b4a70f96cf3474a15
      https://github.com/llvm/llvm-project/commit/f0088ee87cecfb442921251b4a70f96cf3474a15
  Author: Balazs Benics <benicsbalazs at gmail.com>
  Date:   2025-02-22 (Sat, 22 Feb 2025)

  Changed paths:
    M clang/lib/StaticAnalyzer/Checkers/UnixAPIChecker.cpp
    M clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

  Log Message:
  -----------
  [analyzer] Delay the checker constructions after parsing (#127409)

If we were to delay checker constructions after we have a filled
ASTContext, then we could get rid of a bunch of "lazy initializers" in
checkers.

Turns out in the register functions of the checkers we could transfer
the ASTContext and all other things to checkers, so those could benefit
from in-class initializers and const fields.

For example, if a checker would take the ASTContext as the first field,
then the rest of the fields could use it in their in-class initializers,
so the ctor of the checker would only need to set a single field!

This would open uup countless opportunities for cleaning up the
asthetics of our checkers.

I attached a single use-case for the AST and the PP as demonstrating
purposes. You can imagine the rest.

**FYI: This may be a breaking change** to some downstream users that may
had some means to attach different listeners and what not to e.g. the
Preprocessor inside their checker register functions. Since we delay the
calls to these register fns after parsing is already done, they would of
course miss the parsing Preprocessor events.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications