Skip to content
  1. Apr 08, 2009
  2. Mar 29, 2009
    • Chris Lattner's avatar
      Push DeclGroup much farther throughout the compiler. Now the various · 5bbb3c8a
      Chris Lattner authored
      productions (except the already broken ObjC cases like @class X,Y;) in 
      the parser that can produce more than one Decl return a DeclGroup instead
      of a Decl, etc.
      
      This allows elimination of the Decl::NextDeclarator field, and exposes
      various clients that should look at all decls in a group, but which were
      only looking at one (such as the dumper, printer, etc).  These have been
      fixed.
      
      Still TODO:
      
      1) there are some FIXME's in the code about potentially using
      DeclGroup for better location info.
      2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
      3) I'm not sure what is going on with StmtIterator.cpp, or if it can
         be radically simplified now.
      4) I put a truly horrible hack in ParseTemplate.cpp.
      
      I plan to bring up #3/4 on the mailing list, but don't plan to tackle
      #1/2 in the short term.
      
      llvm-svn: 68002
      5bbb3c8a
  3. Mar 28, 2009
    • Chris Lattner's avatar
      Introduce a new OpaquePtr<N> struct type, which is a simple POD wrapper for a · 83f095cc
      Chris Lattner authored
      pointer.  Its purpose in life is to be a glorified void*, but which does not
      implicitly convert to void* or other OpaquePtr's with a different UID.
      
      Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>.  Change the 
      entire parser/sema interface to use DeclPtrTy instead of DeclTy*.  This
      makes the C++ compiler enforce that these aren't convertible to other opaque
      types.
      
      We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
      but I don't plan to do that in the short term.
      
      The one outstanding known problem with this patch is that we lose the 
      bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
      bitmangle the success bit into the low bit of DeclPtrTy.  I will rectify
      this with a subsequent patch.
      
      llvm-svn: 67952
      83f095cc
  4. Mar 18, 2009
  5. Mar 12, 2009
  6. Mar 10, 2009
  7. Mar 09, 2009
  8. Mar 05, 2009
  9. Mar 04, 2009
  10. Mar 03, 2009
  11. Mar 02, 2009
  12. Feb 28, 2009
  13. Feb 18, 2009
  14. Feb 15, 2009
  15. Feb 14, 2009
  16. Feb 11, 2009
  17. Feb 05, 2009
    • Sebastian Redl's avatar
      Put the invalid flag of OwningResult into the Action pointer. · 726a0d95
      Sebastian Redl authored
      This shrinks OwningResult by one pointer. Since it is no longer larger than OwningPtr, merge the two.
      This leads to simpler client code and speeds up my benchmark by 2.7%.
      For some reason, this exposes a previously hidden bug, causing a regression in SemaCXX/condition.cpp.
      
      llvm-svn: 63867
      726a0d95
  18. Jan 29, 2009
  19. Jan 27, 2009
  20. Jan 18, 2009
  21. Jan 12, 2009
  22. Jan 09, 2009
  23. Jan 08, 2009
    • Douglas Gregor's avatar
      Unify the code for defining tags in C and C++, so that we always · 82ac25e4
      Douglas Gregor authored
      introduce a Scope for the body of a tag. This reduces the number of
      semantic differences between C and C++ structs and unions, and will
      help with other features (e.g., anonymous unions) in C. Some important
      points:
      
        - Fields are now in the "member" namespace (IDNS_Member), to keep
          them separate from tags and ordinary names in C. See the new test
          in Sema/member-reference.c for an example of why this matters. In
          C++, ordinary and member name lookup will find members in both the
          ordinary and member namespace, so the difference between
          IDNS_Member and IDNS_Ordinary is erased by Sema::LookupDecl (but
          only in C++!). 
        - We always introduce a Scope and push a DeclContext when we're
          defining a tag, in both C and C++. Previously, we had different
          actions and different Scope/CurContext behavior for enums, C
          structs/unions, and C++ structs/unions/classes. Now, it's one pair
          of actions. (Yay!)
      
      There's still some fuzziness in the handling of struct/union/enum
      definitions within other struct/union/enum definitions in C. We'll
      need to do some more cleanup to eliminate some reliance on CurContext
      before we can solve this issue for real. What we want is for something
      like this:
      
        struct X {
          struct T { int x; } t;
        };
      
      to introduce T into translation unit scope (placing it at the
      appropriate point in the IdentifierResolver chain, too), but it should
      still have struct X as its lexical declaration
      context. PushOnScopeChains isn't smart enough to do that yet, though,
      so there's a FIXME test in nested-redef.c
      
      llvm-svn: 61940
      82ac25e4
  24. Dec 21, 2008
  25. Dec 17, 2008
  26. Dec 13, 2008
  27. Dec 11, 2008
Loading