clang-tidy ignoring compilation database compiler options when single check specified.

[IanCollins]

I have a strange issue with clang-tidy. For one specific file, running with our default .clang-tidy picks up two warnings, one of which is performance-for-range-copy. If I re-run with the following command, a bunch of clang-diagnostic-format-security errors are flagged:

clang-tidy-21 --header-filter='-*' --checks='-*,performance-for-range-copy' -p=<path to compile commands directory> <target file>

The compile_commands.json entry for the files does include -no-format-security!

Is there a way to see the commands passed to clang under the hood?

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Ian Collins (IanCollins)

I have a strange issue with clang-tidy. For one specific file, running with our default .clang-tidy picks up two warnings, one of which is `performance-for-range-copy`. If I re-run with the following command, a bunch of `clang-diagnostic-format-security` errors are flagged:

clang-tidy-21 --header-filter='-*' --checks='-*,performance-for-range-copy' -p=<path to compile commands directory> <target file>

The compile_commands.json entry for the files does include -no-format-security!

Is there a way to see the commands passed to clang under the hood?

[IanCollins]

Testing more, it appears to be any source file that triggers clang-diagnostic-format-security. This is the only clang compiler warning found.

[zeyi2]

Is there a way to see the commands passed to clang under the hood?

Hi, I think you can try adding -extra-arg=-v. This can make clang-tidy to emit more verbose output.

I'm still trying to reproduce the issue you encountered. If you're able to provide a small reproducer or sample file setup, that would be extremely helpful for debugging.

[vbvictor]

Could you provide a full example of compile database? for warning to be disabled in clang it needs -Wno-format-security irrc

[IanCollins]

Could you provide a full example of compile database? for warning to be disabled in clang it needs -Wno-format-security irrc

-Wno-format-security is there (otherwise the run without the specified check would also fail).
I would have to build a specific test case, our project is rather large!

[IanCollins]

-extra-arg=-

was very illuminating. In both cases I see the same compiler warning flags:
"-Wno-missing-exception-spec" "-Wno-unused-command-line-argument" "-Wall" "-Werror" "-Wno-strict-aliasing" "-Wno-missing-braces" "-Wno-switch" "-Wno-format-security" "-Wno-reorder" "-Wno-unknown-warning-option" "-Wno-unknown-pragmas" "-Wno-expansion-to-defined" "-Wno-unused-but-set-variable" "-Wnarrowing" "-Wmismatched-tags" "-Warray-bounds-pointer-arithmetic" "-Wduplicate-method-match" "-Wmove" "-Wunused" "-Wuninitialized" "-Wunneeded-member-function" "-Wdeprecated-copy" "-Wformat" "-Wmissing-field-initializers" "-Werror" "-Werror" "-std=c++17" "-fdeprecated-macro" "-ferror-limit" "19" "-fgnuc-version=4.2.1" "-fskip-odr-check-in-gmf" "-fcxx-exceptions" "-fexceptions" "-fno-diagnostics-fixit-info" "-vectorize-loops" "-vectorize-slp" "-fshow-overloads=best" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-x"

I will try removing -Wformat.

[IanCollins]

As expected, removing the -Wformat fixed it, but why the behaviour was different with and without the specified check remains a mystery. I will dig further tomorrow.

[zeyi2]

Hi, I think I reproduced this weird issue. I suspect it may have something to do with -Werror.

In your arguments: .. -Wno-format-security .. -Wformat .. -Werror

The -Wformat flags after -Wno-format-security re-enables the security warnings[1]. Since -Werror is present, the warning got promoted as an error. When compiler driver reports the error, clang-tidy reports this as a failure and falls under the clang-diagnostic-*.

So removing -Wformat as you did is indeed a correct fix, you may also try fixing the order of arguments to verify this.

---

[1] You can verify this behaviour by;

// flag_test.cpp
#include <stdio.h>

void func(char *s) {
  printf(s); // This triggers -Wformat-security
}

$ clang++ -c -Wno-format-security -Wformat flag_test.cpp
flag_test.cpp:4:10: warning: format string is not a string literal (potentially insecure) [-Wformat-security]
    4 |   printf(s); // This triggers -Wformat-security
      |          ^
flag_test.cpp:4:10: note: treat the string as an argument to avoid this
    4 |   printf(s); // This triggers -Wformat-security
      |          ^
      |          "%s", 
1 warning generated.
$ clang++ -c -Wformat -Wno-format-security flag_test.cpp

[IanCollins]

@zeyi2 thanks for digging. The bizarre thing is that the compiler flags are in the same order for builds, and the warning is never triggered!

I also see those extra -Werror flags in the tidy output that aren't in the compile_commands.json. The supplied compiler flags are:
-Wall -Werror -Wno-strict-aliasing -Wno-missing-braces -Wno-switch -Wno-format-security -Wno-reorder -Wno-unknown-warning-option -Wno-unknown-pragmas -Wno-expansion-to-defined -Wno-unused-but-set-variable -Wnarrowing -Wmismatched-tags -Warray-bounds-pointer-arithmetic -Wduplicate-method-match -Wmove -Wunused -Wuninitialized -Wunneeded-member-function -Wdeprecated-copy -Wformat -Wmissing-field-initializers

[zeyi2]

Hi, sorry for the late reply.

extra -Werror flags in the tidy output that aren't in the compile_commands.json

I think this is likely due to the build system (e.g. CMake) appending flags from multiple sources. Clang-Tidy's verbose output simply reflects the full list of arguments passed to the driver, so this is expected.

the compiler flags are in the same order for builds, and the warning is never triggered

Could you share which compiler are you using (e.g. which version of clang/gcc) for the actual build? AFAIK gcc and clang handle -Wno-format-security in a different way so that may be a possible reason.