AaronBallman wrote: > Extending this functionality with transformers is optional and can be done > later in another PR, if someone is willing.
Yes and no. If the goal is just to write checks, then clang-tidy is a good home for the functionality. But I had the impression that for some people this is also about code migrations, where clang-tidy may be a less appropriate home and a dedicated tool is a potentially better approach. We don't want to walk down the path of adding it to clang-tidy only to add similar-but-extended functionality in another tool as that increases our maintenance burdens and users have to work harder to figure out which tool to reach for or migrate between. (This isn't to say clang-tidy isn't still a reasonable home for this. Just bringing it up so other maintainers are thinking about the long-term picture of where we want to be.) > Also, just my opinion: I cannot force people into merging this PR, but if it > does not break anything and if nobody has significant concerns - I don't see > any reason in slowing it down and postponing the merge, because the feature > is already implemented and the time is spent. That's only part of the decision. Once we accept a feature, we have to support it basically forever. So there are long-term maintenance costs, and each feature we add increases the expense of adding new features later due to the complexity of interactions between them. It's not a simple matter of "someone already wrote it", it's also "we need to review it, we need to maintain it forever, what else do we lose if we take it, etc." > This feature will obviously find its users. You can see a lot of public repos > (last time I saw it in Firefox) extending clang-tidy with their simple custom > checks, some of them are on the level of "Let's not allow people to use > LoadLibraryEx directly). Also, it is a bit unclear when RFC is considered "popular enough". Don't get me wrong, I understand you don't want to merge every shiny PR people find cool, but I don't want this PR to be stuck for 1 year and then no one will want to rebase it. We're in the process of improving our governance to make it more clear what next steps there are for RFCs which aren't reaching obvious consensus. There's no hard rule for "popular enough" (and clang-tools-extra extensions are a bit different from clang ones in terms of how much the community is likely to weigh in), but we do expect the RFC to run for a reasonable period of time so people have the opportunity to express their support or concerns. https://github.com/llvm/llvm-project/pull/131804 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
