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

[Milian Wolff via cfe-dev]

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
-------------- 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/20180417/9c8a764a/attachment.sig>