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


More information about the llvm-dev mailing list