CMake Tools not forwarding configuration to cpptools

[stark-dev]

Brief Issue Summary

Hi,

as discussed in this thread, I'm reporting an issue when the project folder is stored in a path that contains a symlink. In my configuration, a separate volume for projects is mounted to /mnt/data/ws. I created a symlink /home/user/Developer/Projects to /mnt/data/ws/ and I normally run the editor with code . from within /home/user/Developer/Projects/MyProject (which contains the symlink).

The issue appeared after some days of regular use, without any specific action on my side (no updates, no changes in vscode configuration. When opening the project, it can't find any reference to the headers included. As pointed out by @bobbrow, cpptools does not get the configuration with all include paths.

In attachment the log diagnostics of CMake Tools and cpptools. The faulty ones are related to the path that contains the symlink, the good logs come from the same project cloned in a standard path without symlink.

Thanks in advance for your help, let me know if any further info is needed.

CMake Tools Diagnostics

-------- Diagnostics - 8/26/2022, 6:51:37 PM
Version: 1.11.5
Current Configuration:
{
    "name": "Linux",
    "includePath": [
        "${workspaceFolder}/**"
    ],
    "defines": [],
    "compilerPath": "/usr/bin/gcc",
    "cStandard": "gnu17",
    "cppStandard": "gnu++17",
    "intelliSenseMode": "linux-gcc-x64",
    "configurationProvider": "ms-vscode.cmake-tools",
    "compilerPathIsExplicit": true,
    "cStandardIsExplicit": true,
    "cppStandardIsExplicit": true,
    "intelliSenseModeIsExplicit": true,
    "mergeConfigurations": false,
    "browse": {
        "path": [
            "${workspaceFolder}/**"
        ],
        "limitSymbolsToIncludedHeaders": true
    }
}
Custom browse configuration: 
{
    "browsePath": [
        "/home/user/Developer/Projects/MyProject/public/include",
        "/home/user/Developer/Projects/MyProject/build/submodule/include",
        "/home/user/Developer/Projects/MyProject/build/submodule/test/helper/home/user/Developer/Projects/MyProject/submodule/build/googletest-src/googletest/include"
    ],
    "compilerPath": "/usr/bin/c++",
    "compilerArgs": [],
    "compilerFragments": [
        " -D__FILENAME__='\"$(subst /home/user/Developer/Projects/MyProject/,,$(abspath $<))\"' -g -fvisibility=hidden -fvisibility-inlines-hidden",
        "-g3",
        "-ggdb",
        "-Og",
        "-Wall",
        "-Wextra",
        "-Wshadow",
        "-Wcast-align",
        "-Wunused",
        "-Wpedantic",
        "-Wconversion",
        "-Wsign-conversion",
        "-Wsign-compare",
        "-Wnull-dereference",
        "-Wdouble-promotion",
        "-Wformat=2",
        "-Werror",
        "-Wno-narrowing",
        "-Wno-psabi",
        "-Wno-attributes",
        "-Wmisleading-indentation",
        "-Wduplicated-cond",
        "-Wduplicated-branches",
        "-Wlogical-op",
        "-Wnon-virtual-dtor",
        "-Wold-style-cast",
        "-Woverloaded-virtual",
        "-Wuseless-cast",
        "-Wcast-align=strict",
        "-std=gnu++17"
    ]
}
Translation Unit Mappings:
[ /home/user/Developer/Projects/MyProject/src/file.cpp ]:
    /home/user/Developer/Projects/MyProject/src/file.cpp
Translation Unit Configurations:
[ /home/user/Developer/Projects/MyProject/src/file.cpp ]:
    Process ID: 174984
    Memory Usage: 114 MB
    Compiler Path: /usr/bin/c++
    Includes:
        /usr/include/c++/9
        /usr/include/x86_64-linux-gnu/c++/9
        /usr/include/c++/9/backward
        /usr/lib/gcc/x86_64-linux-gnu/9/include
        /usr/local/include
        /usr/include/x86_64-linux-gnu
        /usr/include
    Standard Version: c++17
    IntelliSense Mode: linux-gcc-x64
    Other Flags:
        --g++
        --gnu_version=90400
Total Memory Usage: 114 MB

------- Workspace parsing diagnostics -------
Number of files discovered (not excluded): 9547
Number of files parsed: 3496

Debug Log

No response

Additional Information

c_cpp_diagnostics-faulty.log c_cpp_diagnostics-good.log cmake_diagnostics-faulty.log cmake_diagnostics-good.log

[bobbrow]

What linux distro/version are you using? I just tried this setup with Ubuntu 20.04 and was not able to reproduce the logs the way you have them. What I'm seeing is that in your faulty logs, the path with the symlink unresolved is listed as the opened folder, but in my attempts to reproduce this, my logs show the resolved real path to the data folder is listed.

From your description it sounds like this suddenly changed on your side. Are there any other system settings that could be at play here? Maybe I need to try a few more times?

[stark-dev]

I'm also using Ubuntu 20.04, running in VMware Workstation. The project volume is mounted as in /etc/fstab with default options and is then symlinked in the home folder. I never had issues to access the symlink from terminal or file manager, so I suppose everything works well on that side.

Just to confirm, I tried to open the faulty workspace from the direct path and it works after clearing the build folder, which is not the case if I open the path with symlink (even after clearing the build folder).

I noticed that when the terminal is opened at a path that contains the symlink, opening a new tab will resolve the symlink (usually by opening a new tab it cds into the same folder, but in this case the first is pointing to /home/user/Developer/Projects and the second to /mnt/data/ws). Could there be some similar mechanism in vscode? Or are symlinks always resolved?

[stark-dev]

I can add also that it may be require some time to be triggered, in my case it happened after 4-5 days, although there was no specific reason or change in the machine setup. I though about vscode and extension updates also, but I suspended them to see if it was happening again, so also that can be discarded

[bobbrow]

I asked the VS Code team about this last week and got a response today.

It looks like it matters how you invoke VS Code on the command line. I found that if you run code . from inside the symlinked folder, you will get realpathed files and everything works as expected. If you run code <symlink_path> from outside the symlink folder, then you get symlinked files and our path matching breaks because cpptools sends its configuration requests with the realpath. You can use the former launch method as a workaround until we fix the extension to handle this.

[jesustorresdev]

I guest I have the same problem. I'm using VSCode in Windows to open a folder in WSL2 using Remote WSL. cpptools and cmake-tools integration works fine if I open /mnt/d/Workspace/ssoo, that is where is my project. But I have some problems opening C and C++ files if I open /home/jesus/Workspace/ssoo, where /home/jesus/Workspace is a symlink to /mnt/d/Workspace.

I open VSCode from Windows icon.