<div dir="ltr">I'm unsure if it doesn't make sense, but has it been considered forking the current c++ implementation and just replacing the current parser (and even the AST) for Clang's?<div><br></div><div style>

Maybe it's easier if we do a 1:1 port...</div><div style><br></div><div style>Aleix</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 5, 2013 at 1:19 PM, Alexandre Courbot <span dir="ltr"><<a href="mailto:gnurou@gmail.com" target="_blank">gnurou@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Olivier,<br>
<div class="im"><br>
On Sat, May 4, 2013 at 6:23 PM, Olivier J. G. <<a href="mailto:olivier.jg@gmail.com">olivier.jg@gmail.com</a>> wrote:<br>
> Yes, I think the next step here is to take this to Clang with a proposal and<br>
> hash it out, because using Clang as it stands now would require ugly (and<br>
> inefficient) hacks, and wouldn't make very good use of the duchain. I also<br>
> am very interested in working on this, but I know better than to think I<br>
> could maintain it.<br>
> If Clang could just make partial translation units for single files and just<br>
> annotate the include positions, plus something like libclang's USR (which is<br>
> not directly available in the C++ API) to allow cross-referencing<br>
> cursors/decls, that would provide plenty for us to work with. Of course to<br>
> actually bring something up on the clang mailing-list will require a bit<br>
> more thought and detail. Perhaps I can return to my previous work on it so I<br>
> can refresh my memory.<br>
<br>
</div>Great, how about we (including Milian who apparently has worked on<br>
this too) come with a list of the current issues with CLang to bring<br>
to their list? So far the thing that really blocked me is the apparent<br>
impossibility to detect when to open/close a DUContext for an include<br>
file. The rest of my issues comes from my general ignorance of<br>
DUChain/KDevelop in general.<br>
<br>
Also having first tried the C++ API, I found out that switching to<br>
libclang brings some benefits (like the USRs you mentioned) and also<br>
seems to be more stable API-wise. Is there a reason why you are doing<br>
your work using the unstable C++ API?<br>
<br>
Also, just out of curiosity could you summarize what is currently<br>
working in your plugin?<br>
<br>
Looks like there is some rising interest with respect to bringing<br>
CLang parsing into KDevelop, and honestly speaking nothing could make<br>
me happier.<br>
<div class="HOEnZb"><div class="h5"><br>
Alex.<br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kde.org">KDevelop-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kdevelop-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br></div>