Add support for compile commands json

[agauniyal]

Feature Request - Most of the build systems nowadays have support for generating compilation database file, vscode cpp plugin should also support it. For more information - http://clang.llvm.org/docs/JSONCompilationDatabase.html

[teki]

@sean-mcmanus Managed to figure out what is probably the issue. It is very likely -I. is not handled properly. That should insert the content of "directory" from the compile_commands.json entry into the include path list.

[teki]

Btw, I had to disable the plugin for now. It takes days to parse all the files and that is a no go when I am on battery. I will wait till go to definition switches to the new engine, that should help avoiding the excessive parsing.

[rohitp93]

When can we expect GoTo definition functionality with the compile commands json? It would be a good feature to just specify the compile_commands.json file path and then be able to navigate between headers and source files based on the inlcudes given in the compile_commands.json for that particular source file.

[db4]

This feature as does not work for me for version 0.14.2:

"...\compile_commands.json" could not be parsed. Using 'includePath' settings in c_cpp_properties.json.

compile_commands.json is generated by cmake 3.9.4. It exists and at first glance is correct.

Any idea what could be wrong? Can I see/enable some debugging output from cpptools to figure out a problem?

[MathiasMagnus]

It seems Code 1.18 introduced workspaceFolder instead of workspaceRoot, and thus the extension looks for this file through a non-existing helper var. Problem is, the extension might not even find c_cpp_properties.json, so you might not be able to instruct it otherwise either. You can try though.

[db4]

No, that's what I checked first. If the file does not exist, the error message would be

"...\compile_commands.json" could not be found. Using 'includePath' settings in c_cpp_properties.json"

[bobbrow]

Can you please open a new issue for this and provide some information about your workspace and c_cpp_properties.json file? You can try trimming out all but one entry in the compile commands file to see if a simple case still works for you (which is easier to validate).

${workspaceRoot} is still a valid variable. The language server continues to respect it.

[g-arjones]

Is there a way to set a default "compileCommands" in the user's settings file? All of my projects have the same relative path (e.g ${workspaceRoot}/build/compile_commands.json) and I feel that I should not have to set the same thing for all of them.. Thanks!

[bobbrow]

We are considering moving c_cpp_properties.json into settings.json at which point this will be possible.

[g-arjones]

Great! Do you suggest any workaround in the meantime?

[bobbrow]

Unfortunately there is no workaround at this time.

[g-arjones]

No problem, thank you :)

[loaden]

It's seems broken now. VSCode:1.21.1, CppTools:0.15.0

[sean-mcmanus]

@loaden https://github.com/Microsoft/vscode-cpptools/releases/tag/v0.16.0-insiders2 has a workaround for some issues, such as querying the system defines and enabling a separate compilerPath to be set if the first arg in the compile_commands.json command isn't a compiler.

[loaden]

@sean-mcmanus thans for the tip. I've upgraded to 0.16-insiders2 now, but still can not get any help. I thought paste my json part in here and hope the solved way.

{
            "name": "Win32",
            "includePath": [
                "${workspaceFolder}"
            ],
            "defines": [
                "_DEBUG",
                "UNICODE",
                "_UNICODE"
            ],
            "compileCommands": "${workspaceFolder}/build/compile_commands.json",
            "intelliSenseMode": "clang-x64",
            "browse": {
                "path": [
                    "${workspaceFolder}"
                ],
                "limitSymbolsToIncludedHeaders": true,
                "databaseFilename": ""
            },
            "compilerPath": "",
            "cStandard": "c11",
            "cppStandard": "c++17"
        }

any the compile_commands.json

[
{
  "directory": "d:/qpsoft/projects/test/build",
  "command": "D:\\Office2016\\VSCode\\VSCode_64-bit\\MinGW\\bin\\g++.exe    -g   -o CMakeFiles\\Test.dir\\test.cpp.obj -c D:\\qpSOFT\\Projects\\Test\\test.cpp",
  "file": "D:/qpSOFT/Projects/Test/test.cpp"
}
]

[sean-mcmanus]

@loaden 0.16.0 is released, but it looks like we have a bug and compilerPath needs to be set on Windows or it'll use the Windows includes/defines instead of the one in the compiler_commands.json. Does setting the compilerPath fix the issue for you?

[loaden]

@sean-mcmanus yes, it's fix the issue after set compilerPath like this, and must be absolute path. only 'g++.exe' does not work. "compilerPath": "D:/qpSOFT/VSCode/VSCode_64-bit/MinGW/bin/g++.exe",

[defunctzombie]

@sean-mcmanus A feature that would be immensely useful as a user of the compile commands feature is a way to inspect what the intellisense system "thinks" of the compile_commands.json file. For starters this would surface whether the file has any syntax violations (or other blockers to parsing), it could also include ways to query or discover the learned include paths and settings. Right now; when this feature does not work I find it a bit of a black box to figure out why.

[sean-mcmanus]

@defunctzombie Setting loggingLevel to "6" will show the end result of the settings we pass to our IntelliSense processes, but on Linux/Mac there's a race condition deadlock that can occur if a child process is forked while another thread is logging, so it's recommended to reduce the logging after you're done with it. Is that sufficient to diagnose what is going wrong? We'll consider adding a better diagnostics system later and adding more logging when errors occur. We expect compile_commands.json to be generated by a tool and to be syntax error free...are you hand generating it?

[defunctzombie]

We expect compile_commands.json to be generated by a tool and to be syntax error free...are you hand generating it?

No, autogenerated, but sometimes tools have errors too :)

[defunctzombie]

