@@ -526,7 +526,7 @@ class CheckerBase : public CheckerFrontend, public CheckerBackend {
526526public:
527527 // / Attached to nodes created by this checker class when the ExplodedGraph is
528528 // / dumped for debugging.
529- StringRef getTagDescription () const override ;
529+ StringRef getDebugName () const override ;
530530};
531531
532532// / Simple checker classes that implement one frontend (i.e. checker name)
@@ -547,16 +547,16 @@ class Checker : public CheckerBase, public CHECKs... {
547547// / callbacks (i.e. classes like `check::PreStmt` or `eval::Call`) as template
548548// / arguments of `FamilyChecker.`
549549// /
550- // / NOTE: Classes deriving from `CheckerFamily` must implement the pure
551- // / virtual method `StringRef getTagDescription ()` which is inherited from
552- // / `ProgramPointTag` and should return the name of the class as a string.
550+ // / NOTE: Classes deriving from `CheckerFamily` must implement the pure virtual
551+ // / method `StringRef getDebugName ()` which is inherited from `ProgramPointTag`
552+ // / and should return the name of the class as a string.
553553// /
554554// / Obviously, this boilerplate is not a good thing, but unfortunately there is
555555// / no portable way to stringify the name of a type (e.g. class), so any
556- // / portable implementation of `getTagDescription ` would need to take the
557- // / name of the class from *somewhere* where it's present as a string -- and
558- // / then directly placing it in a method override is much simpler than
559- // / loading it from `Checkers.td`.
556+ // / portable implementation of `getDebugName ` would need to take the name of
557+ // / the class from *somewhere* where it's present as a string -- and then
558+ // / directly placing it in a method override is much simpler than loading it
559+ // / from `Checkers.td`.
560560// /
561561// / Note that the existing `CLASS` field in `Checkers.td` is not suitable for
562562// / our goals, because instead of storing the same class name for each
0 commit comments