[PATCH] D53936: [clang-tidy] More clearly separate public, check-facing APIs from internal ones.

[Sam McCall via Phabricator via cfe-commits]

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