Open hideo67 opened 1 year ago
Hi @hideo67 . You're using a configurationProvider
, but there does not appear to have been a custom configuration received for main.cpp
. If your CMakeLists.txt is composed correctly, there would seem to be an issue with CMake Tools not providing a configuration for that file as expected.
Currently, if a custom configuration is not received, the C/C++ Extension will try to use the 'browse configuration' to compose a configuration for the file.
Looking at the browse configuration returned by CMake Tools, I see the following include paths:
/work/group1/user01/sample/include
/work/group1/user01/sample
However, the path to your source file appears to be: /work/00/group1/user01/sample/main.cpp
, which appears to be under a different parent path than what the browse configuration was provided for.
Perhaps you modified the paths in the logs you provided, to scrub it for personal information, and updated some paths incorrectly?
Hi Colen. Thanks for looking through the logs. Yes I modified the path names in the logs. However the path structure is kept the same. /work/group1 is a symbolic link to /work/00/group1.
Should I post this to the cmake-tools project?
Hi @hideo67 . I suspect the issue is related to the symbolic link, and a comparison or lookup failing with a path either with or without the symbolic link resolved.
I think there are two issues here. One issue would seem to be with CMake Tools, as it should be successfully providing a custom configuration for the source file regardless of whether we're requesting it using a path that has the symbol link resolved or not resolved. It's likely not resolving symbolic links in the path it receives in that request, or the paths it compares that to.
However, even without a custom configuration, the header should be resolved properly, as both the custom browse configuration and the base configuration also refer into the necessary include path. That would seem to be a problem with symbolic links not being resolved under some other code path in the C/C++ extension.
If you disable the custom configuration provider (by temporarily removing configurationProvider
from your base configuration), does that avoid the issue?
We can use this issue to track problems with the general scenario in which a folder is opened under a symbolic link.
Hi @Colengms. I removed configurationProvider from my base configuration through Ctrl-, (I'm not quite sure if I ever set this before) and it worked!
Is there anything else I should try or provide information?
Hi @hideo67 . I think we have enough information from your logs to investigate further. We have multiple issues with symlinks, and will likely investigate and address them all together.
Another potential work-around would be to open the workspace from the resolve path instead of the path containing the symlink, and using fully resolved paths where necessary to use full paths.
Environment
Bug Summary and Steps to Reproduce
Bug Summary:
For a cmake project which can be successfully built from within vscode, IntelliSense cannot locate header files that are stored in a subdirectory of the project root. Clicking on include directives for system header files succeeds. include directives for project local header files fails. The compiler is intel's icpc.
reproduced using a minimal project as follows: directory structure:
my_func.h is included from both source files as
#include <my_func.h>
The following error appears in the problems pane:
include errors detected based on information provided by the configurationProvider setting. Squiggles are disabled for this translation unit (/work/group1/user01/sample/main.cpp).
cannot open source file "my_func.h"
Steps to reproduce:
Expected behavior: the header file my_func.h appears in editor space.
Configuration and Logs
Other Extensions
cmake
Additional context
CMakeLists.txt:
main.cpp
include/my_func.h