[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"
Dmitri Gribenko via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Sep 5 13:23:13 PDT 2019
gribozavr added a comment.
In D67140#1659356 <https://reviews.llvm.org/D67140#1659356>, @aaron.ballman wrote:
> In D67140#1658969 <https://reviews.llvm.org/D67140#1658969>, @gribozavr wrote:
>
> > In D67140#1658365 <https://reviews.llvm.org/D67140#1658365>, @aaron.ballman wrote:
> >
> > > Ah, good to know! That reduces my concern, but doesn't negate it. AFAIK, we haven't changed the interface such that it requires code changes rather than just a recompile in recent history, so this is a bit novel.
> >
> >
> > I think API changes happen all the time. At Google, we are integrating upstream LLVM and Clang changes into our internal codebase daily. We have a lot of internal ClangTidy checkers. Fixing up all our internal code to keep with upstream changes is a full time job for one engineer (but it is a rotation).
>
>
> I think this sort of backs up the point I was making.
Sorry, but in the previous comment you were saying that "we haven't changed the interface such that it requires code changes". So which is it, for you?
> It requires an FTE to keep up with the breaks already.
Exactly. So one more or one less API change that requires a trivial code change *does not matter*. People working on the Clang upgrade still have a ton of other, complex, changes to deal with. Is it more work to upgrade for this sort of API rename? Yes. Is meaningfully more work, if you look at everything that needs to be done as a whole? No. It will not be a thing that makes or breaks someone's Clang upgrade.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D67140/new/
https://reviews.llvm.org/D67140
More information about the cfe-commits
mailing list