http://llvm.org/bugs/show_bug.cgi?id=6811
David Chisnall <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #2 from David Chisnall <[email protected]> 2010-04-10 14:15:43 CDT --- I'm not sure that I agree. Super is magic - there are no expressions that evaluate to super, just the token itself inside 0 or more parentheses. You can't ever get super as the result of a message send, for example. You can't do pointer arithmetic with super. The only thing you can do with it is send messages to it. I don't see how we'd fit it into a message expr, because it's an attribute of the receiver, rather than an attribute of the message expression, so having the flag in the message expression would not really make sense. You'd have to have a flag on all expressions that told you if it evaluated to super, but it would only ever be true in two cases: when the token is super or when the token is a ParenExpr containing the super token. It turns out that the fix for this is trivial - just add ->IgnoreParens() when testing whether the receiver is super. It actually took less time to fix than file the bug report - I should probably do these things in the opposite order... Fixed in r100942. By the way, gcc accepts super as being equivalent to self in every situation other than message sending, so you can do things like super->isa. This fails in the parser in clang. I don't really object to this, because it's a stupid thing to be doing and has non-obvious semantics (e.g. you can do super->foo where foo is defined in the current class). -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
