[clang] [analyzer] Conversion to CheckerFamily: NullabilityChecker (PR #143735)

[Donát Nagy via cfe-commits]

================
@@ -113,25 +114,21 @@ class NullabilityChecker
   void printState(raw_ostream &Out, ProgramStateRef State, const char *NL,
                   const char *Sep) const override;
 
-  enum CheckKind {
-    CK_NullPassedToNonnull,
-    CK_NullReturnedFromNonnull,
-    CK_NullableDereferenced,
-    CK_NullablePassedToNonnull,
-    CK_NullableReturnedFromNonnull,
-    CK_NumCheckKinds
-  };
-
-  bool ChecksEnabled[CK_NumCheckKinds] = {false};
-  CheckerNameRef CheckNames[CK_NumCheckKinds];
-  mutable std::unique_ptr<BugType> BTs[CK_NumCheckKinds];
-
-  const std::unique_ptr<BugType> &getBugType(CheckKind Kind) const {
-    if (!BTs[Kind])
-      BTs[Kind].reset(new BugType(CheckNames[Kind], "Nullability",
-                                  categories::MemoryError));
-    return BTs[Kind];
-  }
+  StringRef getDebugTag() const override { return "NullabilityChecker"; }
+
+  // FIXME: All bug types share the same Description ("Nullability") since the
+  // creation of this checker. We should write more descriptive descriptions...
+  // or just eliminate the Description field if it is meaningless?
----------------
NagyDonat wrote:

> How is the `Description` displayed to the user?

The `Description`  is included in the `plist` output (which is a machine-friendly "raw" output format), so tools that consume `plist` may display it to the user -- but e.g. CodeChecker ignores it. (In the HTML output, the `Description` of the bug type appears within a `<!-- BUGTYPE ... -->` comment, i.e. it's there perhaps for debugging purposes but not actually visible.)

Moreover, the `Description` of the `BugType` affects the hash and the ordering of the `PathDiagnostic` objects, so perturbing it will influence the analyzer results.

> Can we use the `HelpText` from `Checkers.td` as the Description?

No, the `HelpText` is associated with a whole checker (more precisely, a user-facing `CheckerFrontend` like `nullability.NullPassedToNonnull`), while this `Description` is a data member of a `BugType` -- and a single `CheckerFrontend` may "own" multiple `BugType`s. (In this particular checker there is 1:1 correspondence between the `CheckerFrontend`s and `BugType`s, so I'm using the trivial convenience wrapper `CheckerFrontendWithBugType` to initialize a `CheckerFrontend` and the single `BugType` which belongs to it, but this is not the general case.)

Also, AFAIK the `Description` of the bug type is usually a very short name-like string, while the `HelpText` is a somewhat longer documentation-like text. 

https://github.com/llvm/llvm-project/pull/143735