[PATCH] D26342: [analyzer] Add MutexChecker for the Magenta kernel

[Artem Dergachev via cfe-commits]

NoQ added a comment.

In https://reviews.llvm.org/D26342#590881, @khazem wrote:

> I think that it's sensible to try merging this with PthreadLockChecker. In fact, I could also try merging the SpinLockChecker [1] that I've posted for review with PthreadLockChecker also, since they all implement similar functionality.


That'd be great!

In https://reviews.llvm.org/D26342#590881, @khazem wrote:

> Here is my proposal: I could try refactoring the PthreadLockChecker into a LockChecker class, which would be instantiated as various subclasses (for Pthread, XNU, Magenta, and others in the future). The common functionality would be implemented in LockChecker, but the user would ask for a specific checker using command-line flags. Using subclasses would hopefully prevent the class from becoming a mess of if/switch statements, while allowing future LockCheckers to be implemented for other lock APIs. Does this seem reasonable?


We usually go with the if/switch approach (in this case we instantly see what's the difference between the two APIs), and i think we don't do checker inheritance anywhere, but i don't have good reasons to instantly prefer one over the other, so it's be nice to know if inheritance is actually better here.

Note that if all you want is to enable/disable platform-specific checks separately with `-analyzer-checker` options, or have separate lines for the checks in `Checkers.td` (and auto-enable magenta checkers if the magenta target platform is detected), then you don't necessarily need to produce separate `Checker<>` classes/instances in your C++ code for that. We can have different checkers point to the same C++ checker object. See `unix.Malloc` and `cplusplus.NewDelete` as an example (they're essentially the same checker) - the tricks are in `registerChecker` procedure.


https://reviews.llvm.org/D26342