AaronBallman wrote: > > It feels like instead nlohmann/json should be the one responsible for > > providing a "migration path" / tooling for these types of deprecated > > features.
+1 > > Thus I would vote for keeping clang-tidy as a general tool for C++/STL only. > > N.B. we already have `abseil-`, `boost-`, `cppcoreguidelines-`, `fuschia-`, > `linuxkernel-`, and `zircon-`. `boost` is a well-known third-party library that's often a staging area for STL features; I think they fit in with the STL rather closely. `abseil`, `cppcoreguidelines`, `cert` are well-known coding standards, which is clang-tidy's niche. `fuschia` and `zircon` were strongly tied to the LLVM community through Google, but I don't know that I would support adding them if they were proposed today. `linuxkernel` is another one I don't know that I'd support; it's not that it's a niche project, but more that I don't understand what the value is to the general user base. I think the Linux kernel community could maintain this module (as plugins, even) given that they're the primary beneficiary. That said, I don't think we've ever had a *policy* about this sort of thing. If we have a consensus opinion forming, we should probably write an RFC and propose some docs to see if the rest of the community buys into it. https://github.com/llvm/llvm-project/pull/126425 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
