[LLVMdev] Proposal for GSoC project for clang front end

Chris Lattner sabre at nondot.org
Wed Mar 19 14:27:18 PDT 2008

On Wed, 19 Mar 2008, Argiris Kirtzidis wrote:
> I'd like to hear your opinions and ideas for a proposal to improve
> support for C++ parsing for LLVM's clang front end.

Some meta feedback: C++ support in clang is a huge project, far and away 
more than any mortal can get done in a summer.  While it would be possible 
to sketch out the parser itself in the summer (providing the equivalent of 
-parse-noop for C) this won't be able to handle a lot of interesting 
cases.  C++ requires a significant amount of semantic analysis just to get 
parsing correct.

> Goal:
> Improve clang's C++ support. The scope of the project will be limited to
> C++ parsing, not code generation (I think the
> timeframe of a GSoC project and the complexity of C++ doesn't allow full
> C++ support to be developed).

Ok, remember that parsing is only one piece of the puzzle.  We also have 
semantic analysis/typechecking/ASTBuilding as well.  I think that focusing 
on -fsyntax-only is a good place to be.

> C++ parsing support includes (but is not limited to):
> -Namespace declarations, using directives.
> -Class declarations, class members, methods etc.
> -Overload method/function matching.
> -C++ name lookup rules, scope resolution.
> -Class/function templates.

Ok, pick one or maybe two of these.  I think it would be much better to 
have namespaces fully implemented than have everything sorta implemented.

If I were going to pick, I would suggest focusing on getting simple 
methods implemented, along with instance variables, etc through 
-fsyntax-only.  This should be a reasonable amount of work for a summer. 
Something like this should work for example:

class foo {
   int X;
   typedef float Z;
   int test(Z a) { return a+X; }
   int test2(q r);
   tyepdef float q;

int foo::test2(q r) {
   return X+r;

No overloading, not templates, but handling the basic "class issues". 
Static methods would be a bonus :)

> Is LLVM interested in accepting such a proposal ?




More information about the llvm-dev mailing list