[clang-tools-extra] [clang-tidy] support query based custom check (PR #131804)
olologin wrote: I like it if it does not break anything :) One small nitpick: Maybe word "custom" is too broad for this. Maybe something that mentions "clang-query" is more specific. But it is just my opinion and I am not related to clang-tidy, so whatever you guys decide. 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
[clang-tools-extra] [clang-tidy] support query based custom check (PR #131804)
olologin wrote: Splitting config to multiple files is potentially bad because caching wrappers need to be adjusted to take into account this new type of input file (they only know about .clang-tidy file). 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
[clang-tools-extra] [clang-tidy] support query based custom check (PR #131804)
olologin wrote: @carlosgalvezp Hi, I tried to explain everything here: https://github.com/llvm/llvm-project/issues/107680 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
[clang-tools-extra] [clang-tidy] support query based custom check (PR #131804)
olologin wrote: >it sounds like the goal is somewhat less about clang-tidy checks and more >about running code transformations more easily. Original goal was to have just clang-tidy checks. We use it on our CI to guard main branch from people accidentally merging prohibited stuff. If CI informs devs their PR is bad - they are smart enough to follow the guidelines and fix their problem themselves without relying on automatic transformers. Or to use "NOLINT" as a way to override checks. Extending this functionality with transformers is optional and can be done later, if someone is willing. 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. 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". 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
[clang-tools-extra] [clang-tidy] support query based custom check (PR #131804)
olologin wrote: > It would feel safer if the custom check was passed via command-line instead, > similar to --config But then you will not be able to properly disable such checks for subfolders (modules) of some huge project, right? 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
[clang-tools-extra] [clang-tidy] Add ClangQueryChecks config option (PR #123734)
olologin wrote: Just FYI: I have tested @DeNiCoN on our codebase in the company we work with him together (~8k Translation units), and it seems to work fine. `NOLINT(check-name)` works, .clang-tidy config inheritance works (In case some subfolders want to disable particular matchers). Very useful feature, I hope it gets into clang-tidy at some point. At the moment we use backported patch for clang-tidy-16 https://github.com/llvm/llvm-project/pull/123734 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
