This tutorial shows how to diagnose IntelliSense problems for advanced VisualGDB projects (e.g. Advanced CMake, Arduino, Mbed or ESP-IDF). We will create a basic Linux project using the Advanced CMake project subsystem and will show how VisualGDB computes the header search files and other IntelliSense parameters and how to diagnose situations where the headers are not located properly or some other settings are missing.
- First, we will create a regular Advanced CMake project. Open the VisualGDB Linux Project Wizard:
- Proceed with the default settings:
- In this tutorial we will explain how VisualGDB caches remote header directories, so select “Build the project under Linux over network”:
- On the next page select “Store source files on the Windows computer”:
- Click “Finish” to generate the project. Once it is created, right-click on the “Source files” folder for the main target and select “Add->New Item”:
- Select “C/C++ Header File” and place the new file into a subdirectory (e.g. subdir):
- Include the header file from the main source file and let VisualGDB automatically suggest adding “subdir” to the header search directories, then proceed with updating the settings:
- Now we have a simple project that includes both system headers (e.g. <iostream>) from the system directories and custom headers (e.g. Header.h) from header directories specified in the settings. We will now show how exactly VisualGDB queries those directories and how to check that they are handled correctly. Open the View -> Clang IntelliSense Diagnotsics Console window and switch it to the Projects view:The Projects view displays the project structure exactly as seen by IntelliSense. The “X” symbol near the “Header.h” file means that it is not compiled directly, but is expected to be included from other files. The gear symbol near the ClangIntelliSenseDemo.cpp file means that the file has different set of IntelliSense parameters than the project defaults.
- If Clang IntelliSense cannot locate some headers, the first step to diagnose it would be to locate the corresponding source file in the Clang IntelliSense Diagnostics Console and check its build flags. The relevant flags would be -I<directory>, -isystem <directory> -include <file> and -D<macro>. E.g. in this example, the ClangIntelliSenseDemo.cpp file has the following include directories defined:
123456789-I c:\projects\temp\ClangIntelliSenseDemo\subdir-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0000\include\c++\7-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0000\include\x86_64-linux-gnu\c++\7-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0000\include\c++\7\backward-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0001\include-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0003\include-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0002\include-fixed-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0000\include\x86_64-linux-gnu-isystem <LOCALAPPDATA>\VisualGDB\RemoteSourceCache\kubuntu18vm\0000\include
Note how the system directories point to a location under %LOCALAPPDATA% where VisualGDB caches the header files from the Linux machine.
- We will now show how VisualGDB computes the include directories. Locate the CodeModel.json file in the build directory for your project (e.g. C:\projects\temp\ClangIntelliSenseDemo\VisualGDB\Debug\CodeModel.json) and locate the “fileGroups” element in it:
It will list all source files reported by CMake along with the preprocessor macros and include directories defined through CMakeLists.txt files. Note that since CMake runs on Linux, the paths will reflect the file locations on the remote Linux machine. VisualGDB will use the following logic to map them:
- If the path is inside the remote project directory, it will automatically get mapped inside the project directory on the Windows machine.
- If the path is inside one of the directories listed via VisualGDB Project Properties -> Path Mapping or Synchronized Directories, it will get mapped accordingly.
- If it is not covered by any other mapping rule, but is a part of the include directories reported by CMake, VisualGDB will automatically cache it under %LOCALAPPDATA%.
For other advanced project types (e.g. Arduino or ESP-IDF), the name and the format of the Code Model file will be different. You can find the exact file name via the View->Output->Advanced VisualGDB Project Output.
- The directories for common system headers (e.g. <iostream>) are not reported via CodeModel.json and are handled separately. VisualGDB will automatically query the GCC specified on the Build Settings page of VisualGDB Project Properties for common include directories and macros and will merge them with the information from CodeModel.json. The flags will get cached in the ImplicitCompilerFlags.xml file inside the VisualGDBCache directory (e.g. C:\projects\temp\ClangIntelliSenseDemo\VisualGDBCache\ClangIntelliSenseDemo-Debug-VisualGDB\ImplicitCompilerFlags.xml):
123456789101112131415161718192021222324252627<?xml version="1.0"?><ImplicitFlagCache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><GCC>gcc</GCC><GXX>g++</GXX><CachedFlags><Entry><Key><IsCXX>true</IsCXX><Arguments /></Key><Specs><RawIncludeDirs><string>/usr/include/c++/7</string><!-- ... --></RawIncludeDirs><ForcedIncludeFiles /><PreprocessorMacros><PreprocessorMacro><Key>__SSP_STRONG__</Key><Value>3</Value></PreprocessorMacro><!-- ... --></PreprocessorMacros></Specs></Entry></CachedFlags></ImplicitFlagCache>
You can see the details of the built-in directory and macro extraction by opening View->Other Windows->VisualGDB Diagnostics Console, deleting the ImplicitCompilerFlags.xml file and reopening the solution.
- If the directories in all the cached files and in Clang IntelliSense Diagnostics Console appear correct, but some headers are still not found, the header cache might be out of date. You can reload it via the IntelliSense Directories page of VisualGDB Project Properties: