[cfe-dev] clang leveraging Elsa?

[Chris Lattner]

>> It is somewhat irritating to me that there is almost no comments
>> for this: it seems well thought out and written. Is there any out
>> of line documentation available?
>
> Asking around there doesn't seem to be any that I could find.   
> Sorry :(

Ok.

>> Overall, it is an impressive piece of work.  There are some minor
>> strange (to me) design decisions: for example, what is
>> ConditionAST, why does it exist?
>
> Sorry I am not that familiar with the design choice, I have forwarded
> this to Roberto who will hopefully respond shortly with answers to it
> and the other ones below.

Thanks,

>> The ASTs produced seem to be a bit heavier-weight than the clang
>> ASTs, and relies on the entire lexed token stream being available
>> to interpret the location info.  However, in my first few minutes
>> looking at it, I don't think that it shares the "fatal flaws" (from
>> the clang perspective only, obviously) in its design or
>> implementation that elsa has.  As a matter of fact, while the
>> details differ significantly, its design is somewhat similar to
>> clangs, validating clang's design ;-).  One thing that is
>> impossible for me to do from inspection is to determine how
>> complete the parser is.
>>
>> Since I don't have it built and you do, here are some questions for
>> you: :)
>
> Having it sitting in the middle of other packages is getting
> annoying.  I have pulled it out and made a quick (and very dirty)
> example app that can be used to generate preprocessed files (./
> example -E file) put it in a git depot and put it up online
>
> http://repo.or.cz/w/rpp.git

Nice, it's easy to get a tarball from it, unfortunately I don't have  
qmake.

>> 1) looking at the preprocessor, the implementation doesn't look
>> particularly speedy.  It is using std::strings to push text
>> around.  Have you timed the preprocessor on large inputs to see how
>> fast it really is?
>
> Did a quick (not scientific) test against gcc on my macbook it is
> almost twice the speed
>
> g++
> real    0m0.437s
> user    0m0.243s
> sys     0m0.060s
>
> rpp
> real    0m0.248s
> user    0m0.197s
> sys     0m0.070s

User+sys it is only 13% faster.  Still this is impressive :)

>> 5) it looks like a lot of semantic checks are missing.  Is there
>> anything that talks about the current state of the parser?  It also
>> reads and ignores lots of stuff, even simple things like break/
>> continue/goto stmts.
>
> I know that there are several groups (kdevelop is one group) who wish
> to use it to parse c++ code beyond Qt so it will be maintained and
> improved.  I don't know their plans though.  Sorry I can't be more  
> help.

No problem, I'll delve more into the code.  It looks like it is  
designed and optimized for use by kdevelop, so it hasn't focused much  
on type analysis and other things that a front-end needs for full  
diagnostics and code generation.  However, it has a pretty nice  
design and is simple, so it's a good source of inspiration.

Now we just need someone to help push C++ support forward! :)

-Chris