microsoft / vscode-cpptools

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

Intellisense is giving unrelated results for definitions #8701

Closed TheJCAB closed 2 years ago

TheJCAB commented 2 years ago

Bug type: Language Service

Describe the bug

All versions of "go to definition" (mouse float tooltip, go to definiton, peek definition, peek type definition...) are giving me patently nonsensical results for some definitions. Usually (maybe always, I need to pay more attention over time), what I get is the definition of some macro from sal.h, not always the same one.

Two things of note: 1- This happens both in our smaller project (we use CMake-tools for building) and in the Windows codebase (I work at MS) which doesn't use CMake. 2- The mouse float tooltip will show completely different definitions depending on which character of the identifier I float over. Usually, they are all different SAL macros. The one I'm looking at actually gives me the correct definition in the tooltip if I float over the last couple of characters of the identifier. But go to or peek definition always inevitably takes me only to the definitions shown if I float over the first couple of characters.

That last one is probably a good clue to what's going on here.

Steps to reproduce

  1. Only for some identifiers in my source code, use any of go to definition, peek definition or float the mouse over it.
  2. Observe the wrong definition.

Expected behavior

Correct definitions shown and traveled to.

Code sample and logs

------- Workspace parsing diagnostics ------- Number of files discovered (not excluded): 6402 Number of files parsed: 512


- Logs from [the language server logging](https://code.visualstudio.com/docs/cpp/enable-logging-cpp#_enable-logging-for-the-language-server)

loggingLevel: Debug loggingLevel has changed to: Debug cpptools/didChangeCppProperties $/setTraceNotification cpptools/fileChanged: C:\Users\jcab\AppData\Roaming\Code\User\settings.json Checking for syntax errors: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h Queueing IntelliSense update for files in translation unit of: X:... censored ....cpp cpptools/fileChanged: C:\Users\jcab\AppData\Roaming\Code\User\settings.json Checking for syntax errors: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h Queueing IntelliSense update for files in translation unit of: X:... censored ....cpp cpptools/finishUpdateSquiggles Error squiggle count: 16 Error squiggle count: 0 Update IntelliSense time (sec): 0.613 loggingLevel has changed to: Error cpptools/didChangeSettings IntelliSense Engine = Default. Enhanced Colorization is enabled. Error squiggles are enabled if all header dependencies are resolved. Autocomplete is enabled. loggingLevel has changed to: Debug cpptools/didChangeCppProperties $/setTraceNotification cpptools/getCodeActions: X:... censored ....cpp (id: 100) cpptools/textEditorSelectionChange cpptools/getDocumentSymbols: X:... censored ....cpp (id: 101) cpptools/textEditorSelectionChange cpptools/activeDocumentChange: X:... censored ....cpp cpptools/getDocumentSymbols cpptools/getFoldingRanges: X:... censored ....cpp (id: 102) cpptools/getCodeActions: X:... censored ....cpp (id: 103) idle loop: reparsing the active document Checking for syntax errors: X:... censored ....cpp Queueing IntelliSense update for files in translation unit of: X:... censored ....cpp cpptools/finishUpdateSquiggles Error squiggle count: 16 Error squiggle count: 0 Update IntelliSense time (sec): 0.318 cpptools/getFoldingRanges: X:... censored ....cpp (id: 104) cpptools/getCodeActions: X:... censored ....cpp (id: 105) textDocument/hover: X:... censored ....cpp (id: 106) textDocument/hover: X:... censored ....cpp (id: 107) textDocument/hover: X:... censored ....cpp (id: 108) textDocument/hover: X:... censored ....cpp (id: 109) textDocument/hover: X:... censored ....cpp (id: 110) textDocument/hover: X:... censored ....cpp (id: 111) Request canceled: 111 textDocument/hover: X:... censored ....cpp (id: 112) textDocument/hover: X:... censored ....cpp (id: 113) textDocument/hover: X:... censored ....cpp (id: 114) cpptools/textEditorSelectionChange cpptools/textEditorSelectionChange cpptools/activeDocumentChange: X:... censored ....cpp cpptools/getCodeActions: X:... censored ....cpp (id: 115) textDocument/definition: X:... censored ....cpp (id: 116) cpptools/getCodeActions: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 117) cpptools/getFoldingRanges: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 118) cpptools/getCodeActions: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 119) textDocument/hover: X:... censored ....cpp (id: 120) textDocument/definition: X:... censored ....cpp (id: 121) cpptools/getCodeActions: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 122) cpptools/textEditorSelectionChange cpptools/getDocumentSymbols: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 123) cpptools/textEditorSelectionChange cpptools/getDocumentSymbols cpptools/activeDocumentChange: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h cpptools/getFoldingRanges: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 124) cpptools/getCodeActions: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 125) idle loop: reparsing the active document Checking for syntax errors: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h Queueing IntelliSense update for files in translation unit of: X:... censored ....cpp cpptools/finishUpdateSquiggles Error squiggle count: 16 Error squiggle count: 0 Update IntelliSense time (sec): 0.325 cpptools/getFoldingRanges: C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.30818\include\sal.h (id: 126)



