microsoft / vscode-cpptools

Official repository for the Microsoft C/C++ extension for VS Code.
Other
5.52k stars 1.55k forks source link

Intellisense not working after upgrade from v1.20.5 to v1.21.6 #12595

Open g199209 opened 2 months ago

g199209 commented 2 months ago

Environment

Bug Summary and Steps to Reproduce

The same project, v1.20.5 works well, but v1.21.6 can not work, the basic code highlight and jumping not working.

Example:

v1.21.6

a8e7f4bcdc007db0af23cffee3ee7029_compress

v1.20.5

image

Configuration and Logs

v1.21.6 has such error log:

> Quick info operation failed: FE: 'Compiler exited with error - No IL available'
> using Tag Parser for quick info

v1.20.5 doesn't have it.

Other Extensions

No response

Additional context

No response

sean-mcmanus commented 2 months ago

This is because the IntelliSense parser is encountering an unrecoverable error such that at the quick info location, it doesn't think any code is at that spot, which can occur if it has picked up the wrong includePath to a header. Are you able to open some of the headers (via go to definition) took for an error in one of them, and/or preprocess the translation unit to a single file, such as via something like clang <compilerArgs> -E -dD -fno-blocks <filename>?

Another thing to try is to set the setting C_Cpp.intelliSenseCacheSize to 0 and reloading window to see if that fixes it (if not you remove that setting change).

g199209 commented 2 months ago

I wonder what's the related change bwtween v1.20.5 and v1.21.6? This is a large project and I can't share the code.

sean-mcmanus commented 2 months ago

@g199209 You don't need to share the code if you can see what the initial parsing error is in the TU. We currently hide the errors that occur in the header files which can make it hard to see the root cause. The intelliSense cache also has a known bug where it can store the wrong header sometimes.

You can see most of the changes described in our release notes: https://github.com/microsoft/vscode-cpptools/releases .

sean-mcmanus commented 2 months ago

@g199209 Also, if you run C/C++: Log Diagnostics with 1.20.5 and 1.21.6 and compare the difference it might show a different configuration is being used, which could cause IntelliSense parsing difference (otherwise, it could be an IntelliSense parsing regression bug).

PepeOjeda commented 1 month ago

I have had this same problem, where intellisense does not work at all, but also a different problem where in some files it reports strange errors like "strlen is not defined" and in other files it gets stuck on "Loading..." forever.

Annoyingly, it seems to be inconsistent about which error happens (after having changed extension versions multiple times), so right now I only have info about the second case. I have included a (huge, sorry) preprocessed file and the output of Log Diagnostics for both versions. Bug-report.zip

sean-mcmanus commented 1 month ago

@PepeOjeda With 1.21.6, we're not marking the system includes from your compiler with -isystem so they get moved to end of the includes list, so that might be the cause. You might also want to try 1.22.3 to see if that helps, since the recursive includes implementation is also different there. i.e. I think the issue is you have includePaths being added due to ** that contain files with the same name as system headers, so the system headers aren't being used when they're supposed to. If you sent g++ the equivalent command line with -I and -isystem you'd probably get a similar compile error.

PepeOjeda commented 1 month ago

@sean-mcmanus This sounds like it might be it, since there are serveral files named "string.h" in the ROS packages I'm including, but I've been unable to fix it by manually adding "usr/include" to the start of the include paths (would this even help? I must admit I'm a bit out of my depth here).

Switching to 1.22.3 actually caused several different errors to pop up, complaining about types and namespaces not being defined even though there were no include errors: Screenshot from 2024-09-16 09-57-58

I also tried removing all the recursive include paths and substituting them for a list of all the include directories, but it didn't seem to change anything. Also of note, I was unable to reproduce these issues on a different machine with the same code and the same c_cpp_properties.json, so maybe it's some issue with the system headers themselves?

g199209 commented 1 week ago

@sean-mcmanus This is cause by recursive includes, I change my include path setting to avoid using **, which solve the problem.