1.24.5

[sean-mcmanus]

Instructions

The extension can be obtained by one of the methods below:

• Install the "C/C++" or "C/C++ Extension Pack" extension published by Microsoft from the Extensions view in VS Code.
• Download a vsix that matches your OS from the Assets section below (and install it via the method mentioned above). The previous download methods have the vsix signatures verified by the Marketplace, but for this method, you can do the verification by downloading the matching manifest and signature.p7s file and running npx @vscode/vsce@latest verify-signature -i <.vsix> -m <.signature.manifest> -s <.signature.p7s> vscode-vsce#1044.

Requirements

• VS Code 1.67.0 or later (April 2022).
• Windows 7+ (x64, arm64), macOS 10.12+, Linux (Ubuntu 16+, etc.).
  • Debugging is not supported on CentOS 7 or RHEL 7. The last supported version was 1.22.11: #13219.

Changes

New Feature

• Add support for Copilot descriptions in hover tooltips, controlled by the C_Cpp.copilotHover setting. PR #13385

Enhancements

• Improve/fix the switch header/source feature. #2635
• Add detected test frameworks to the Copilot context when #cpp is used. PR #13285
• Update clang-tidy and clang-format from 19.1.7 to 20.1.2. PR #13348
• Remove some unnecessary files from the vsix. PR #13368
• Improve the logging when a non-existent path is used for indexing. PR #13372
• Add a new recursiveIncludes property to c_cpp_properties.json. PR #13374
• Remove the C_Cpp.updateChannel setting. PR #13376
• Add handling of -cxx-isystem, -stblib++-isystem, -isystem-after, and --include-barrier Clang compiler arguments when composing the order of include paths used by IntelliSense.
• Defer the building of the include completion cache to another thread to improve performance when a file is opened.
• On shutdown, immediately terminate the IntelliSense process instead of waiting 2 seconds.

Bug Fixes

• Fix an IntelliSense crash in build_sections. #12666, #12956
• Fix random IntelliSense process crashes on Linux/macOS when C_Cpp.intelliSenseCacheSize is > 0. #12668
• Fix a bug in which hundreds of custom configuration requests could be sent on startup before the configuration provider has registered. #13166
• Fix handling of the -framework compiler argument. #13204
• Fix a potential race between didChange and didOpen. PR #13209
• Fix an issue with the .editorconfig tab_size. PR #13216
• Fix a potential deadlock on shutdown if configuration providers are used. #13218
• Fix the code analysis mode in the Language Status bar not updating after the setting changes. #13240
• Fix system include/framework paths being used as a fallback for user include/framework paths in the base configuration. PR #13247
• Fix the svdPath description being missing for launch.json. #13287
• Update the Windows SDK packages referenced in the walkthrough. #13290
• Fix an issue with C: being treated as a relative path. PR #13297
• Fix an unnecessary TU reset when a change is detected in a compile_commands.json file that is not used by the active configuration. #13317
• Fix handling of URIs in web environments. #13327
• Fix a potential deadlock after using 'Reset IntelliSense Database'. #13337
• Fix some localization bugs. PR #13373
• Fix IntelliSense showing the wrong size of objects. #13375
• Fix the get_mangled_function_name IntelliSense process crash. #13358
• Fix an issue with duplicate forced includes being removed. Multiple forced includes of the same file should now properly be included multiple times.
• Fix an issue in which the base configuration browse paths may not get populated when using a custom configuration provider.
• Fix an issue with forced includes not being resolved against the same include path search order as a compiler would.
• Fix a ${workspaceFolder}/* include path not being used as a non-recursive browse path.
• Fix an issue with include path ordering of paths specified with the -imsvc argument.
• Fix a race condition that could result in incorrect include completion results.
• Avoid reporting an error due to multiple didOpen requests after a crash.
• Fix an inaccurate cursor position for IntelliSense update.
• Fix an IntelliSense crash if a "bad seq number" occurs.
• Fix processes potentially getting stuck on shutdown.
• Fix a potential crash when saving a file.
• Fix a random crash during code analysis.

---

This discussion was created from the release 1.24.5.

[mrx23dot]

Is it me, or this way of detecting if we are in VSCode no longer works?

#if defined(_MSC_VER) /* for VScode detection */

it greys it out

I would need a more universal way then.

[sean-mcmanus]

_MSC_VER is set by cl.exe and by IntelliSense with the msvc modes. If you see _MSVC_VER grayed out then you might not be using an msvc IntelliSense mode. You can check for __INTELLISENSE__ potentially.

[mrx23dot]

I'm using Amazon code completer, thank you __INTELLISENSE__ did work.

[zhekaso]

Hello, I need help.

I use the same c_cpp_properties.json for 1.24.3 and 1.24.5, but on the latest version cpptools eat up all my pc ram. As I can see in the progress info of the file analyser in version 1.24.5 vscode is analysing several times more files.

[sean-mcmanus]

@zhekaso You mean 1.24.3/1.24.5, right? The recursive includes properly only applies to IntelliSense so it's only expected to affect the cpptools-srv process and not the cpptools process. If you set C_Cpp.loggingLevel to "Debug" the C/C++ logging might indicate which additional files are being tag parsed and you could potentially add some C_Cpp.files.exclude. I recall we did fix some bug with multi-root projects where it might have not processes some files when it should have. The recursiveInclude properties are set to their defaults, so it's not expected to have any change in behavior unless you modify those settings.

[Colengms]

Hi @zhekaso . Could you open an issue and provide the information requested in the new issue form? In particular, enabling logging and providing the log output should tell us something about what's going on. Any additional information, such as exactly what you're seeing regarding many files being analyzed, would be helpful as well. I'd be glad to look into this ASAP.

[Colengms]

As Sean mentioned, we did fix a bug where only the first workspace in a multi-root project was being analyzed. That fix could definitely result in seeing many more files analyzed. But those would be files that should have been getting parsed.

Though, that is related to the number of files being parsed into the database and wouldn't explain increased RAM usage. If something is using up all of your RAM, that would definitely be a bug.

[zhekaso]

Thanks for the answer, I will create issue and provide logs.

[zhekaso]

I look at logs. On both versions *.3 and *.5 File detection: processing files - 211734.
On version *.3 Analysis: files processed - 4525, on *.5 analysis is much longer so i don't wait it is finished.

So I matched file names in output on version *.3 and *.5 and discovered that in *.3 boost include files were not all analysed. I'm not sure creating issue is required. "C_Cpp.files.exclude": { "**/base/common/include/boost/**": true} helps me because I don't need boost in this subproject.

Project is not very good organized and "includePath", actualy containes to muсh actualy not required files. For example boost is analized in 13 copies(per boards).