Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Version 1.70 is now available! Read about the new features and fixes from July.
Dismiss this update
Files can be corrupted due to the fact that you either have a multi-root workspace where one folder is a child of the other, or you are using symlinks to open your file. Reduce the folders in the workspace to one and remove the symlink. This should fix your problem.
Without any configuration, the extension will attempt to locate headers by searching your workspace folder and by emulating a compiler it finds on your computer. (for example cl.exe/WSL/MinGW for Windows, gcc/clang for macOS/Linux). If this automatic configuration is insufficient, you can modify the defaults by running the C/C++: Edit Configurations (UI) command. In that view, you can change the compiler you want to emulate, the paths to include files you want to use, preprocessor definitions, and more.
Or, if you install a build system extension that interfaces with our extension, you can allow that extension to provide the configurations for you. For example, the CMake Tools extension can configure projects that use the CMake build system. Use the C/C++: Change Configuration Provider... command to enable any such extension to provide the configurations for IntelliSense.
A third option for projects without build system extension support is to use a compile_commands.json file if your build system supports generating this file. In the "Advanced" section of the Configuration UI, you can supply the path to your compile_commands.json and the extension will use the compilation information listed in that file to configure IntelliSense.
Note: If the extension is unable to resolve any of the #include directives in your source code, it will not show linting information for the body of the source file. If you check the Problems window in VS Code, the extension will provide more information about which files it was unable to locate. If you want to show the linting information anyway, you can change the value of the C_Cpp.errorSquiggles setting.
The most common reason for this is missing include paths and defines. The easiest way to fix this on each platform is as follows:
Linux/Mac: Set intelliSenseMode": "clang-x64 or intelliSenseMode": "gcc-x64 and compilerPath in c_cpp_properties.json to the path to your compiler.
Windows: If you are using the Microsoft C++ compiler, set intelliSenseMode": "msvc-x64, but don't add the compilerPath property to c_cpp_properties.json. If you are using Clang for Windows, set intelliSenseMode": "msvc-x64, and compilerPath in c_cpp_properties.json to the path to your compiler.
See Get Started with C++ and Mingw-w64 in Visual Studio Code.
See Get Started with C++ and Windows Subsystem for Linux in Visual Studio Code.
These two settings are available in c_cpp_properties.json and can be confusing.
This array of path strings is used by the "Default" IntelliSense engine. This new engine provides semantic-aware IntelliSense features and will be the eventual replacement for the Tag Parser that has been powering the extension since it was first released. It currently provides tooltips and error squiggles in the editor. The remaining features (for example, code completion, signature help, Go to Definition, ...) are implemented using the Tag Parser's database, so it is still important to ensure that the browse.path setting is properly set.
The paths that you specify for this setting are the same paths that you would send to your compiler via the -I switch. When your source files are parsed, the IntelliSense engine will prepend these paths to the files specified by your #include directives while attempting to resolve them. These paths are not searched recursively.
This array of path strings is used by the "Tag Parser" ("browse engine"). This engine will recursively enumerate all files under the paths specified and track them as potential includes while tag parsing your project folder. To disable recursive enumeration of a path, you can append a /* to the path string.
When you open a workspace for the first time, the extension adds ${workspaceFolder} to both arrays. If this is undesirable, you can open your c_cpp_properties.json file and remove it.
Starting in version 0.12.3 of the extension, there is a command to reset your IntelliSense database. Open the Command Palette (⇧⌘P (Windows, Linux Ctrl+Shift+P)) and choose the C/C++: Reset IntelliSense Database command.
The language server caches information about included header files to improve the performance of IntelliSense. When you edit C/C++ files in your workspace folder, the language server will store cache files in the ipch folder. By default, the ipch folder is stored under the user directory. Specifically, it is stored under %LocalAppData%/Microsoft/vscode-cpptools on Windows, and for Linux and macOS it is under ~/.vscode-cpptools. By using the user directory as the default path, it will create one cache location per user for the extension. As the cache size limit is applied to a cache location, having one cache location per user will limit the disk space usage of the cache to that one folder for everyone using the default setting value.
VS Code per-workspace storage folders were not used because the location provided by VS Code is not well known and we didn't want to write GB's of files where users may not see them or know where to find them.
With this in mind, we knew that we would not be able to meet the needs of every different development environment, so we provided settings to allow you to customize the way that works best for your situation.
"C_Cpp.intelliSenseCachePath": <string>This setting allows you to set workspace or global overrides for the cache path. For example, if you want to share a single cache location for all workspace folders, open the VS Code settings, and add a User setting for IntelliSense Cache Path.
"C_Cpp.intelliSenseCacheSize": <number>This setting allows you to set a limit on the amount of caching the extension does. This is an approximation, but the extension will make a best effort to keep the cache size as close to the limit you set as possible. If you are sharing the cache location across workspaces as explained above, you can still increase/decrease the limit, but you should make sure that you add a User setting for IntelliSense Cache Size.
If you do not want to use the IntelliSense caching feature that improves the performance of IntelliSense, you can disable the feature by setting the IntelliSense Cache Size setting to 0 (or "C_Cpp.intelliSenseCacheSize": 0" in the JSON settings editor).
The debugger needs to be configured to know which executable and debugger to use:
From the main menu, select Run > Add Configuration....
The file launch.json will now be open for editing with a new configuration. The default settings will probably work except that you need to specify the program setting.
See Configure C/C++ debugging for more in-depth documentation on how to configure the debugger.
Enabling debug symbols is dependent on the type of compiler you are using. Below are some of the compilers and the compiler options necessary to enable debug symbols.
When in doubt, please check your compiler's documentation for the options necessary to include debug symbols in the output. This may be some variant of -g or --debug.
--debug option.CXXFLAGS environment variable is set. For example, export CXXFLAGS="${CXXFLAGS} --debug".CMAKE_CXX_FLAGS is set. For example, export CMAKE_CXX_FLAGS=${CXXFLAGS}.See Clang C++ but use CFLAGS instead of CXXFLAGS.
If you invoke the compiler manually, add the -g option.
Symbols are located in the *.pdb file.
When you start debugging, if your breakpoints aren't bound (solid red circle) or they are not being hit, you may need to enable debug symbols during compilation.
If your debugger is showing a grey stack trace, won't stop at a breakpoint, or the symbols in the call stack are grey, then your executable was compiled without debug symbols.
If you are experiencing a problem with the extension that we can't diagnose based on information in your issue report, we might ask you to enable logging and send us your logs. See C/C++ extension logging for how to get C/C++ extension logs.
If you have any other questions or run into any issues, please file an issue on GitHub.