clang-tidy warnings and fixes are missing when relative paths are output

[dfarley1]

Environment

• OS and version: Gentoo
• VS Code: 1.68.1
• C/C++ extension: 1.11.0 pre-release
• OS and version of remote machine (if applicable): MacOS 12.4

Bug Summary and Steps to Reproduce

This might be related to #9091, I was having similar issues before?

With the following config:

        "C_Cpp.loggingLevel": "Debug",
        "C_Cpp.default.intelliSenseMode": "gcc-x64",
        "C_Cpp.default.compileCommands": "/depot/out/cur/compile_commands.json",
        "C_Cpp.default.compilerArgs": ["-Wall", "-Werror"],
        // clang-tidy
        "C_Cpp.codeAnalysis.clangTidy.enabled": true,
        "C_Cpp.codeAnalysis.clangTidy.useBuildPath": true,
        // showing header errors is really spammy
        "C_Cpp.codeAnalysis.clangTidy.headerFilter": "",
        "C_Cpp.codeAnalysis.clangTidy.args": [
            "-extra-arg=-Wno-unknown-warning-option",
        ],

I get an error: 'stddef.h' file not found [clang-diagnostic-error] from clang-tidy (removed our source code lines):

/home/extrahop/.vscode-server/extensions/ms-vscode.cpptools-1.11.0-linux-x64/bin/../LLVM/bin/clang-tidy
--header-filter=
-extra-arg=-Wno-unknown-warning-option
--export-fixes=/tmp/loose/cpptools/10565370979505651659/fixes140547972920896.yaml
--quiet
/depot/.../source.c
-p=/depot/out/cur/
  tag parsing file: /depot/.../source.c
cpptools/fileChanged: /depot/.../source.c
Error while processing /depot/.../source.c.
Unexpected output from clang-tidy:       FileOffset:      5653. Expected: doc != nullptr.
Unexpected output from clang-tidy:       FileOffset:      29691. Expected: doc != nullptr.
Unexpected output from clang-tidy:       FileOffset:      34964. Expected: doc != nullptr.
Unexpected output from clang-tidy:       FileOffset:      36527. Expected: doc != nullptr.
/depot/.../source.c:191:23: warning: narrowing conversion from 'uint32_t' (aka 'unsigned int') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]


/depot/.../source.c:1017:5: warning: switch has 2 consecutive identical branches [bugprone-branch-clone]


/depot/.../source.c:1032:6: note: last of these clones ends here


/depot/.../source.c:1152:44: warning: narrowing conversion from 'uint32_t' (aka 'unsigned int') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]


/depot/.../source.c:1202:49: warning: pointer parameter 'label_ids' can be pointer to const [readability-non-const-parameter]


/depot/.../source.c:1342:5: warning: if with identical then and else branches [bugprone-branch-clone]


/depot/.../source.c:1347:5: note: else branch starts here


/depot/.../source.c:1567:27: warning: narrowing conversion from 'unsigned long' to signed type 'int64_t' (aka 'long') is implementation-defined [cppcoreguidelines-narrowing-conversions]


/usr/include/bits/types/struct_iovec.h:23:10: error: 'stddef.h' file not found [clang-diagnostic-error]
#include <stddef.h>
         ^~~~~~~~~~
cpptools/getCodeActions: /depot/.../source.c (id: 25)
idle loop: reparsing the active document
Checking for syntax errors: /depot/.../source.c
Queueing IntelliSense update for files in translation unit of: /depot/.../source.c
cpptools/finishUpdateSquiggles
Error squiggle count: 0
Update IntelliSense time (sec): 0.273
cpptools/getSemanticTokens: /depot/.../source.c (id: 26)
cpptools/getFoldingRanges: /depot/.../source.c (id: 27)

The above repros when running the cpptools-provided clang-tidy in my terminal.

Using my system-provided clang-tidy doesn't have this error and provides more reports:

/depot/ $ clang-tidy --header-filter= -extra-arg=-Wno-unknown-warning-option --export-fixes=/tmp/loose/cpptools/10565370979505651659/fixes140547972920896.yaml --quiet /depot/.../source.c -p=/depot/out/cur/
161 warnings generated.
/depot/.../source.c:191:23: warning: narrowing conversion from 'uint32_t' (aka 'unsigned int') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]


