Skip to content
  1. Apr 13, 2009
  2. Apr 12, 2009
    • Sebastian Redl's avatar
      Parse deleted member functions. Parsing member declarations goes through a... · 42e92c4b
      Sebastian Redl authored
      Parse deleted member functions. Parsing member declarations goes through a different code path that I forgot previously.
      Implement the rvalue reference overload dance for returning local objects. Returning a local object first tries to find a move constructor now.
      The error message when no move constructor is defined (or is not applicable) and the copy constructor is deleted is quite ugly, though.
      
      llvm-svn: 68902
      42e92c4b
  3. Apr 09, 2009
  4. Apr 02, 2009
  5. 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
    • Sebastian Redl's avatar
      Reintroduce r67870 (rval ref overloading), since I can't reproduce any test... · 4c0cd856
      Sebastian Redl authored
      Reintroduce r67870 (rval ref overloading), since I can't reproduce any test failures on i386 or x86_64. If this fails for someone, please contact me.
      
      llvm-svn: 67999
      4c0cd856
    • Chris Lattner's avatar
      various cleanups · 85e2e141
      Chris Lattner authored
      llvm-svn: 67981
      85e2e141
    • Anders Carlsson's avatar
      More improvements to namespace aliases. We now support everything except... · bb1e4724
      Anders Carlsson authored
      More improvements to namespace aliases. We now support everything except aliases in using directives.
      
      llvm-svn: 67966
      bb1e4724
    • Anders Carlsson's avatar
      Fix lookup bug · 3694935c
      Anders Carlsson authored
      llvm-svn: 67964
      3694935c
  6. Mar 28, 2009
  7. Mar 27, 2009
  8. Mar 26, 2009
  9. Mar 25, 2009
  10. Mar 24, 2009
  11. Mar 23, 2009
  12. Mar 22, 2009
  13. Mar 19, 2009
    • Douglas Gregor's avatar
      Introduce a representation for types that we referred to via a · 5253768a
      Douglas Gregor authored
      qualified name, e.g., 
      
        foo::x
      
      so that we retain the nested-name-specifier as written in the source
      code and can reproduce that qualified name when printing the types
      back (e.g., in diagnostics). This is PR3493, which won't be complete
      until finished the other tasks mentioned near the end of this commit.
      
      The parser's representation of nested-name-specifiers, CXXScopeSpec,
      is now a bit fatter, because it needs to contain the scopes that
      precede each '::' and keep track of whether the global scoping
      operator '::' was at the beginning. For example, we need to keep track
      of the leading '::', 'foo', and 'bar' in
       
        ::foo::bar::x
      
      The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
      opaque version of the new NestedNameSpecifier, which contains a single
      component of a nested-name-specifier (either a DeclContext * or a Type
      *, bitmangled). 
      
      The new sugar type QualifiedNameType composes a sequence of
      NestedNameSpecifiers with a representation of the type we're actually
      referring to. At present, we only build QualifiedNameType nodes within
      Sema::getTypeName. This will be extended to other type-constructing
      actions (e.g., ActOnClassTemplateId).
      
      Also on the way: QualifiedDeclRefExprs will also store a sequence of
      NestedNameSpecifiers, so that we can print out the property
      nested-name-specifier. I expect to also use this for handling
      dependent names like Fibonacci<I - 1>::value.
      
      llvm-svn: 67265
      5253768a
  14. Mar 18, 2009
    • Douglas Gregor's avatar
      The scope representation can now be either a DeclContext pointer or a · 6bfde496
      Douglas Gregor authored
      Type pointer. This allows our nested-name-specifiers to retain more
      information about the actual spelling (e.g., which typedef did the
      user name, or what exact template arguments were used in the
      template-id?). It will also allow us to have dependent
      nested-name-specifiers that don't map to any DeclContext.
      
      llvm-svn: 67140
      6bfde496
  15. Mar 17, 2009
  16. Mar 15, 2009
Loading