llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
27.92k stars 11.53k forks source link

missing build path in some clang-tidy-11 warnings #55024

Open pjaitken opened 2 years ago

pjaitken commented 2 years ago

Running clang-tidy-11 with "-p", some issues are prefixed with the "-p" path while others are not. eg:

$ clang-tidy-11 -header-filter=^((?!\.pb).)*\.h$ -checks=-readability-magic-numbers,-readability-isolate-declaration,-bugprone-reserved-identifier -p=/usr/src/packages/BUILD/builddir -quiet /usr/src/packages/BUILD/src/debug.c
../src/debug.c:151:11: warning: narrowing conversion from 'unsigned int' to signed type 'int' is implementation-defined [bugprone-narrowing-conversions]
                        return i;
                               ^
/usr/src/packages/BUILD/builddir/../src/debug.c:172:16: warning: integer literal has suffix 'ul', which is not uppercase [readability-uppercase-literal-suffix]
                dp_debug |= (1ul << i);
                             ^~~
                              UL

Notice that the first issue is reported against "../src/debug.c" (without the -p path) while the second is against "/usr/src/packages/BUILD/builddir/../src/debug.c" (which includes the -p path).

The -p path is included nearly 90% of the time.

As can be seen above, the path may or may not be included for analysis of any one file, and across multiple files it may or may not be included for a particular check type.

This is a problem when clang is run from a Jenkinsfile, where "recordIssues" parses the clang-tidy.log and reports "file not found" for each issue. clang-tidy.log has to be post-processed (with "sed") to normalise all the issues before parsing by recordIssues.

EugeneZelenko commented 2 years ago

What is behavior of 14 and main?

llvmbot commented 2 years ago

@llvm/issue-subscribers-clang-tidy