Warnings such as `variable 'as' is not initialized [cppcoreguidelines-init-variables]GCC` not cleared on fixing it and saving the file

[thernstig]

Brief Issue Summary

This is a quite serious bug, as it completely hampers working with this tool when having errors and clearing them.

If you have common errors and then save a file, the errors do not get away on save. They stay. See here:

See also this capture. I am saving the file in between changes done in this video, before I hover the error:

https://github.com/user-attachments/assets/fe3c58ff-1bc0-4814-8ef3-90fb97f22f8d

I have no idea why this tool even shows errors like this, I initially wrote a bug report here https://github.com/microsoft/vscode-cpptools/issues/12716 thinking it was the C/C++ extension from Microsoft that had this problem, since it has built-in support for clang-tidy. But for some reason this CMake extension decides to also show errors. And those errors are not removed on save.

This issue is thus about that the errors are not cleared when you fix them and save the file.

Also, is there a way to completely disable them in settings? I already have the C/C++ to show these errors.

CMake Tools Diagnostics

{
  "os": "linux",
  "vscodeVersion": "1.93.0",
  "cmtVersion": "1.19.51",
  "configurations": [
    {
      "folder": "/home/tobias/code/c-test",
      "cmakeVersion": "3.30.2",
      "configured": true,
      "generator": "Unix Makefiles",
      "usesPresets": true,
      "compilers": {
        "C": "/usr/bin/gcc"
      }
    }
  ],
  "cpptoolsIntegration": {
    "isReady": true,
    "hasCodeModel": true,
    "activeBuildType": "Debug",
    "buildTypesSeen": [
      "Debug"
    ],
    "requests": [
      "file:///home/tobias/code/c-test/src/main.c"
    ],
    "responses": [
      {
        "uri": "file:///home/tobias/code/c-test/src/main.c",
        "configuration": {
          "includePath": [],
          "defines": [],
          "compilerPath": "/usr/bin/gcc",
          "compilerArgs": [],
          "compilerFragments": [
            "-g -std=gnu90"
          ]
        }
      }
    ],
    "partialMatches": [],
    "targetCount": 1,
    "executablesCount": 1,
    "librariesCount": 0,
    "targets": [
      {
        "name": "helloworld",
        "type": "EXECUTABLE"
      }
    ]
  },
  "settings": [
    {
      "communicationMode": "automatic",
      "useCMakePresets": "auto",
      "configureOnOpen": true
    }
  ]
}

Debug Log

There is no output at all when just saving a file.

Additional Information

No response

[gcampbell-msft]

@sean-mcmanus From what I can tell, these are coming from the C/C++ extension, can you confirm? And if so, I'll transfer the issue

[sean-mcmanus]

@gcampbell-msft This was already reported for the C/C++ extension at https://github.com/microsoft/vscode-cpptools/issues/12716 . The errors labeled with C/C++ on the right are from our extension (so I think those are our issues), but the GCC ones are from another, maybe CMake Tools or from CMake -- the CMakeLists.txt might have some clang-tidy on build feature enabled.

[gcampbell-msft]

I believe I see that we're populating this. @thernstig There are two things that I believe you could do: 1) Rebuild your project to get our extension to re-assess the diagnostics. 2) If you don't want our extension to provide these, you can disable the cmake.parseBuildDiagnostics setting

[thernstig]

@gcampbell-msft you are correct, the errors go away on rebuild. I understand the rationale behind this.

I have set set(CMAKE_C_CLANG_TIDY clang-tidy) set in CMakeLists.txt.

There are two things that makes this hard UX-wise for users when we see the error:

variable name 'a' is too short, expected at least 3 characters [readability-identifier-length] GCC

1. There is no indication which extension gives this error. I believe you should rename the GCC part to something like CMake Tools or even better, if you can deduct this somehow from CMakeLists.txt that it is clang-tidy that gives this error: CMake Tools - clang-tidy:
2. I think you should clear any build errors on file save or when starting to edit. At least the squigglies and maybe just keep them in the Problems pane. But with a clear indication it came from the CMake Build step (and preferably also clang tidy). The rationale behind this is what we see after we edit and save, the squigglies are not valid anymore and end up over code that it has no relation to.

Are these feasible and make sense?

[bobbrow]

I think you should clear any build errors on file save or when starting to edit. At least the squigglies and maybe just keep them in the Problems pane. But with a clear indication it came from the CMake Build step (and preferably also clang tidy). The rationale behind this is what we see after we edit and save, the squigglies are not valid anymore and end up over code that it has no relation to.

I don't agree with this suggestion. Build errors should persist until the next build. Visual Studio behaves the same way. When I work through a list of build problems (e.g. when I'm refactoring code), I don't want the ones I haven't fixed yet to suddenly disappear because I fixed other ones in the file. That would require me to rebuild and that can take time. And I don't think CMake Tools should automatically rebuild the file on edit/save.

And I don't know of a way to make an error show in the Problems pane without also drawing a squiggle. In VS Code, extensions just report the Problems and VS Code handles the rest.

[bobbrow]

What CMake Tools could potentially do is add a code action for the build errors that allow you to dismiss them one by one.

[thernstig]

@bobbrow I am not sure being able to dismiss them one-by-one is something I would personally use, maybe others would.

How would one solve the problem with that the yellow squigglies end up in the wrong place when doing any edits to the file? Are there any other ideas, or are we saying we have to live with this incorrect-placement-of-yellow-squigglies-on-further-edits?

I cannot come up with a good idea myself.

aside: Should I write a separate issue about the variable name 'a' is too short, expected at least 3 characters [readability-identifier-length] GCC output not being clear maybe?

[v-frankwang]

@gcampbell-msft Users want to know if we have a better solution to the problem of the yellow wavy line appearing in the wrong place, and if we need to create a new issue about unclear output.