That's a few mouse floats on different parts of the identifier (giving different definitions), and then a peek definition and then a go to definition.

**Screenshots**
<!-- If applicable, add screenshots to help explain your problem. -->
I can add screen snips if needed, but they wouldn't add any new information.

**Additional context**
<!--
Providing call stacks:
For bugs like crashes, deadlocks, infinite loops, etc. that we are not able to repro and for which the call stack may be useful, please attach a debugger and/or create a dmp and provide the call stacks. Windows binaries have symbols available in VS Code by setting your "symbolSearchPath" to "https://msdl.microsoft.com/download/symbols".

Instructions for attaching debugger to language service process:
https://github.com/microsoft/vscode-cpptools/wiki/Attaching-debugger-to-cpptools-or-cpptools%E2%80%90srv.

Performance analysis:
For a performance issue see instructions at https://github.com/microsoft/vscode-cpptools/wiki/Troubleshooting-Performance-Issues.
-->
None
sean-mcmanus commented 2 years ago

Can you confirm that it's a regression via switching to the non-Prerelease 1.7.1?

Also, there is a known potential IntelliSense regression that only repros with a recent STL, so if you could check if it still repros with a non-preview build of the VC tools that could help. It's also FYI it's not recommended to ship/test production code using the Preview builds of the VC tools.

I'll see if someone else on our team can follow up more...

TheJCAB commented 2 years ago

@sean-mcmanus I can't seem to be able to switch back to 1.7.1. None of the options ("Switch to Release Version" or "Install Another Version...") results in a non-release version. It always ends up in Pre-release 1.8.0, for some reason.

Regarding the VC tools... this is just my local setup. We don't release or test out of my machine 😁. I do find it useful to locally stay at the bleeding edge to watch out for changes before they happen in our official builds. Regardless, that's not particularly relevant to this issue, right?

I'm not going to try switching to a release VS at this time. It's too disruptive. VSCode's CMake tools don't currently allow me to choose which installed toolset of Visual Studio it'll configure for building, when using CMake presets (completely different issue, nothing to do with C/C++ tools), so in order to ensure I'm testing he right thing I'd need to uninstall what I have and I'm not about to do that. I hope you understand.

One clarification: in the description I originally mentioned that this is happening also in the Windows codebase, which doesn't use CMake, and instead uses a separate proprietary extension. for its build system. Well... I actually had that extension disabled, so reproing in that repo was essentially reproing on a folder with plain C++ code (no CMake). It's still a good datapoint that this is happening in two different repos (one CMake and the other not) in my machine.

TheJCAB commented 2 years ago

Ok, I managed to find a way for 1.7.1 to stay up long enough to test, and it works fine in that version. The extension then always auto-updates to the preview 1.8.0. So this seems to be an issue with 1.8.0.

sean-mcmanus commented 2 years ago

You need to also set extensions.autoUpdate to false (I think that requirement will go away once the non-Release 1.8.2 or so is released),

There is some IntelliSense bug (I believe a regression) that only repros with a new STL (I'm not sure of the complete details). We could potentially cherry pick the fix into 1.8.1 to rule that out.

Our team has the Preview and non-Preview builds of VC installed and we can switch between which one gets used by Ninja/CMake depending on which Developer Command Prompt we use.

This sounds like it could be an important regression we should investigate.

TheJCAB commented 2 years ago

"switch between which one gets used by Ninja/CMake depending on which Developer Command Prompt we use" - You mean launch VSCode from a developer command prompt? We don't normally do that, and I never thought of doing that. In fact, my VSCode instances are ususally auto-launched for me after a Windows Update reboot and remain open until the next Windows Update. It's... fun how it remembers which ones I had open. GUI tools are... GUI. Not exactly natural to manage them from a command prompt. But we digress... 😊 this is a CMake tools and personal workflow issue, if at all.

"set extensions.autoUpdate to false" - but that halts updates of all extensions. Is this an issue within the C/C++ tools extension?

I'll be happy to try any potential fixes you throw my way.

Thanx!

sean-mcmanus commented 2 years ago

I was referring to building from the Developer Command Prompt. If you're building from VS Code using the CMake Tools extension you can choose which VC toolset you're using from the dropdown UI in the status bar.

extensions.autoUpdate to false would be needed if you're using VS Code Insiders and you don't explicitly set C_Cpp.updateChannel to "Default"...otherwise, make sure C_Cpp.updateChannel is set to "Default". However, 1.8.0 changes our update mechanism to VS Code's Insider mechanism so there could be some bug somewhere. @Colengms you may want to review this report.

sean-mcmanus commented 2 years ago

We believe this is fixed with https://github.com/microsoft/vscode-cpptools/releases/tag/1.8.1 (let us know if you're still hitting it).