Diagnostic messages are getting ignored due to relative filepath check

[theswordsmahin]

The if statement here:

vscode-clang-tidy/src/tidy.ts

Line 239 in dc19ba9

if (

Is causing diagnostic messages to be ignored due to the fact that the FilePath output is only a filename.

Command being run /usr/local/clang/bin/clang-tidy /code/srv/sd/sdbuf.c ...
The diagnostic messages being reported are:

- DiagnosticName:  clang-diagnostic-incompatible-pointer-types-discards-qualifiers
    DiagnosticMessage:
      Message:         'passing ''volatile uchar *'' (aka ''volatile unsigned char *'') to parameter of type ''void *'' discards qualifiers'
      FilePath:        sdbuf.c
      FileOffset:      62732
      Replacements:    []

This then fails that check, and causes all messages to be ignored.

[notskm]

On my machine, clang-tidy only reports absolute filepaths, both on Windows and Linux.

What version of clang-tidy are you using? Can you describe the file layout of your project? What do your settings look like?

[theswordsmahin]

What version of clang-tidy are you using?

$ clang-tidy -version
LLVM (http://llvm.org/):
  LLVM version 11.0.0git
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

Can you describe the file layout of your project?
We have a large C project, compiled using gcc in a Makefile. We're getting everything working in VSCode with the clang toolset, for better intellisense and syntax highlighting than microsoft c/c++ extension, but it has taken some work. We are generating a compile_commands.json file which appears to appease the clangd plugin:

{
"directory": "/code/srv/sd",
"file": "/code/srv/sd/sdbuf.c",
"command": "/usr/local/gcc/bin/gcc -c -D_REENTRANT -D__linux -DTSMSRV -Wall -Wno-enum-conversion -Wno-parentheses -ferror-limit=0 -fno-strict-aliasing -Wno-pointer-sign -funsigned-char -Werror -Wextra -Wno-sign-compare -Wno-unused-parameter -D_RHEL_ -DEXT2FS_EXT2FS -O2 -g -fpic -fno-omit-frame-pointer <include_directories> sdbuf.c -o../sd/linux64/x86_64/server/sdbuf.o"
},

I have tried versions of this file with both the absolute filepath for the file, as well as just the file name. The DiagnosticMessage output is the same.

What do your settings look like?

    "clang-tidy.executable": "/usr/local/clang/bin/clang-tidy",
    "clang-tidy.checks": [
        "-clang-diagnostic-pointer-sign",
        "-clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling",
        "-clang-diagnostic-dangling-else",
        "-clang-diagnostic-tautological-pointer-compare",
        "-clang-analyzer-security.insecureAPI.strcpy"
    ],
    "clang-tidy.compilerArgs": [
        "-DCLANG_ANALYZE"
    ],

Also, for what its worth, the absolute filepath is listed above:

MainSourceFile:  '/code/srv/sd/sdbuf.c'
Diagnostics:
  - DiagnosticName:  clang-diagnostic-incompatible-pointer-types-discards-qualifiers
    DiagnosticMessage:
      Message:         'passing ''volatile uchar *'' (aka ''volatile unsigned char *'') to parameter of type ''void *'' discards qualifiers'
      FilePath:        sdbuf.c
      FileOffset:      62732
      Replacements:    []

Hope that is enough information, thanks for looking into it!

[notskm]

The only weird thing that stands out is that you're on clang-tidy 11.0.0, which hasn't been released. Can you try out clang-tidy 10.0.0 and let me know if you have the same problem? I'd compile the master branch myself, but LLVM takes forever to compile on my machine.

I see '/code/srv/sd/sdbuf.c'. What folder do you have VSCode open in? In other words, what folder is acting as the root of the project?

[theswordsmahin]

Ah I did not realize version 11 had not been officially released yet. We are doing a lot of work in centos 7 docker containers for which there does not appear to be pre-compiled binaries available so we compiled the latest once (which did indeed take a long time) and use that to build our subsequent images. Rebuilding it with an older version would take a fair bit of time for us as well, but if I have a chance to verify that it works in version 10 for us I will let you know.

It does seem likely this was caused by using version 11, in which case I wouldn't think there'd be any urgency for you to devote much time to this (unless it really bothers you) as the majority of people probably wont be encountering it, and I currently have worked around the issue by disabling the offending code block in tidy.js when our devcontainer starts up which appears to be working for our purposes.

I see '/code/srv/sd/sdbuf.c'. What folder do you have VSCode open in? In other words, what folder is acting as the root of the project?

/code is the root directory of the project

Thanks again