sammccall added inline comments.
================ Comment at: clang-tidy/ClangTidy.h:11 +// +// It should remain as stable as possible, as many out-of-tree checks exist. +//===----------------------------------------------------------------------===// ---------------- steveire wrote: > Clang C++ code does not have any stability requirements. That's quite > well-established. > > This comment adds a new requirement of stability for this C++ API. You should > probably put a RFC on cfe-dev about it. This header is no more public or > stable than any other Clang header. > > > Clang C++ code does not have any stability requirements. That's quite > well-established. I was aiming for "stability is a design goal", not "this is a stable API and you may not break it". Happy to take a shot at rewording, maybe you have suggestions? > This comment adds a new requirement of stability for this C++ API. You should > probably put a RFC on cfe-dev about it. Stability here has always been an aim; I'm trying to document the current state of the world. e.g. in D15528 @alexfh wrote: > It's one of the goals of clang-tidy to provide an easy way to maintain > out-of-tree checks. > This header is no more public or stable than any other Clang header. I wish that were true - my current yakshave is reducing the need for `registerPPCallbacks` to make clang-tidy more flexible for use in a library. Removing it entirely would be great but having talked to some clang-tidy maintainers, out-of-tree checks are at least a factor here. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D53936 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