/depot/.../source.c:584:27: warning: narrowing conversion from 'unsigned char' to signed type 'char' is implementation-defined [cppcoreguidelines-narrowing-conversions]


/depot/.../source.c:842:19: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]


/usr/include/sys/mman.h:44:21: note: expanded from macro 'MAP_FAILED'
#define MAP_FAILED      ((void *) -1)
                         ^
/depot/.../source.c:869:18: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]


/usr/include/sys/mman.h:44:21: note: expanded from macro 'MAP_FAILED'
#define MAP_FAILED      ((void *) -1)
                         ^
/depot/.../source.c:893:15: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]


/usr/include/sys/mman.h:44:21: note: expanded from macro 'MAP_FAILED'
#define MAP_FAILED      ((void *) -1)
                         ^
/depot/.../source.c:925:18: warning: integer to pointer cast pessimizes optimization opportunities [performance-no-int-to-ptr]


/usr/include/sys/mman.h:44:21: note: expanded from macro 'MAP_FAILED'
#define MAP_FAILED      ((void *) -1)
                         ^
/depot/.../source.c:1152:44: warning: narrowing conversion from 'uint32_t' (aka 'unsigned int') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]


/depot/.../source.c:1215:20: warning: narrowing conversion from 'uint32_t' (aka 'unsigned int') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]


/depot/.../source.c:1281:22: warning: narrowing conversion from 'uint32_t' (aka 'unsigned int') to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]


/depot/.../source.c:1567:27: warning: narrowing conversion from 'unsigned long' to signed type 'int64_t' (aka 'long') is implementation-defined [cppcoreguidelines-narrowing-conversions]


Error opening output file: No such file or directory

However, if I try to make cpptools use by system-provided clang-tidy instead:

        "C_Cpp.codeAnalysis.clangTidy.path": "/usr/lib/llvm/13/bin/clang-tidy"

I get no reports in VSCode. I see output matching my terminal in the "C/C++" Output tab, but those reports do not surface up to the Problems tab or highlights in the editor.

Here's the versions from both clang-tidys:

