[all-commits] [llvm/llvm-project] ec96c0: [analyzer] Fix tagging of PostAllocatorCall (#142132)

[Donát Nagy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ec96c0c072ef3f78813c378949c00e1c07aa44e5
      https://github.com/llvm/llvm-project/commit/ec96c0c072ef3f78813c378949c00e1c07aa44e5
  Author: Donát Nagy <donat.nagy at ericsson.com>
  Date:   2025-06-03 (Tue, 03 Jun 2025)

  Changed paths:
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h
    M clang/lib/StaticAnalyzer/Core/CheckerManager.cpp

  Log Message:
  -----------
  [analyzer] Fix tagging of PostAllocatorCall (#142132)

By design the `Location` data member of a `CheckerContext` is always a
`ProgramPoint` which is tagged with the currently active checker (note
that all checker classes are subclasses of `ProgramPointTag`). This
ensures that exploded nodes created by the checker are by default tagged
by the checker object unless the checker specifies some other tag (e.g.
a note tag) when it calls the `addTransition`-like method that creates
the node.

This was followed by all the `CheckerManager::runCheckersForXXX`
methods, except for `runCheckerForNewAllocator`, where the
implementation constructed the `PostAllocatorCall` program point which
was used to create the `CheckerContext` without passing
`checkFn.Checker` as the tag of the program point.

This commit elimintates this inconsistency and adds an assertion to the
constructor of `CheckerContext` to ensure that this invariant will be
upheld even if we e.g. add a new program point kind.

I strongly suspect that this is a non-functional change because program
point tags are a vestigial feature in the codebase that barely affect
anything -- but e.g. their presence affects the infamous node
reclamation process, so I'm not marking this as NFC.



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