Skip to content
  1. Mar 28, 2009
  2. Mar 27, 2009
  3. Mar 26, 2009
  4. Mar 25, 2009
  5. Mar 24, 2009
  6. Mar 23, 2009
  7. Mar 22, 2009
  8. 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
  9. 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
  10. Mar 17, 2009
  11. Mar 15, 2009
  12. Mar 14, 2009
  13. Mar 13, 2009
    • Douglas Gregor's avatar
      Refactor the way we handle operator overloading and template · 1baf54e1
      Douglas Gregor authored
      instantiation for binary operators. This change moves most of the
      operator-overloading code from the parser action ActOnBinOp to a new,
      parser-independent semantic checking routine CreateOverloadedBinOp. 
      
      Of particular importance is the fact that CreateOverloadedBinOp does
      *not* perform any name lookup based on the current parsing context (it
      doesn't take a Scope*), since it has to be usable during template
      instantiation, when there is no scope information. Rather, it takes a
      pre-computed set of functions that are visible from the context or via
      argument-dependent lookup, and adds to that set any member operators
      and built-in operator candidates. The set of functions is computed in
      the parser action ActOnBinOp based on the current context (both
      operator name lookup and argument-dependent lookup). Within a
      template, the set computed by ActOnBinOp is saved within the
      type-dependent AST node and is augmented with the results of
      argument-dependent name lookup at instantiation time (see
      TemplateExprInstantiator::VisitCXXOperatorCallExpr).
      
      Sadly, we can't fully test this yet. I'll follow up with template
      instantiation for sizeof so that the real fun can begin.
      
      llvm-svn: 66923
      1baf54e1
  14. Mar 12, 2009
  15. Mar 11, 2009
  16. Mar 10, 2009
    • Douglas Gregor's avatar
      Limit the template instantiation depth to some user-configurable value · fcd5db3b
      Douglas Gregor authored
      (default: 99). Beyond this limit, produce an error and consider the
      current template instantiation a failure.
      
      The stack we're building to track the instantiations will, eventually,
      be used to produce instantiation backtraces from diagnostics within
      template instantiation. However, we're not quite there yet.
      
      This adds a new Clang driver option -ftemplate-depth=NNN, which should
      eventually be generated from the GCC command-line operation
      -ftemplate-depth-NNN (note the '-' rather than the '='!). I did not
      make the driver changes to do this mapping.
      
      llvm-svn: 66513
      fcd5db3b
    • Douglas Gregor's avatar
      Implement template instantiation for ClassTemplateSpecializationTypes, · c40290e4
      Douglas Gregor authored
      such as replacing 'T' in vector<T>. There are a few aspects to this:
      
        - Extend TemplateArgument to allow arbitrary expressions (an
          Expr*), and switch ClassTemplateSpecializationType to store
          TemplateArguments rather than it's own type-or-expression
          representation.
      
        - ClassTemplateSpecializationType can now store dependent types. In
          that case, the canonical type is another
          ClassTemplateSpecializationType (with default template arguments
          expanded) rather than a declaration (we don't build Decls for
          dependent types).
      
        - Split ActOnClassTemplateId into ActOnClassTemplateId (called from
          the parser) and CheckClassTemplateId (called from
          ActOnClassTemplateId and InstantiateType). They're smart enough to
          handle dependent types, now.
      
      llvm-svn: 66509
      c40290e4
  17. Mar 09, 2009
  18. Mar 06, 2009
  19. Mar 05, 2009
Loading