[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