Clang

[Alexandre Courbot]

Hi Olivier,

On Sat, May 4, 2013 at 6:23 PM, Olivier J. G. <olivier.jg at gmail.com> wrote:
> Yes, I think the next step here is to take this to Clang with a proposal and
> hash it out, because using Clang as it stands now would require ugly (and
> inefficient) hacks, and wouldn't make very good use of the duchain. I also
> am very interested in working on this, but I know better than to think I
> could maintain it.
> If Clang could just make partial translation units for single files and just
> annotate the include positions, plus something like libclang's USR (which is
> not directly available in the C++ API) to allow cross-referencing
> cursors/decls, that would provide plenty for us to work with. Of course to
> actually bring something up on the clang mailing-list will require a bit
> more thought and detail. Perhaps I can return to my previous work on it so I
> can refresh my memory.

Great, how about we (including Milian who apparently has worked on
this too) come with a list of the current issues with CLang to bring
to their list? So far the thing that really blocked me is the apparent
impossibility to detect when to open/close a DUContext for an include
file. The rest of my issues comes from my general ignorance of
DUChain/KDevelop in general.

Also having first tried the C++ API, I found out that switching to
libclang brings some benefits (like the USRs you mentioned) and also
seems to be more stable API-wise. Is there a reason why you are doing
your work using the unstable C++ API?

Also, just out of curiosity could you summarize what is currently
working in your plugin?

Looks like there is some rising interest with respect to bringing
CLang parsing into KDevelop, and honestly speaking nothing could make
me happier.

Alex.