Proposal for GSoC project for clang front end

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal for GSoC project for clang front end

Argyrios Kyrtzidis-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Wilhansen Li-2
On 3/19/08, Argiris Kirtzidis <[hidden email]> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Joachim Durchholz

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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Chris Lattner
In reply to this post by Argyrios Kyrtzidis-2
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Argyrios Kyrtzidis-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Chris Lattner
>> 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)

Note that 'test' exercises a cute detail of C++: inline methods cannot  
be parsed until the whole class is processed.  You need to analyze the  
q typedef before you can parse the body of test.

This should be straight-forward to handle in clang, please discuss on  
cfe-dev when it becomes time.


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

It's not that bad, we already handle it for instance variables in ObjC.

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

I'd stick with the minimal amount of name lookup to get classes  
themselves working.  instance variables are included, but not  
overloading or anything tricky.

-Chris
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Jon Harrop
In reply to this post by Chris Lattner
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Chris Lattner
On Wed, 2 Apr 2008, Jon Harrop wrote:
>> 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/

Please see:
http://clang.llvm.org/comparison.html

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Proposal for GSoC project for clang front end

Tanya Lattner-2
In reply to this post by Jon Harrop

>> 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:

Well thats a matter of opinion. Regardless, this is GSoC ideas for
LLVM/clang and doesn't have anything to do with Elsa.

-Tanya
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev