Closed sean-mcmanus closed 1 week ago
@jondo2010 We need more info -- when you open the workspace what folders does it list as "Folder: … will be indexed"? Those are the folders which we "tag parsed"...typically the files under the workspace root. What is your workspaceRoot -- /home/john? We have a bug where the browse.path is not populated correctly when compile_commands.json was used, but this seems like the opposite of that. My guess is that the workspaceRoot is being forced into the browse.path (intentionally)...you could try adding ${workspaceRoot}/ to the browse.path setting in c_cpp_properties.json to prevent this ( means non-recursive). Also, do you know if this is a 0.17.8-insiders regression compared to 0.17.7? I don't remember us touching this area of code for 0.17.8-insiders.
@sean-mcmanus thanks for the prompt reply.
Folder: /usr/lib/gcc/x86_64-linux-gnu/7/include/ will be indexed
Folder: /usr/local/include/ will be indexed
Folder: /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed/ will be indexed
Folder: /usr/include/ will be indexed
Folder: /home/john/Devel/werkstatt/ will be indexed
Upon further inspection of the logs, I think the problem is that Bazel has symlinked some root folders into my workspace.. I added the culprits to my "files.exclude", hopefully that fixes it!
Ok, running 0.18.1 now.
My workspace folder contains a symbolic link (${workspaceRoot}/bazel-werkstatt/external/local_files
) which resolves to root folders on my disk, /usr/share
, /usr/src
, etc.
I have tried several permutations of files.exclude
:
files.exclude: {
"/usr/src/**": true,
"/usr/share/**": true,
"${workspaceRoot}/bazel-werkstatt/external/local_files/**": true,
}
Intellisense is completely ignorning this and still indexing my entire disk. I can confirm this with the debug console, as well as checking the files
table in .browse.VC.db
If I rm this symbolic link, then reset the database, everything behaves correctly.
To reproduce, should be as simple as creating a symlink in your workspace folder to /usr/share
or some such, then adding an files.exclude
entry.
We believe this is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.3.0-insiders5 , but we don't correctly handle files.exlude with "/**"
at the end (removing the "/**"
should fix that).
I have a fix for the /**
at the end of files.exclude for our next-next release: https://github.com/microsoft/vscode-cpptools/issues/7331
So, everything is fixed in this issue? Can we close it?
Copied from https://github.com/Microsoft/vscode-cpptools/issues/2156#issuecomment-411328125 .
I'm definitely still experiencing this issue. I updated to 0.17.8 yesterday.
I'm using a
compile_commands.json
Which the extension seems to read just fine, identifying the correct include paths for this file I just opened:
However I also get a ton of debug messages about parsing files from my home folder and elsewhere on the system that have nothing to do with this project and are not in the include paths: