================
@@ -115,9 +115,22 @@ class CheckerRegistry {
public:
/// Adds a checker to the registry. Use this non-templated overload when your
/// checker requires custom initialization.
- void addChecker(RegisterCheckerFn Fn, ShouldRegisterFunction sfn,
+ void addChecker(RegisterCheckerFn Fn, ShouldRegisterFunction Sfn,
+ StringRef FullName, StringRef DebugName, StringRef Desc,
+ StringRef DocsUri, bool IsHidden);
+
+ /// Adds a checker to the registry. This overload doesn't take a `DebugName`
+ /// (which usually looks like `DivZeroChecker`), so it uses the user-facing
+ /// `FullName` (which usually looks like ``core.DivideZero`) as a debug name.
+ /// THIS IS DEPRECATED and is only provided to preserve compatibility with
+ /// legacy plugins.
+ /// TODO: Eventually remove this from the codebase.
----------------
NagyDonat wrote:
> I see. Maybe we could expose a macro to fill the debug name with the
> stringified token of the class?
I'm not a fan of macros but this could be a good use of them if it makes it
more ergonomic.
Most of these are mock checkers where the debug name is completely irrelevant,
they won't be used for actual analysis. In fact I created a method called
`addMockChecker(StringRef FullName)` which is sufficient for these simple
situations.
> And btw, could we assert that when adding a checker the debug names are
> unique?
Perhaps, although providing unique debug names for the mock checkers in the
unit tests is pointless. Overall, the whole "debug name" concept is an
extremely unimportant feature that is only used during manual investigation of
bugs, so IMO it doesn't deserve complex assertions and we should stop designing
our whole architecture around it.
https://github.com/llvm/llvm-project/pull/139256
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
