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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
