[cfe-dev] clangd/libclang: how to emulate other compilers?

[Milian Wolff via cfe-dev]

On Dienstag, 17. April 2018 22:35:00 CEST Doug Schaefer via cfe-dev wrote:
> Eclipse CDT does something similar. For each unique collection of compiler
> command line arguments (i.e. for files that build with the same options) we
> add -E -P -v -dD and call the real compiler to get the list of all include
> paths and symbols used for a given parse, including both user and built-in
> ones. Works with both clang and gcc.
> 
> For compiler specifics, we cheat and add macros that work us through the
> parse errors. You likely lose info but at least it rounds up to a pretty
> good parse.

Ah, so you also have something like this [1] which I forgot to reference in my 
initial email:

https://github.com/KDE/kdevelop/blob/master/plugins/clang/duchain/gcc_compat.h

If so, can you point me to your version of that file? If you are also using 
this approach, and it works for you, then I guess we should share resources 
and both work on a common file.

Out of interest: Have you ever tried to parse old clang headers with a CDT 
built against a newer clang?

> I'm at the very beginning of trying to figure out how we'd do something
> similar with clangd. This feature will be a must for users with embedded
> systems toolchains which are mainly based on gcc.
> 
> Doug.
> 
> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Milian
> Wolff via cfe-dev Sent: Tuesday, April 17, 2018 4:03 PM
> To: Clang Dev <cfe-dev at lists.llvm.org>
> Subject: [cfe-dev] clangd/libclang: how to emulate other compilers?
> 
> Hey all,
> 
> how does clangd or other users of the libclang handle situations where you
> want to parse code that is dependent on a certain other compiler or
> compiler environment? The most common scenario being embedded projects that
> rely on the compiler-builtin defines and include paths to find the sysroot
> include paths and such.
> 
> For KDevelop, which is using libclang, we have tried to build a sort of
> emulation layer that originally yielded good results. The approach is as
> followed:
> 
> 1) We use the actual compiler that is used to compile a given project, e.g.
> gcc, arm-none-eabi-gcc, ...
> 
> 2) We take this compiler and query it for its builtin defines:
> /usr/bin/gcc -xc++ -std=c++11 -dM -E - < /dev/null
> 
> 3) And also query the include paths:
> /usr/bin/gcc -xc++ -std=c++11 -v -E - < /dev/null
> 
> 4) Then for the libclang calls to clang_parseTranslationUnit2 we pass `-
> nostdinc -nostdinc++` followed by the defines and includes we got from 2)
> and 3).
> 
> Now, for simply things this actually worked quite well. But once you include
> a file that heavily relies on the compiler, such as all the SIMD intrinsic
> headers, you are easily drowning in parse errors. And once you have too
> many parse errors, clang will just give up. We have tried to workaround
> this via compatibility headers such as [1], but it keeps breaking.
> 
> More recently, we now also got bug reports where the user system has clang3
> and they use that to to compile the code, but then download a KDevelop
> AppImage built against libclang v5 (e.g. via AppImage). Once again this
> easily yields tons of parse errors when encountering system headers that
> are using intrinsics specific to clang v3.
> 
> I am now thinking about removing the emulation layer described above. But
> then it will be essentially impossible to work on a lot of embedded
> projects which rely on the cross compiler defines and include paths...
> 
> So, once again - how do other users of libclang handle this scenario? What
> is the plan for clangd in this regard?
> 
> Thanks
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180418/f0e95c55/attachment.sig>