vbvictor wrote: > I dont't think this is a substantive change in the scope of LLVM. It's very > much in line with previous work on "include-system-headers"
You can create RFC on `clang-tidy` topic, previous work on `system-header` had RFC: https://discourse.llvm.org/t/rfc-exclude-issues-from-system-headers-as-early-as-posible/68483. I think main question we should answer and agree among maintainers is: "Do we wish to trade correctness of some checks for speed". I'm currently against this statement even with "dangerous" option because: 1) I think we don't want to give users a way to break checks even if it's called "dangerous", "use-with-caution", "DONT" because eventually we will have to deal with "FP/FN" that this option creates. But this is only my opinion, in RFC majority can vote in favor of option and we can merge it. ----------------- > The practical usage for our large monorepo for example is that we have a few > hundreds of custom checks which just take too long to run by leveraging this > flag can drop a 10-20 of them but shift left the others and let users of the > codebase run clangtidy in scenarios they wouldn't run it. So we will parity > check every checker and pick the ones compatible with the flag for the > purpose getting speed. I can see how you wish to use that internally, but who will pick "compatible" check in upstream clang-tidy. Does this mean that every clang-tidy user who wants to use this option have to find "compatible" checkers by hand? Or tidy maintainers would have to update this list? If this need to be done by maintainers (which I personally don't want to take responsibility of), what would the flow be (do we need to deduce this from checkers code or writing tests)? https://github.com/llvm/llvm-project/pull/194370 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
