Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
x/tools/gopls: support something like `compile_commands.json` #36995
Build systems such as CMake and Ninja can output a compilation database -- a
Bear intercepts process forking/creation to get the
The nice thing about
Is there any way that
Note: this could also be a good "source-of-truth" and useful for cross-checking other ways of getting the project model. I.e. log the actual invocations of the go compiler to build a project model; we should get the same project model when obtained via other means, like when relying on the standard GOPATH directory structure.
Note: the compilation database /
I don't think this is feasible in the current architecture. We use the output of
To clarify, the compile_commands.json file contains entries like this:
Thus it is more than just a list of files. It is all information needed for full semantic analysis of all code that was compiled. For go, perhaps it would contain entries made up of things like the following:
From there, I assume it would be possible to derive further information that exactly matches the way the files were built by the build system.
In reality, our team is using Bazel :-) So eventually, I am sure gopls will work. My fear though is that there are other build systems. And that, even for Bazel, there may be quirks (like updates to Bazel, build system hacks, weird edge cases, etc.) that cause the support to be imperfect. In contrast, the above approach (in theory) cannot fail; the tool (e.g. clangd or gopls) has exactly the same information as the compiler. By definition, it cannot be missing any information or have the wrong information.
Yes, perhaps it would be possible to make a driver that reads a "compile_commands-like" file (for all go files that were compiled) and returns the relevant JSON. This issue was mainly just to ask whether the team has considered relying (directly or indirectly) on the actual compilation commands executed, and whether this seems like it may have advantages over relying on a driver for each build system? Could these drivers get details incorrect? Etc.