[cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp

[Chris Lattner]

taking this to cfe-dev.

On Apr 10, 2010, at 12:23 PM, David Chisnall wrote:

> Hi Chris,
> 
> As I said on the PR, I disagree with your assessment of the correct fix - I think your proposal would introduce a lot of difficulties.  Given that this is a trivial change and does fix the problem, I'd rather leave it in for now and, if you think rewriting a large chunk of AST code to treat a single special case is the correct solution then revert it when this has been done.  If you disagree, then please revert it.
> 
> I do not know how you think that setting a flag on ObjCMessageExpr will make things simpler though.  There doesn't seem to be a bitfield on ObjCMessageExpr already, so we'd need to add a new field just to hold this one flag, which would increase the size of every ObjCMessageExpr for one special case.  Alternatively we could add a new subclass, but I'm not really sure that this would be more convenient.
> 
> It would also make it impossible if we wanted to support GCC's treatment of super in contexts other than as the receiver for messages.

To me, this is a very similar cousin to "cast of super" which we explicitly disallow.

The big issue here is that from a language perspective, "super" is not an expression at all.  It is a magic token that is only valid in a message send.  Things like super->ivar *should* be disallowed, as should "id x = super" and many other things that we probably accidentally allow.

I think that the big AST change to model this correctly is really important, because it will fix a number of other problems and cases where Sema probably accidentally accepts invalid code (what about foo(super), passing it as an argument)?  This is not about a single special case, this is about the design always being broken and wanting to fix the root problem.

Just "leaving it in" will make clang accept illegal code - weaning the invalid code off their constructs is going to be more difficult in the future than it is now.  Since clang has never accepted this, we just continue rejecting it.

-Chris