[clangd-dev] Supporting gcc environments with clangd

[Doug Schaefer via clangd-dev]

On Thu, 2019-01-10 at 18:12 +0100, Ilya Biryukov wrote:
Hi Doug,

I'm pretty new to the LLVM project so I'm not sure how best to proceed.

Welcome! Happy to have you on board!

We are working on using clangd in the Eclipse CDT context (which is now also building VS Code extensions) where we mainly support developers building embedded systems. Most of these systems use gcc as the compiler and where clang does not have target support.
I've been able to get clangd to properly deal with these projects by forking llmv and clang and adding Triples and Toolchains to properly set up the system include paths and built-in macros and other properties clang needs to parse.

I also have a hack in the clangd layer to figure out the '-target' argument from the gcc command and inject it when fetching from the compilation database. This part is especially ugly and I'm hoping to find a better way.

How do you figure it out currently? If the fork is public, could you provide the pointers to the code? My initial intuition is that it would make sense for this to live somewhere in the Tooling library (which defines abstractions for compile_commands.json), would also enable things like clang-tidy for those use-cases.

Basically, I call out to the compiler with the -v option and scan for the Target: line and use that. In theory this could also be done by whatever tool generates the compile_commands.json file or an external tool that can massage it, or something in the Tooling library as you mention.

The tricky part is knowing that the compile is gcc and not doing this in other contexts. That's why making this closer to client doing the build makes some sense.


The main question I have: is there appetite for changes like this to be pushed upstream, even though these targets are not meant to be used by clang itself? Or is a fork the proper way to deal with this? Is there anyone else doing something similar?

+via cfe-dev<mailto:cfe-dev at lists.llvm.org> for figuring out whether it's fine to have targets supported only in the frontend without the prospect of them being implemented in the backend.
From the clangd's standpoint (and more generally, from other source-level tools like clang-tidy, etc.) this would make total sense: if clang can run for some targets only with `-fsyntax-only` (producing an error in the modes that need the codegen), all the source-level tools can still be used there.

+1. That's why I'm wondering if this has come up before. These are all valuable tools that in theory could work for all C/C++ environments.

I'll work on cleaning up the code and pushing it to github so people can see what I'm talking about.

Thanks!
Doug.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/clangd-dev/attachments/20190111/abc2c548/attachment-0001.html>