Closed Feacur closed 3 years ago
Yeah, when you open just the header we make an attempt to find the correct .cpp file, but in this case, it seems that we fail and try to create TU with just the header file in it. Add the name of the source file used in the status bar with the ability to change it when clicked might solve this. I'm not sure if you're describing additional bugs. We capitalizes the file paths when they're not case-sensitive (for our database)...for the purposes of the output log we could probably clean that up a little.
Appreciate the response.
As for additional bugs, I would say there is only one excerpt from this issue is:
... Which I assume is that "CustomEngineStudy.code-workspace" folders structure prevents IntelliSense from working properly. If I drop all but "." folders from there, only then I'll be able to F12 to a header. Specializing a "*.cpp" doesn't help here, as it is one already.
Also thank you for your work, this extension is greatly useful.
This is caused by the CustomEngineStudy-master having demo_game as a child folder, which isn't a scenario we "support", although ideally we should do a better job communicating this. In particular, the CustomEngineStudy-master process is stealing the textDocument/didOpen, so the demo_game process doesn't receive it, causing the Go to Definition to fail. Maybe @bobbrow might have some ideas how we should deal with this. Currently, the only way would be to not have a multi-root workspace with one folder being a parent of another. Another user recently tried to do the same thing at https://github.com/Microsoft/vscode-cpptools/issues/2954 . We could use this issue to track better handling of this multi-root scenario or we could create a new issue.
If the issue is just with textDocument/didOpen, we might be able to send that message to all clients containing the file. We currently filter the messages and just pick one workspaceFolder client to send messages to.
Yeah, sending the did open to all clients with the file sounds good to me. I don't know if there are "other" issues after doing that.
@Feacur Our multi-root support has changes significantly since this issue last had activity. Are you still seeing this issue?
@Colengms Hi! Didn't have a chance to test if intellisense works for nested roots. Since then I've been using a slightly different approach as a workaround, and thus don't see the issue in question:
instead of putting projects inside a workspace
- repository folder and workspace root
- - projects roots
... they are put at the same level with it
- repository folder
- - workspace root
- - projects roots
... which makes the extensions satisfied and decouples responsibilities quite nicely. An issue with rerouting C_Cpp.intelliSenseCachePath
rises sometimes: despite the setting I have, ipch
folder might end up inside the workspace root instead of a target path. Quite a minor nuisance anyways.
We moved the ipch issue to #6723. Please let us know if there are any remaining issues we need to investigate here. Thanks.
Type: LanguageService Cpp IntelliSense quirk: works sometimes or in special cases.
I verified the same behaviour on two different machines.
Note that this project uses C++ unity build approach: compiling single compilation unit "main.cpp". It's totally legal C/C++ code.
Example in project:
Now, there is a header "demo_game/platform_globals.h", which is included inside "pathttracing/main.h", and is relying on headers from "demo_game/main.cpp". Unless I open "main.cpp" before I open "platform_globals.h", I don't get proper headers parsing from IntelliSense.
Describe the bug
To Reproduce repository is here
Expected behavior IntelliSense works for any absolute or relative path.
For any workspace structure.
For settings from *.code-workspace, settings.json, c_cpp_properties.json.
Screenshots Similiar relative path, and "demo_game" is excluded from workspace folders list:
Additional context
If "demo_game" is excluded from the workspace folders list, IntelliSense still won't work well: