Open daantimmer opened 1 year ago
@llvm/issue-subscribers-clang-tidy
Moving the flag from the command line to the config likely wouldn't have any effect on clangd as it doesn't handle the options file the same way tidy does natively.
Can I also understand the motivation for this support. hard coding the lines seems like a strange request. The reason for that option at all is so that you can apply clang-tidy just on the diff of the file, I'm not sure I see the use case for it outside of that
Can I also understand the motivation for this support. hard coding the lines seems like a strange request. The reason for that option at all is so that you can apply clang-tidy just on the diff of the file, I'm not sure I see the use case for it outside of that
Sure! --line-filter is the only way, it seems, to fully ignore googletest//googlemock macro usage warnings. TEST_F
is throwing, with my current clang-tidy config, two warnings. That I can only ignore by either // NOLINT
at the end of the line. Which is too much visual noise and just plain annoying. Or by specifying --line-filter=gtest.h (not exactly, forgot the way it is supposed to be written, not at my work PC right now).
Modifying the source of gtest to either ignore or fix the warnings is a no go. Google(test) repo has been declining any and all sorts of pull requests related to fixing or ignoring warnings from 'third party analyzers'. :-(
@daantimmer you can try include GTest headers as system include (-isystem
). It would probably help you
@KindDragon how do you expect that to work? I am using FetchContent from cmake. And it is then up to googletests cmake project to mark those headers as system headers. From my cmakelists I can't really do that...
@daantimmer I use sed to patch compile_commands.json after generation
cat compile_commands.json |
sed 's# -I../../../thirdparty/googletest/googletest# -isystem../../../thirdparty/googletest/googletest#g' \
>compile_commands.json.tmp
mv compile_commands.json.tmp compile_commands.json
@KindDragon oof, that sounds like a terrible, non-portable and definitely an unworkable workaround if you ask me.
Not something you can easily deploy to other team members of other projects.
It is, however, a genius solution. (But I won't use it)
You can change your CMake script that adds GTest include dir, but it is of course up to you.
@KindDragon CMake has the INTERFACE_SYSTEM_INCLUDE_DIRECTORIES property, which you can manually set using set_target_properties
. CMake will then use -isystem
in the compiler invocation.
@ts826848 thanks, but we use GN Build
@KindDragon Ah, sorry, pinged the wrong person. My apologies for the mistake!
Currently
clang-tidy
supports the--line-filter
option via the command line. However, when clang-tidy is ran from, say,clangd
, then it is not possible to provide any command line options forclang-tidy
. One of these (important) parameters is the--line-filter
option.I would like to request the
--line-filter
option to also be available as a.clang-tidy
file configuration option. Which results inclangd
's usage ofclang-tidy
to respect the.clang-tidy
file and thus the--line-filter
option.