[llvm-dev] RFC tidy-llvm.py

[Christian Kühnel via llvm-dev]

Hi Chris,

Thx for looking into this. The use case I was thinking about for a while
was:
Can we add clang-tidy to the linters run during arc diff to check my
modifications, so similar to clang-format?

A couple of thoughts around that.

   - Only trigger this linter if the user enabled it (at least until we
   know it works well). So we would need some mechanism to enable/disable this
   per user.
   - Ensure we have a compile_commands.json and the include files were
   generated. I suppose this is what your script takes care of.
   - Check only the modified files (everything else would be too slow) and
   filter the findings to your modified lines only. This is covered by
   clang-tidy-diff.py
   - I don't know if we want to offer to apply fix-its at this point. They
   might be too noisy.

What do you think?

Best,
Christian


On Thu, Dec 16, 2021 at 7:46 AM Chris Sears via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Using clang-tidy on LLVM itself (the proverbial eating your own dogfood)
> is a little different from using a clang-tidy installation on another
> source tree. clang-tidy needs to know where to find include files within
> the LLVM source tree itself.
>
> This is a Python script, tidy-llvm, which finds the root of the llvm tree,
> verifies LLVM build requirements
> (LLVM_ENABLE_PROJECTS:STRING=clang;clang-tools-extra and
> CMAKE_EXPORT_COMPILE_COMMANDS:UNINITIALIZED=On), constructs llvm and
> current directory include paths, concatenates up an argument list and then
> runs clang-tidy on the .h and .cpp files on the command line.
>
> tidy-llvm XXAsmPrinter.cpp generates a clang-tidy command line that looks
> like:
>
>   clang-tidy -checks="llvm-*" -p .../build XXAsmPrinter.cpp -- -I.
>     -IAsmParser -IGISel -IDisassembler -ITargetInfo -IXX -IMCTargetDesc
>     -I.../libcxx/include -I.../build/include -I.../llvm/include
>
> I'm pretty sure that the llvm include directories (-I.../libcxx/include
> -I.../build/include -I.../llvm/include others?) have to be enumerated
> rather than simply inheriting where clang-tidy thinks they are in the
> installation. Unless I manually specified them, clang-tidy wasn't finding
> them.
>
> I think someone more expert in the build machinery could improve it
> greatly. For example, it currently gets a strange error about __config_site
> (which doesn't prevent the rest of the clang-tidy checking):
>
>   Error while processing path to XXAsmPrinter.cpp.
>   path/libcxx/include/__config:13:10: error: '__config_site' file not
> found [clang-diagnostic-error]
>   #include <__config_site>
>
> __config_site is indeed not in my build tree. There is a file
> libcxx/include/__config_site.in but that's it. Again, someone more
> knowledgable in the build machinery might understand why this is the case.
>
> clang-tidy still interprets its .clang_tidy file wherever it finds it.
> It's better to leave most of the -checks there. The tidy-llvm Python script
> itself is currently set to -checks=\"llvm-*\". I set modernize in the
> .clang_tidy file for my backend. I can imagine having a .clang-tidy file at
> the root of the llvm tree.
>
> Adding support for run-clang-tidy would be nice but for tidying individual
> files it really won't matter.
>
> https://reviews.llvm.org/D115848
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211216/9e30a7d9/attachment.html>