Question on behaviors of cmake build outputs in PROBLEMS panel

[wkjung]

When I configure and build (through >CMake: Build), I got behaviors that I don't understand.

With this simple example (main.cpp)

class bar{};
void foo(bar&&) {}

int main(int, char**) {
    bar x;
    foo(x); // non-const lval to rval -> error
}

I got the problems pane as below:

cmake: 3.23
cmake tools: 1.10.5
vscode: 1.67.1
os: m1 macos
compiler: Apple clang 13.1.6

Questions:

• Why the error outputs even tho I set "cmake.parseBuildDiagnostics": false in settings.json? Is it a bug?
• Is it possible to make the error and its corresponding squiggle follow the current file after modification? I mean, I would expect not to see the error after removing the problematic line foo(x), but the current implementation seems to hold all the problems (so it points to a wrong line after removing the line) until I reinvoke > CMake: build.

As a side note, it outputs as GCC error, even though what I'm using is Apple clang 13.1.6, which seems to me as a subtle bug.

This is the CMakeLists.txt I used:

cmake_minimum_required(VERSION 3.0.0)
project(sample VERSION 0.1.0)

add_executable(sample main.cpp)
target_compile_features(sample PUBLIC cxx_std_17)

[bobbrow]

• Why the error outputs even tho I set "cmake.parseBuildDiagnostics": false in settings.json? Is it a bug?

Yes. It's #1932.

• Is it possible to make the error and its corresponding squiggle follow the current file after modification? I mean, I would expect not to see the error after removing the problematic line foo(x), but the current implementation seems to hold all the problems (so it points to a wrong line after removing the line) until I reinvoke > CMake: build.

Without rebuilding we can't know that the problem has actually been resolved. We could perhaps add a feature to let you dismiss the error manually.

As a side note, it outputs as GCC error, even though what I'm using is Apple clang 13.1.6, which seems to me as a subtle bug.

Good point. GCC and clang format their errors the same way, so we don't have separate problem matchers for them. We could probably find a way to insert the correct compiler into the problem. Would you mind opening an issue for that?