@sean-mcmanus Thanks; Ill try that next time I encounter an issue. What would be helpful is to see the information (include paths, etc) on a per file basis (maybe the logging level will do that).

[juxeii]

Sorry to say, but for us VSC is still a no go when include paths are not found via cmake. We will eventually come back to this otherwise nice editor, but in the meantime go with other competitors.

[sean-mcmanus]

@juxeii Do you mean you're having problems when files are not found in compile_commands.json and it falls back to using the includePath? Do you believe we have a bug in that scenario? We might need more repro details.

[MathiasMagnus]

@juexii I have been using VSC as my primary C++ dev platform for a few months now and it does resolve include paths when used with CMake Tools. What's not working?

[juxeii]

First, we have a huge code and complex code base. With a competitor tool, we can just open the folder with CMakeLists.txt and after a while everything is indexed and found. With VSC its not so easy. You have to install CMake Tools and CMake Tools Helper at first glance. But for us it was not clear if CMake Tools Helper is even working a promised. So we took the route with setting the path to _compilecommands.json. After some waiting time for Intellisense, almost no errors were reported on the #include statements. Everything under the projects working directory is found and we can jump to these files. The problems start with files which are outside of the actual project and are all over the place on the server file system. The include paths for these are all listed in the _compilecommands.json file, so they should be indexed too by VSC? Problem is we cannot jump/open the files with F12, VSC keeps saying "no definition found"(or similar). As an artificial example:

#include <Blah.h>
SomeType var;

Here, Blah.h is a file which is not under the project root folder; it resides somewhere on the file system. VSC does not underline this include statement, yet when trying to jump to the file with F12 it says no definition found. Strangely enough, the type SomeType is defined only in Blah.h and when hovering over it VSC shows a little window with the actual typedef definition. So clearly, VSC has somehow parsed Blah.h, but it just won't jump to it. Is it because it is an *.h file? Is it because it is an include with "<" bracket type? Is it because it is not under the project root path?

With our complex project setup I cannot provide a simple example. Is there some kind of logging mechanism where we can see whats really going on? We also noticed that each time we start VSC the indexing takes the same amount of time. With our huge codebase this gets really in the way of productivity(competitor tool builds some kind of cache here). These are all pain points and we agreed that we should give VSC another try next year. Personally, I think VSC is a great editor :)

[bobbrow]

Got it. Yes, we know this scenario doesn't currently work right now. The code navigation stuff is controlled by the "browse.path" setting in your c_cpp_properties.json file. There's an issue open to automatically add the include paths from the compile_commands.json file to this setting for you, but we haven't implemented that yet (#1715). I recommend you go upvote that one.

Are there any other blockers for you?

[sean-mcmanus]

@juxeii Setting the browse.path is expected to be relatively easy to set manually because it's recursive, so you should only need to supply the roots of your projects. What do you mean by "indexing takes the same amount of time"? We have a database that stores the parsed symbol info, and we just scan the directories for newer files on startup, which should be fast. What does the database icon in the bottom right say when you hover? You can enable more logging using the hidden values of "6" or "7" (but 7 is for symbol parsing info, which may spew a lot and slow things down).

[juxeii]

@sean-mcmanus , @bobbrow Thanks for the information on #1715, I will upvote that one. I havent really looked into it, but colleages complainted about that indexing takes always the same amount of time, no matter if the project was already indexed before. We would expect that after a restart of VSC(after indexing) the experienced workflow is much faster. Anyway, we will wait and see what's the situation after #1715 has been resolved.

[sean-mcmanus]

@juxeii Yes, "indexing" is supposed to be faster after the database been built, unless something is causing the database to be corrupted/reset. With the large open source chromium repo with 500k files, the scanning time on reopen is around 20 seconds.

It's possible you're experiencing a delay from the red flame on file open (IntelliSense updating), which is not cached.

[juxeii]

As a remark: for VSC to be a good editor for CMake projects it would be helpful to have a look at how CLion does this. You just open a folder with CMakeLists.txt and the rest is done automatically. There is no need to fiddle around with _compilecommands.json. I would expect a similar approach for VSC, where new users just open the project and experienced ones can do all kind of complicated settings at their will.

[jhasse]

Not everyone is using VS Code with CMake though.

[MathiasMagnus]

@juxeii CLion is a nice experience, but it has it's downsides. The fact that it can author the scripts for you is OK, the fact that it will write into your scripts (or that you are allowed to write into generated stuff, depends on the POV) is not a smart choice. Also, it still does not have CMake server support AFAIK. (Correct me if I'm wrong, I checked it out ~1 year ago.)

That being said, big brother Visual Studio provides you with just what you wrote and even more. It's by far the best CMake experience out there. (xplat squigglies, build locally inside WSL, etc.) If only I were able to template the default CMakeSettings.json, I'd never look back if it comes to solo C++ development. VS Code is useful when there are many languages involved. C++, PowerShell, Python, LaTeX… unfortunately, these do not integrate well. The promoted LaTeX extension is not CMake aware and compile_commands.json does not export custom commands, so… the fact that VS Code allows me to setup the default values to some of the c_cpp_properties.json saves me a lot of time. Setup and forget.

Until WG15 doesn't come up with something better, most of C++ developers are stuck with CMake. Hand authoring tasks.json for every homework handed in to me is not an option for me. It's sure good for people who work on one project for 2 months, but I open 5-10 projects every day, and they all have CMakeLists.txt. I want want to do exactly what @juexii said. Setup once and forget. VS Code is close, but some stuff are still missing. The lack of code navigation in user includes is the biggest pain.