/depot/ $ /usr/lib/llvm/13/bin/clang-tidy --version
LLVM (http://llvm.org/):
  LLVM version 13.0.1
  Optimized build.
  Default target: x86_64-pc-linux-gnu
  Host CPU: skylake

/depot/ $ /home/extrahop/.vscode-server/extensions/ms-vscode.cpptools-1.11.0-linux-x64/bin/../LLVM/bin/clang-tidy --version
LLVM (http://llvm.org/):
  LLVM version 14.0.0
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: skylake

Other Extensions

No response

Additional Information

No response

[sean-mcmanus]

Yeah, setting "C_Cpp.codeAnalysis.clangTidy.path": "/usr/lib/llvm/13/bin/clang-tidy" may be required if useBuildPath is true, because our pre-built binary isn't able to locate one of the clang include paths that you have installed on your machine.

However, it sounds like you're hitting a bug with no Problems being shown. Do you see "Unexpected output from clang-tidy: FileOffset: 5653. Expected: doc != nullptr." in your output logging still? Either way, that unexpected output is an indication of some bug. I'll investigate...

[dfarley1]

Yeah, setting "C_Cpp.codeAnalysis.clangTidy.path": "/usr/lib/llvm/13/bin/clang-tidy" may be required if useBuildPath is true, because our pre-built binary isn't able to locate one of the clang include paths that you have installed on your machine.

Works for me, sadness that it's needed but 🤷

However, it sounds like you're hitting a bug with no Problems being shown. Do you see "Unexpected output from clang-tidy: FileOffset: 5653. Expected: doc != nullptr." in your output logging still? Either way, that unexpected output is an indication of some bug. I'll investigate...

Huh... this bug seems to be dependent on the file I'm looking at.
The file I was originally investigating DOES NOT have the "unexpected output" lines and errors DO NOT show up in the UI.
Another file I just tried DOES have the "unexpected output" lines and its errors DO show up in the UI.
Very confusing...

[sean-mcmanus]

The "unexpected output" is from code we added for clang-tidy fix processing, so it would not affect the actual warning but any potential fix that would be available would not be available, so that is why you do see the warnings in the UI (with fixes potentially missing that shouldn't be). There might be a 2nd bug causing the warnings to not appear in certain cases -- we have a known repro of this on our build machines that we're currently investigating, which could share the same root cause.

The "doc != nullptr" means there was a problem getting the VS Code document object that corresponds to the file output in the clang-tidy --export-fixes yaml file, possibly due to an unexpected URI format. It looks like we don't log the file path format in our non-debug builds, but I could add that logging.

Do you know where the "..." is coming from -- is that what is actually being shown or is that an edit from you?

[dfarley1]

Do you know where the "..." is coming from -- is that what is actually being shown or is that an edit from you?

The ... is me, sorry about that. Some are relative to our build output dir (../../foo/bar/source.c) and some are absolute (/depot/foo/bar/source.c), but they all look sane to me.

The odd thing to me (and this happens in the terminal too) is that clang-tidy will mix and match relative and absolute paths on a per-warning basis; i.e. a single report will show both relative and absolute paths to the same file.

[dfarley1]

I just updated VSCode and extensions (so now on v1.69.0 and v1.11.2 respectively) and now I'm getting even weirder behavior. On the file I originally reported, I'm not seeing any warnings show up in the UI, nor am I seeing any parsing errors.

However, on the second file I tried, only 1 out of ~30 reports show up in the UI! Here's the debug output, but only the bugprone-sizeof-expression one shows up.

../../path/to/source.c:5769:15: warning: narrowing conversion from 'unsigned long' to signed type 'int' is implementation-defined [cppcoreguidelines-narrowing-conversions]


../../path/to/source.c:5812:22: warning: suspicious usage of 'sizeof(A*)'; pointer to aggregate [bugprone-sizeof-expression]


/depot/path/to/lib.h:81:39: note: expanded from macro 'ARRAY_SIZE'
#define ARRAY_SIZE(a)   (sizeof(a) / (sizeof((a)[0])))
                                      ^
../../path/to/source.c:6269:23: warning: 'signed char' to 'int' conversion; consider casting to 'unsigned char' first. [bugprone-signed-char-misuse]

The report that shows up is the only one that contains an absolute path (to lib.h), so I manually fudged my compile_commands.json to use absolute paths instead of relative ones and now all the reports show up! So it seems like your clang-tidy processing doesn't like the relative paths (we use GN as a build tool fwiw).

Here's the original entry for the above file in my compile_commands.json (with -I and -iquote stripped out):

  {
    "file": "../../path/to/source.c",
    "directory": "/depot/out/Default",
    "command": "gcc -MMD -MF  obj/path/to/source.o.d  -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2  -I...  -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -Wno-format-truncation -Wno-stringop-truncation -Werror -O3 -g2 -fstack-protector-strong -iquote ... -fPIC -fno-common  -c ../../path/to/source.c -o  obj/path/to/source.o"
  },

If you're interested, I can share all my unedited output with you privately, but I tried to preserve the original syntax a bit better here.

[dfarley1]

I confirmed with another file that had mixed relative and absolute paths that only the reports with absolute paths show up in the UI:

../../path/to/source.cc:24:8: warning: do not declare C-style arrays, use std::array<> instead [cppcoreguidelines-avoid-c-arrays,modernize-avoid-c-arrays]


/depot/out/Default/../../path/to/source.cc:50:8: warning: constructor does not initialize these fields: label_id [cppcoreguidelines-pro-type-member-init]

In the above case only the latter report showed up. No idea how/why clang-tidy decides to use different syntax in the same output though?

[sean-mcmanus]

I got a repro of the issue (via creating a compile_commands.json with a relative path and useBuildPath set to true) -- both the "doc != nullptr" and the relative file path in the output leading to missing diagnostics.

[sean-mcmanus]

I've filed #9574 to track the stddef.h not found issue.

[sean-mcmanus]

Fixed with 1.11.3 (pre-release): https://github.com/microsoft/vscode-cpptools/releases/tag/v1.11.3

...well, it's fixed for the repro cases we tested on -- let us know if you're still seeing any bugs related to the relative paths.