Question about custom Clang static analyzer checker registration in clang-tidy without using plugin

Friendly ping on this.

Hmm, okay, i see, well, i mean, in approach #1 i was thinking about moving the global registry to clang-tidy and keeping the clang binary free from it, because clang-tidy is a smaller tool and less things could go wrong.

I personally have no immediate objections against having a global registry of statically-linked-in (is it even a word?) checkers in the analyzer, with a clear explanation of why this is necessary and what to do with it if the global becomes a problem, examples, ideally tests of course (if it would be easy enough with our build system; we don't seem to have tests for our plugins, not sure why). After all, i doubt we'd ever (or any time soon) have to restart the analysis with a different list of statically-linked-in checkers without restarting the clang process. So i'll accept patches in this direction as well.

I guess llvm::ManagedStatic<> would be handy.

We’ve talked with George offline and we seem to have found a maintainable solution. I’ve sent for review.