This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] More clearly separate public, check-facing APIs from internal ones.
Needs ReviewPublic

Authored by sammccall on Oct 31 2018, 8:40 AM.

Details

Summary

This codifies the mostly-current state:

  • The stuff in ClangTidy.h is reasonable for checks to depend on.
  • The stuff in ClangTidyDiagnosticConsumer.h is a mish-mash of clang-tidy
  • checks are expected to treat ClangTidyContext as opaque

implementation details that checks shouldn't depend on (and most don't!)

But because there's no comments and the former currently #includes the latter,
this isn't clear and is violated in places:

  • exportReplacements is public but consumes ClangTidyError, a private API
  • Context exports all sorts of details publicly that checks shouldn't depend on, but checks must use Context->getOptions() in some cases

Event Timeline

sammccall created this revision.Oct 31 2018, 8:40 AM
sammccall updated this revision to Diff 171937.Oct 31 2018, 8:49 AM

Add FIXME to fuchsia check that uses private APIs.

JonasToth added a project: Restricted Project.
JonasToth added a subscriber: JonasToth.
steveire added inline comments.
clang-tidy/ClangTidy.h
11

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.

sammccall added inline comments.Oct 31 2018, 11:47 AM
clang-tidy/ClangTidy.h
11

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.

alexfh added inline comments.Oct 31 2018, 4:18 PM
clang-tidy/ClangTidy.h
11

I tend to agree with Stephen re: lack of stability guarantees of Clang APIs. Clang-tidy API on its own is not nearly enough to create a useful check, thus any out-of-tree check will use a significant amount of Clang APIs. Though the project aims at providing an easy way to maintain out-of-tree checks, there's little benefit in clang-tidy APIs being more stable than the API surface of Clang needed for an average out-of-tree check. Maintainers of any clang-based out-of-tree code should be ready to update their code with every change of the clang revision they use. Clang-tidy checks are not an exception. Putting this documentation here may send a very wrong message and serve badly both to the clang-tidy developers and to the folks who decide to depend on it.

A softer version of this (something along the lines of "A large number of out-of-tree checks depend on this API, so be careful when introducing potentially breaking changes.") may work here, but the same note will be needed on the whole AST, ASTMatchers, and Lex libraries in Clang (and many other ones, I guess).

sammccall updated this revision to Diff 172058.Oct 31 2018, 5:06 PM

Rethink comment about public API stability.

Fair enough.
I think it's worth saying *something* here, as the stability of these API has value and churning them has costs that far exceed (2 of magnitude?) the other C++ APIs in clang-tidy. And out-of-tree dependencies are something I usually want to be aware of when changing an API.

But softened it a lot and made it explicit no stability guarantee is being made.

steveire added inline comments.Nov 1 2018, 2:16 AM
clang-tidy/ClangTidy.h
11

I have a proposal coming up which involves a breaking change to AST_MATCHER* macros (many of which are out of tree), so I'm really just trying to make sure no backward compatibility concern opposes that.

I still see no point in the comment, if you don't also put the same comment in ASTMatchers.h, each header in AST/ etc. The files have the same out-of-tree use, and no one of them deserves a comment more than the others.

In fact, I had the idea just last week that I want to write a documentation page outlining compatibility guarantees in various user-facing parts of llvm/clang. It would be a single page containing the two sections about compatibility here: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility, C++ API stability, whether clang-query interpreter commands are stable, whether driver command lines and plumbing command lines are stable etc. AFAIK, that does not exist yet.

Regarding C++ API compatibility something along the lines here (http://clang-developers.42468.n3.nabble.com/getLocStart-versus-getStartLoc-tp4061010p4061292.html) and here (http://clang-developers.42468.n3.nabble.com/API-Removal-Notice-4-weeks-getStartLoc-getLocStart-getLocEnd-td4061566.html) . A note like yours would belong on such a page too. I don't think it belongs in this header.

lebedev.ri added inline comments.
clang-tidy/ClangTidy.h
11

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.

What do you mean by that, exactly?
Having PP callbacks in the clang-tidy checks is essential for many checks.