llvm dev - Apr 2008 - [LLVMdev] Proposal for GSoC project for clang front end

Hi all,

I'd like to hear your opinions and ideas for a proposal to improve 
support for C++ parsing for LLVM's clang front end.

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).

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.

Is LLVM interested in accepting such a proposal ?
If yes, can you offer me hints on what is the best way to describe such 
a proposal (I mean, should I make a list about
each and every specific C++ feature that the parser should be able to 
handle ?)

Any thoughts about the subject will be greatly appreciated.

About me:
I'm an undergraduate student of electrical engineering in Democritus 
University of Greece (http://www.ee.duth.gr).
I've been a user, contributor, and project leader, of various 
open-source projects over the years.
I've gained some experience in C++ parsing when I developed an automatic 
wrapper for Ogre3D (http://www.ogre3d.org),
that produces bindings for the CLR (http://sourceforge.net/projects/mogre).

I think that LLVM+clang is the future of C++ development, and I'd be 
really happy to make a useful contribution to this
great project :).


-Argiris Kirtzidis

On 3/19/08, Argiris Kirtzidis <akyrtzi at gmail.com>
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.
>
>  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).
>
>  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.
>
>  Is LLVM interested in accepting such a proposal ?
>  If yes, can you offer me hints on what is the best way to describe such
>  a proposal (I mean, should I make a list about
>  each and every specific C++ feature that the parser should be able to
>  handle ?)
>
>  Any thoughts about the subject will be greatly appreciated.
>
I'm also quite interested in improving the clang front-end: there are
too many projects in dire need of a good C/C++ parser (like
Code::Blocks or Eclipse's CDT for instance). However, I will have to
admit that I'm not very experienced with creating parsers for
programming languages (though I'm quite proficient with C++).

In any case, I could probably take on a less daunting task like
writing the documentation for clang (right now, the documentation is
very, very....lacking), helping another participant (not too sure how
to work it out though) or fixing some TODOs in the clang code (like
providing a better alternative for the hard-coded include paths).

Before I forget my introductions, I'm an undergrad of Computer Science
and Math from Ateneo de Manila University (http://www.admu.edu.ph/) in
the Philippines.

-- 
Life is too short for dial-up.

Am Donnerstag, den 20.03.2008, 02:16 +0800 schrieb Wilhansen
Li:
> I'm also quite interested in improving the clang front-end: there are
> too many projects in dire need of a good C/C++ parser (like
> Code::Blocks or Eclipse's CDT for instance).
Yes, and C++ is one of the worst parsing nightmares that exist. Prepare
to maintain your code for years to come, or consider it a throwaway
project.

Does anybody know what the status of gcc-xml relative to clang is?
(gcc-xml is reworking the g++ parser to emit XML. It's not complete, but
it should fit the needs of Code::Blocks or CDT nicely once it's done.)

Regards,
Jo

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 ?
Yes!

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Thanks for your feedback Chris,

Chris Lattner wrote:
> 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 :)
Ok, adding basic class support sounds great. It will include:

1) declaring methods, nested classes, enumerations and typedefs. (nested 
types will be accessible
    only by class methods, unless class scope resolution is implemented; 
see below)
2) member access control ("public:" etc)
3) calling instance methods.
> int foo::test2(q r) {
>    return X+r;
> }
This is actually quite tricky, because clang currently assumes that a 
declaration can be "found"
only by using an identifier (support for '::' in "foo::test2"
needed),
and for name lookup it
assumes that the declaration is accessible at the current scope or at an 
enclosing scope of the
current one (support for resolving X in "return X+r;" needed).

So either a kind of "hack" would be employed to get correct parsing
for
this situation only,
or "proper" C++ name lookup would be developed to also accommodate 
access to class nested types
and static members. Personally I'd prefer the latter, but I'd like to 
hear your opinion whether
[1) - 3)] plus "C++ name lookup" is a reasonable amount of work for
the
summer or something
should be dropped or simplified.


-Argiris

On Wednesday 19 March 2008 21:27:18 Chris Lattner wrote:
> 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.
You could surely save a lot of time reinventing the wheel by reusing an 
existing C++ parser, like Elsa:

  http://www.cs.berkeley.edu/~smcpeak/elkhound/

There are even OCaml bindings:

  http://www.cs.ru.nl/~tews/olmar/

These libraries were discussed on the OCaml mailing list recently:

  http://groups.google.com/group/fa.caml/msg/dd7dad5533647220

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e