Skip to content
  1. Mar 17, 2011
  2. Mar 16, 2011
  3. Mar 14, 2011
  4. Mar 13, 2011
  5. Mar 08, 2011
  6. Mar 01, 2011
  7. Feb 28, 2011
  8. Feb 23, 2011
  9. Feb 17, 2011
  10. Feb 16, 2011
  11. Feb 10, 2011
  12. Jan 25, 2011
  13. Dec 23, 2010
  14. Dec 22, 2010
  15. Dec 20, 2010
  16. Dec 02, 2010
  17. Dec 01, 2010
  18. Oct 22, 2010
  19. Oct 21, 2010
  20. Aug 15, 2010
  21. Aug 11, 2010
  22. Jul 06, 2010
  23. May 17, 2010
  24. Apr 21, 2010
    • Douglas Gregor's avatar
      Overhaul the AST representation of Objective-C message send · 9a129194
      Douglas Gregor authored
      expressions, to improve source-location information, clarify the
      actual receiver of the message, and pave the way for proper C++
      support. The ObjCMessageExpr node represents four different kinds of
      message sends in a single AST node:
      
        1) Send to a object instance described by an expression (e.g., [x method:5])
        2) Send to a class described by the class name (e.g., [NSString method:5])
        3) Send to a superclass class (e.g, [super method:5] in class method)
        4) Send to a superclass instance (e.g., [super method:5] in instance method)
      
      Previously these four cases where tangled together. Now, they have
      more distinct representations. Specific changes:
      
        1) Unchanged; the object instance is represented by an Expr*.
      
        2) Previously stored the ObjCInterfaceDecl* referring to the class
        receiving the message. Now stores a TypeSourceInfo* so that we know
        how the class was spelled. This both maintains typedef information
        and opens the door for more complicated C++ types (e.g., dependent
        types). There was an alternative, unused representation of these
        sends by naming the class via an IdentifierInfo *. In practice, we
        either had an ObjCInterfaceDecl *, from which we would get the
        IdentifierInfo *, or we fell into the case below...
      
        3) Previously represented by a class message whose IdentifierInfo *
        referred to "super". Sema and CodeGen would use isStr("super") to
        determine if they had a send to super. Now represented as a
        "class super" send, where we have both the location of the "super"
        keyword and the ObjCInterfaceDecl* of the superclass we're
        targetting (statically).
      
        4) Previously represented by an instance message whose receiver is a
        an ObjCSuperExpr, which Sema and CodeGen would check for via
        isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
        where we have both the location of the "super" keyword and the
        ObjCInterfaceDecl* of the superclass we're targetting
        (statically). Note that ObjCSuperExpr only has one remaining use in
        the AST, which is for "super.prop" references.
      
      The new representation of ObjCMessageExpr is 2 pointers smaller than
      the old one, since it combines more storage. It also eliminates a leak
      when we loaded message-send expressions from a precompiled header. The
      representation also feels much cleaner to me; comments welcome!
      
      This patch attempts to maintain the same semantics we previously had
      with Objective-C message sends. In several places, there are massive
      changes that boil down to simply replacing a nested-if structure such
      as:
      
        if (message has a receiver expression) {
          // instance message
          if (isa<ObjCSuperExpr>(...)) {
           // send to super
          } else {
           // send to an object
         }
        } else {
          // class message
          if (name->isStr("super")) {
            // class send to super
          } else {
            // send to class
          }
        }
      
      with a switch
      
        switch (E->getReceiverKind()) {
        case ObjCMessageExpr::SuperInstance: ...
        case ObjCMessageExpr::Instance: ...
        case ObjCMessageExpr::SuperClass: ...
        case ObjCMessageExpr::Class:...
        }
      
      There are quite a few places (particularly in the checkers) where
      send-to-super is effectively ignored. I've placed FIXMEs in most of
      them, and attempted to address send-to-super in a reasonable way. This
      could use some review.
      
      llvm-svn: 101972
      9a129194
  25. Mar 27, 2010
  26. Feb 08, 2010
Loading