[libcxx-commits] [PATCH] D117174: [libc++][test] Run clang-tidy during CI

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added a comment.

In D117174#3284177 <https://reviews.llvm.org/D117174#3284177>, @ldionne wrote:

> This LGTM, however would it make sense to remove some of the checks we did using Python scripts now?

I would (of course ;)) recommend against removing the Python checks, because they're simpler and more maintainable. In the sense that if they ever became annoying in some small way (like, I dunno, we decide to move `<__config>` back to the top of every include list) we could modify the single relevant line of Python code to fix the issue, whereas with clang-tidy it'd be much more of an all-or-nothing situation — there might be no way to "slightly adjust" a clang-tidy check without making a PR against clang-tidy itself. It's also easier to see that we test a certain invariant if it's right there in libcxx/test/, versus having to poke around in the build system. (Heck, it might even make sense to move the clang-tidy check itself into libcxx/test/, in the form of a test that verifies clang-tidy exists and then calls into it! But I don't know.)
I guess I'm philosophically puzzled: what if anything is the invariant here? Are we committing to "libc++ 14 compiles clean with clang-tidy 14" as an invariant? (If so, having a test that calls into clang-tidy would make a lot of sense.) Or are we just using clang-tidy as a handy //tool// because it happens to detect a few of our existing invariants out of the box (and so we're actually Hyrum's-Law-ing `clang-tidy` such that if it changed its behavior in certain ways we'd have to move off it again, just like we're currently Hyrum's-Law-ing `python` and `grep`)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117174/new/

https://reviews.llvm.org/D117174