[all-commits] [llvm/llvm-project] ea107d: [NFC][analyzer] Use `CheckerBase::getName` in chec...

[Donát Nagy via All-commits]

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

  Changed paths:
    M clang/include/clang/Analysis/ProgramPoint.h
    M clang/include/clang/StaticAnalyzer/Core/Checker.h
    M clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
    M clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
    M clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
    M clang/unittests/StaticAnalyzer/AnalyzerOptionsTest.cpp

  Log Message:
  -----------
  [NFC][analyzer] Use `CheckerBase::getName` in checker option handling (#131612)

The virtual method `ProgramPointTag::getTagDescription` had two very
distinct use cases:
- It is printed in the DOT graph visualization of the exploded graph
(that is, a debug printout).
- The checker option handling code used it to query the name of a
checker, which relied on the coincidence that in `CheckerBase` this
method is defined to be equivalent with `getName()`.

This commit switches to using `getName` in the second use case, because
this way we will be able to properly support checkers that have multiple
(separately named) parts.

The method `reportInvalidCheckerOptionName` is extended with an
additional overload that allows specifying the `CheckerPartIdx`. The
methods `getChecker*Option` could be extended analogously in the future,
but they are just convenience wrappers around the variants that directly
take `StringRef CheckerName`, so I'll only do this extension if it's
needed.



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