Fwd: Clang

[Olivier J. G.]

I think I accidentally failed to send this to KDevelop-Devel.

---------- Forwarded message ----------
From: Olivier J. G. <olivier.jg at gmail.com>
Date: Sat, May 4, 2013 at 11:23 AM
Subject: Re: Clang
To: Alexandre Courbot <gnurou at gmail.com>


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.
Of course, the next step will be to figure out Clang's codebase and provide
patches, and I haven't a clue how much time/difficulty is involved in the
changes I'm suggesting. Perhaps after real life has settled down in a
couple months, I could look into that. Clang is the only real solution
since the advent of C++11 and only more so going into the future, I think.

- Olivier JG



On Fri, May 3, 2013 at 1:53 PM, Alexandre Courbot <gnurou at gmail.com> wrote:

> On Fri, May 3, 2013 at 7:48 PM, Milian Wolff <mail at milianw.de> wrote:
> > The big problem afaik is includes and caching. Clang operates on compile
> units
> > whereas you can throw pretty much everything at KDevelop's parser and it
> > mostly does something thats kinda useful :)
>
> I did not care much about caching yet, but you are right about
> includes. That's actually the reason why my parser doesn't handle them
> yet. The switch between files is not obvious to catch.
>
> I'd say this is something that should be brought to the CLang
> community and discussed with them. If the task can be made easier by
> changing CLang a big and exposing new interfaces, I'd bet they
> wouldn't mind a few extra patches. What KDevelop does is far from
> being uncommon and could benefit other people too.
>
> In any case, if you become active on this, I'd love to follow the
> progress and contribute if time allows.
>
> Alex.
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130504/b9b37a94/attachment.html>