<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 18, 2018 at 4:22 PM Doug Schaefer via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_8870320074644864138WordSection1">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>Manuel Klimek via cfe-dev<br>
<b>Sent:</b> Wednesday, April 18, 2018 6:26 AM<br>
<b>To:</b> Milian Wolff <<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>><br>
<b>Cc:</b> Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [cfe-dev] clangd/libclang: how to emulate other compilers?<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
<div>
<div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_8870320074644864138WordSection1"><div><div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Tue, Apr 17, 2018 at 8:02 PM Milian Wolff via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:.5in">Hey all,<br>
<br>
how does clangd or other users of the libclang handle situations where you <br>
want to parse code that is dependent on a certain other compiler or compiler <br>
environment? The most common scenario being embedded projects that rely on the <br>
compiler-builtin defines and include paths to find the sysroot include paths <br>
and such.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
</div>
</div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_8870320074644864138WordSection1"><div><div><div>
<p class="MsoNormal" style="margin-left:.5in">I'm not sure I understand what you mean - do you mean the compiler has builtins that clang doesn't provide and relies on their existence?<u></u><u></u></p>
</div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_8870320074644864138WordSection1"><div><div><div><p class="MsoNormal">Yes.<u></u><u></u></p>
</div>
<div></div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_8870320074644864138WordSection1"><div><div><div>
<p class="MsoNormal" style="margin-left:.5in">Generally, you'll want to use the builtin defines and includes from clang (at the point at which you compiled libclang), but the standard library and so forth that the system is using. Clang should be able to find
that given the right flags.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div></div></div></div></div><div lang="EN-US" link="blue" vlink="purple"><div class="m_8870320074644864138WordSection1"><div><div><div><p class="MsoNormal">Well, no. The plan for a lot of us is to use clangd with projects that use gcc as the compiler. We need to be able to reach out to gcc to ask it what the built-ins are. We’ll then need to convince clang to parse in the same manner. Given
all the variants of compilers that we need to be able to support in our various IDE’s, it’s already something we’ve gotten quite use to.</p></div></div></div></div></div></blockquote><div><br></div><div>If you want to use intrinsics where they differ between compilers, you'll still need to use clang's builtin headers, otherwise clang will incorrectly parse, well, basically anything.</div><div><br></div><div>The problem is that there is no layering; builtin headers depend on each other and compiler internals somewhat randomly.</div><div><br></div><div>We'd like to better understand examples of differences in language extensions, as clang tries really hard to emulate all the different dialects out there :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_8870320074644864138WordSection1"><div><p class="MsoNormal" style="margin-left:.5in"><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:.5in">For KDevelop, which is using libclang, we have tried to build a sort of
<br>
emulation layer that originally yielded good results. The approach is as <br>
followed:<br>
<br>
1) We use the actual compiler that is used to compile a given project, e.g. <br>
gcc, arm-none-eabi-gcc, ...<br>
<br>
2) We take this compiler and query it for its builtin defines:<br>
/usr/bin/gcc -xc++ -std=c++11 -dM -E - < /dev/null<br>
<br>
3) And also query the include paths:<br>
/usr/bin/gcc -xc++ -std=c++11 -v -E - < /dev/null<br>
<br>
4) Then for the libclang calls to clang_parseTranslationUnit2 we pass `-<br>
nostdinc -nostdinc++` followed by the defines and includes we got from 2) and <br>
3).<br>
<br>
Now, for simply things this actually worked quite well. But once you include a <br>
file that heavily relies on the compiler, such as all the SIMD intrinsic <br>
headers, you are easily drowning in parse errors. And once you have too many <br>
parse errors, clang will just give up. We have tried to workaround this via <br>
compatibility headers such as [1], but it keeps breaking.<br>
<br>
More recently, we now also got bug reports where the user system has clang3 <br>
and they use that to to compile the code, but then download a KDevelop <br>
AppImage built against libclang v5 (e.g. via AppImage). Once again this easily <br>
yields tons of parse errors when encountering system headers that are using <br>
intrinsics specific to clang v3.<br>
<br>
I am now thinking about removing the emulation layer described above. But then <br>
it will be essentially impossible to work on a lot of embedded projects which <br>
rely on the cross compiler defines and include paths...<br>
<br>
So, once again - how do other users of libclang handle this scenario? What is <br>
the plan for clangd in this regard?<br>
<br>
Thanks<br>
-- <br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><u></u><u></u></p>
</blockquote>
</div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>