Chris Lattner wrote: > On Oct 1, 2007, at 1:00 PM, Taras Glek wrote: >> I just found out about clang from the LLVM 2.1 announcement. It's great >> to see someone working on a C++ front-end with an emphasis on >> source2source and static analysis. I've been writing tools for that >> using the Elsa frontend for the past year. > > Nifty! > >> Elsa is further along in development (fairly complete in that it can >> parse most of the C/C++ code that gcc3.4 accepts). Have the clang >> developers considered reusing parts of the elsa? I haven't noticed a >> mention of elsa in the list archives. > > We have. The killer problem is that Elsa's implementation will not > allow us to achieve the performance goals of the clang project. In > addition, Elsa doesn't solve the hard part of C++ parsing (the > semantic analysis and type checking), isn't built as a reusable > library (in the way clang aims to be), doesn't get the corner cases of > the languages it parses correct, etc. Actually, it does do semantic analysis and type checking.
Could you elaborate on what you mean by "isn't built as a reusable library"? API-wise I think it's ok in that regard. I'm also not sure about what you mean by corner cases. Elsa's C support isn't ideal because it pretends that C is a subset of C++. And if by corner cases you mean that it doesn't always store everything it parsed in in the AST, that's also correct. However I've found that filling in missing information is next to trivial and I am not aware of any other shortcomings. Could you elaborate on that point too? > > While we could extend Elsa to complete its support for C++ and polish > the corner cases, fixing the performance issues would require a > complete redesign. As such, reusing elsa is a non-starter. :( Elsa's support for C++ is fairly complete. In my view, templates are the only crucial part that needs work. It fails on anything beyond simple template instantiation(lucky for me it's barely enough for Mozilla). However, template support is a hard part that will have to dealt with in any C++ frontend. Elsa was also designed with a performance in mind (but I agree that the authors could've done much better). An annoying part of elsa is hand-rolled data structures(one named string!), so I've been considering doing some sort of refactoring to get rid or change some of the obscure data structures. The type system also needs slight redoing . Perhaps we could redo it in clang's image. >> Elsa comes with an extensive testsuite and has some design similarities >> to clang as described in the clang Internals manual. > > When we get that far, I expect clang to extensively leverage the > available test suites, including the GCC test suite, elsa, as well as > just building tons of open source software. > >> I am very interested in clang since it will be a C/C++/ObjC frontend >> that's suitable for source analysis that also serves as a frontend to a >> production compiler. >> My biggest gripe with Elsa is that isn't developed in a transparent >> fashion. It also occasionally has bugs that would be caught if it were >> used as a frontend for a compiler. > > clang is definitely developed in the open and welcomes contributors. > However, our C++ support is basically non-existent (and we don't have > anyone really working on it), so Elsa is probably a better solution to > C++ parsing issues in the short term. Over the next couple years, I > expect the clang C++ support to come up to the point where it is both > industrial quality and useful for a broad variety of clients. It also > has much better ObjC support than elsa ;-) We have been discussing adding ObjC++ to elsa :) Me and a number of other people would like an actively maintained C++ frontend suitable for analysis and source2source. GCC isn't an option, neither is waiting on someone to write another frontend from scratch since that take another half a decade. It would be nice if useful parts of elsa were absourbed by clang so I wouldn't have to play catch up with real compilers. What would you need done to elsa to consider using it in clang? Perhaps it could serve as a stopgap measure while the faster clang C++ frontend matures. Taras _______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
