[LLVMdev] Proposal for GSoC project for clang front end

Chris Lattner sabre at nondot.org
Thu Mar 20 20:49:35 PDT 2008


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



More information about the llvm-dev mailing list