Intellisense squiggles appear even though headers are discovered #3731
Comments
|
F12 on So if you're getting squiggles on the headers it means IntelliSense isn't able to find the files via the includePath used. Can you run the C/C++: Log Diagnostics command with the file with error squiggles to see what IntelliSense settings are getting used and if the includePath can be fixed? |
sean-mcmanus
added
Language Service
more info needed
|
Sure! Here it is. Blurred out my username, though. |
|
Maybe this is what is wrong: the |
How can I make it appear again when I disable these squiggles? |
|
@feijie825 You can change the C_Cpp.errorSquiggles setting. |
|
@sean-mcmanus Thank you. I've tried to change the settings. But it didn't work. |
|
@feijie825 How did you disable the squiggles originally? |
|
Is it possible to take CMakelists, if there is one, as reference for include path searching? |
|
@Victsz You can use the CMake Tools extension and set the configurationProvider (in c_cpp_properties.json, or the C_Cpp.default one) to "vector-of-bool.cmake-tools". |
@sean-mcmanus after cmake tools update,
I change accordingly but the intellisense engine not working |
|
@Victsz We didn't change the configurationProvider to |
|
@bobbrow |
|
@Victsz We're releasing a 0.26.2-insiders tomorrow which has a bunch of bug fixes...your issue with CMake tools may be a new issue though that we haven't been able to repro/diagnose yet. Do you know if the regression is caused by the newer version of the C/C++ extension or the CMake extension? I got CMake Tools to be configured on Linux (it keeps choosing the wrong kit on startup though, but it gets fixed after I choose "Unspecified"). Do your logs show the correct paths in the output "Custom configuration received: { … "includePath": [....]"" |
|
It is about the newer verison of CMAKE tools which in my case update just 2 or 3days ago. Its a remote ssh project from win10 and it can find the kit correctly I`m not sure about the last question, from my point of view, its not actually parsing the cmake files. |
|
Is it possible to provide a way to rollback CMAKE tools, I tried pick another version but it`s not working. |
|
@Victsz I hit the same issue. See microsoft/vscode-cmake-tools#904 . If you look at your C/C++ logs you can see the input includePaths the CMake Tools extensions sends us. |
|
@sean-mcmanus After cmake 1.2.2 I can jump to header definition. After edit "configurations": [["includePath"]] , the intellisense can work properly |
|
@Victsz I don't understand. What does "edit configurations: [["includePath"]]" mean? Is there a bug still? With CMake Tools or the C/C++ extension? |
|
@sean-mcmanus I had to add headers in to Current Configuration {includePath} as shown below, now it can jump to definition but cannot find reference. The weird thing is it can jump to definition from the same expression that cannot find reference.
Current Configuration: |
|
Adding paths to the includePath should only affect things if the configuration provider fails to provide the includePath. You might want to file a bug with the CMake Tools extension if you haven't already: https://github.com/microsoft/vscode-cmake-tools/issues . If the Go to Def is working but Find All References works, it means there is a failure to create your database (so Go to Def on definitions in other TUs should also fail as well). You might want to try setting your C_Cpp.default.browse.databaseFilename to something like "${workspaceFolder}/vs/vc.db" to ensure that it is able to get created (assuming it's failing at it's default location). Killing any dangling/old process using the database may also fix it (i.e. #4508 (comment)). Does running "/usr/bin/g++ --version" show 8.1 as the version? If not, it looks like we may also be failing to query your compiler for includes/defines, possibly due to the compiler output being in a different language. |
|
@sean-mcmanus I created an issue microsoft/vscode-cmake-tools#959, it would be great if you can help to explain with more details when necessary, in case I did not state clear enough. Yes I found many dangling process after close my vscode, and killed them. I also tried reset c++ intellisense db but nothing special and I have no idea if the reset action is successful "/usr/bin/g++ --version" returns 9.1.1 same as the selected config |
|
@sean-mcmanus And the kit should be correct as well because I have no problem to build the project. The log for To ensure my project is setup properly, I open the project in QTCreator and everything is ok there. |
|
@Victsz Yeah, you're hitting a crash (the "Failed to read response"). If you could attach a debugger to the Microsoft.VSCode.CPP.IntelliSense.Msvc process before the crash occurs and get a call stack that would help identify the issue (you could copy/paste the file contents if the crash occurs too soon after opening the file). Also, we don't understand the -std=gnu++17 yet, so that might cause issues. You might need to add some defines like _GNU_SOURCE as a partial workaround. Using -E to obtain a preprocessed TU file may help in obtaining an isolated repro. |
|
@sean-mcmanus "Using -E to obtain a preprocessed TU" where I can use -E Custom configurations received: |
|
Yeah, you won't notice any difference in the logging output (the gnu++17 in the output gets overwritten by us with "c++17"), but it might fix issues that relied on the _GNU_SOURCE define that would get set if handled it the gnu++17 correctly. You would use -E in your build command...you also might need to output the results to some file. There's some debugging info at https://code.visualstudio.com/docs/cpp/cpp-debug . You basically just create a launch.json file from the VS Code Debug view "gear icon", add an "attach" configuration for your debugger, and if you're on Linux you need to set the "program" to something like |
|
@sean-mcmanus I try use gdb attach to Microsoft.VSCode.CPP.Extension.linux, but the process has not crashed.
Meanwhile, the jump to definition works fine, but neither find reference nor auto completion Oh I attached to one of the child processes,hope it will help
|
|
|
|
|
|
@sean-mcmanus |
|
@Victsz Yeah, it's easier to track issues if they're in separate issues. I don't see any crash call stacks. You appear to be attaching to the main process instead of Microsoft.VSCode.CPP.IntelliSense.Msvc.linux, which is what was crashing previously. I'm not sure your comment about "3 hours later the process is still running"...is our extension supposed to be running or is it dangling? I don't understand how a Microsoft.VSCode.CPP.Extension process is being launched by a Find All References operation. Are you using a multi-root workspace? The top of the call stack with the pthread waits is insufficient for us to tell what it's stuck on -- we need the full call stack. And the processes have multiple threads, many of which are waiting under normal conditions. It might be easier to use VS Code to debug so you can see the call stacks for all the threads, unless you're familiar with the correct gdb commands to use to get the same info. |
|
@sean-mcmanus "I don't understand how a Microsoft.VSCode.CPP.Extension process is being launched by a Find All References operation."
And, down grade to 0.26.0 solved the issue. |
|
21797 is the IntelliSense process. One IntelliSense process should be created after a file is first opened -- it is not supposed to end unless it's "supposed" to. Doing Find All References can launch multiple temporary IntelliSense processes that should ago away after the FAR is done. Is the IntelliSense process not crashing for you? In the screenshot I saw "No IL available" which is a non-crashing failure. |
|
Actually, looking again -- it doesn't appear from your screenshot that 21797 is the IntelliSense process (maybe I'm not understand what the output is showing). Do you see a Microsoft.VSCode.CPP.IntelliSense.Msvc.linux process when you open a file? If other main processes are launching, that would imply the previous one is crashing. |
|
21797 is the IntelliSense process. One IntelliSense process should be created after a file is first opened -> no it is not. you can tell from the process time , see below, 21797 was started at 17:54 one mintue later than 20806. And since I am doing well on 0.26.0, I dont have the environment to reproduce. But Im pretty sure you are hitting some forever loop issue which is induced since 0.26.1 |
|
More info can see from this screenshot, it is about the gdb on main process 20806.
|
|
Your screenshot shows Microsoft.VSCode.CPP.Extension.linux -- is the process name not correct? To debug Microsoft.VSCode.CPP.IntelliSense.Msvc.linux (the IntelliSense process), you just change the "program" to be that (my example was with the main process, sorry about the misleading example). If you don't see a Microsoft.VSCode.CPP.IntelliSense.Msvc.linux process after opening a file (and after recursive includes processing is finished) then it would imply the process is crashing or falling back to the Tag Parser mode due to missing includes. Doing a Find All References could cause a crashed IntelliSense process to respawn. I don't see evidence of a "forever loop". Do you mean a deadlock? Is there endless CPU usage? In order for us to identify/fix the crash, we would need you to open a blank .cpp, attach to the IntelliSense process, paste in the crashing code, and then provide the call stack of the crash. If you believe the process is stuck we'd need a call stack for that as well. |
|
I don't see evidence of a "forever loop". Do you mean a deadlock? Is there endless CPU usage? -> I can see the find all reference bar keep looping for 3 hours until i killed that 21797, this might be the most obvious tell. It is a remote project, after setting launch.json it cannot find process. I am on a tight schedule will get back to this issue latter. Thanks for your help. |
|
We need more information to fully investigate this issue. If you update to the latest version of the extension and your issue persists, please reply with additional information that can help us investigate your issue. |
Type: LanguageService
Hello everyone,
I'm having some issues with the Intellisense feature of the C++ extension of VSCode.
Describe the bug
I have a ROS workspace, whose source folder I have opened in VSC, with path:
"/home/george/ros_workspaces/uav_ftc/src/.All local files are visible and all included files which are situated in this folder.
Also, I have included the source files from another program (called ACADO for reference), whose path I have added in the
includePathvariable of c_cpp extension.All header files and types of the ACADO source are apparently discovered, since hitting F12 will open and point to the corresponding line.
However, squiggles are broken and exist everywhere the ACADO source is referred. Errors include include errors and undefined identifiers.
I do not wish to turn to Tag Parser engine for intellisense, because apparently it also doesn't squiggle obvious errors, such as actually undefined symbols.
To Reproduce
I'm not sure if I should go all the way and provide you with files for two large projects...
Expected behavior
I expected headers and symbols of the external source files to be parsed and recognized by Intellisense correctly
Screenshots
Example:
DifferentialStatetype looks undefinedbut hitting F12 on it leads to its definition:
Additional context
The local
c_cpp_properties.jsonfile:{ "configurations": [ { "browse": { "databaseFilename": "", "limitSymbolsToIncludedHeaders": true }, "includePath": [ "/home/xxx/UserPrograms/ACADOtoolkit/acado/**", "/home/xxx/ros_workspaces/uav_ftc/devel/include", "/opt/ros/melodic/include", "/home/xxx/ros_workspaces/uav_ftc/src/last_letter/last_letter/include", "/home/xxx/ros_workspaces/uav_ftc/src/last_letter/mathutils/include", "/home/xxx/ros_workspaces/uav_ftc/src/uav_ftc/include", "/home/xxx/ros_workspaces/uav_ftc/src/last_letter/uav_utils/include", "/usr/include" ], "name": "Linux", "intelliSenseMode": "gcc-x64", "compilerPath": "/usr/bin/gcc", "cStandard": "c11", "cppStandard": "c++17" } ], "version": 5 }Thank you in advance for your time.
Let me know if additional information is needed or if I have posted in the wrong issue tracker.
The text was updated successfully, but these errors were encountered: