Skip to content
  1. Mar 24, 2009
  2. Mar 23, 2009
  3. Mar 22, 2009
  4. 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
  5. 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
  6. Mar 17, 2009
  7. Mar 15, 2009
  8. Mar 14, 2009
  9. 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
  10. Mar 12, 2009
  11. Mar 11, 2009
  12. 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
  13. Mar 09, 2009
  14. Mar 06, 2009
  15. Mar 05, 2009
  16. Mar 03, 2009
    • Douglas Gregor's avatar
      Implement the basics of implicit instantiation of class templates, in · 463421de
      Douglas Gregor authored
      response to attempts to diagnose an "incomplete" type. This will force
      us to use DiagnoseIncompleteType more regularly (rather than looking at
      isIncompleteType), but that's also a good thing.
      
      Implicit instantiation is still very simplistic, and will create a new
      definition for the class template specialization (as it should) but it
      only actually instantiates the base classes and attaches
      those. Actually instantiating class members will follow. 
      
      Also, instantiate the types of non-type template parameters before
      checking them,  allowing, e.g., 
      
        template<typename T, T Value> struct Constant; 
       
      to work properly.
      
      llvm-svn: 65924
      463421de
  17. Feb 27, 2009
    • Douglas Gregor's avatar
      Create a new TypeNodes.def file that enumerates all of the types, · deaad8cc
      Douglas Gregor authored
      giving them rough classifications (normal types, never-canonical
      types, always-dependent types, abstract type representations) and
      making it far easier to make sure that we've hit all of the cases when
      decoding types. 
      
      Switched some switch() statements on the type class over to using this
      mechanism, and filtering out those things we don't care about. For
      example, CodeGen should never see always-dependent or non-canonical
      types, while debug info generation should never see always-dependent
      types. More switch() statements on the type class need to be moved 
      over to using this approach, so that we'll get warnings when we add a
      new type then fail to account for it somewhere in the compiler.
      
      As part of this, some types have been renamed:
      
        TypeOfExpr -> TypeOfExprType
        FunctionTypeProto -> FunctionProtoType
        FunctionTypeNoProto -> FunctionNoProtoType
      
      There shouldn't be any functionality change...
      
      llvm-svn: 65591
      deaad8cc
  18. Feb 18, 2009
    • Douglas Gregor's avatar
      Downgrade complaints about calling unavailable functions to a warning · 171c45ab
      Douglas Gregor authored
      (as GCC does), except when we've performed overload resolution and
      found an unavailable function: in this case, we actually error.
      
      Merge the checking of unavailable functions with the checking for
      deprecated functions. This unifies a bit of code, and makes sure that
      we're checking for unavailable functions in the right places. Also,
      this check can cause an error. We may, eventually, want an option to
      make "unavailable" warnings into errors.
      
      Implement much of the logic needed for C++0x deleted functions, which
      are effectively the same as "unavailable" functions (but always cause
      an error when referenced). However, we don't have the syntax to
      specify deleted functions yet :)
      
      llvm-svn: 64955
      171c45ab
  19. Feb 17, 2009
  20. Feb 16, 2009
    • Douglas Gregor's avatar
      Adopt a more principled approach to invalid declarations: · 75a45ba2
      Douglas Gregor authored
        - If a declaration is an invalid redeclaration of an existing name,
          complain about the invalid redeclaration then avoid adding it to
          the AST (we can still parse the definition or initializer, if any).
        - If the declaration is invalid but there is no prior declaration
          with that name, introduce the invalid declaration into the AST
          (for later error recovery).
        - If the declaration is an invalid redeclaration of a builtin that
          starts with __builtin_, we produce an error and drop the
          redeclaration. If it is an invalid redeclaration of a library
          builtin (e.g., malloc, printf), warn (don't error!) and drop the
          redeclaration.
      
      If a user attempts to define a builtin, produce an error and (if it's
      a library builtin like malloc) suggest -ffreestanding.
      
      This addresses <rdar://problem/6097585> and PR2892. However, PR3588 is
      still going to cause some problems when builtins are redeclared
      without a prototype.
      
      llvm-svn: 64639
      75a45ba2
  21. Feb 09, 2009
    • Douglas Gregor's avatar
      Make Sema::getTypeName return the opaque pointer of a QualType rather · 9817f4a7
      Douglas Gregor authored
      than a Decl, which gives us some more flexibility to express the
      results with the type system. There are no clients using this
      flexibility yet, but it's meant to be able to describe qualified names
      as written in the source (e.g., "foo::type") or template-ids that name
      a class template specialization (e.g., "std::vector<INT>").
      
      DeclSpec's TST_typedef has become TST_typename, to reflect its use to
      describe types found by name (that may or may not be typedefs). The
      type representation of a DeclSpec with TST_typename is an opaque
      QualType pointer. All users of TST_typedef, both direct and indirect,
      have been updated for these changes.
      
      llvm-svn: 64141
      9817f4a7
  22. Feb 07, 2009
    • Ted Kremenek's avatar
      Overhaul of Stmt allocation: · 5a201951
      Ted Kremenek authored
      - Made allocation of Stmt objects using vanilla new/delete a *compiler
        error* by making this new/delete "protected" within class Stmt.
      - Now the only way to allocate Stmt objects is by using the new
        operator that takes ASTContext& as an argument.  This ensures that
        all Stmt nodes are allocated from the same (pool) allocator.
      - Naturally, these two changes required that *all* creation sites for
        AST nodes use new (ASTContext&).  This is a large patch, but the
        majority of the changes are just this mechanical adjustment.
      - The above changes also mean that AST nodes can no longer be
        deallocated using 'delete'.  Instead, one most do
        StmtObject->Destroy(ASTContext&) or do
        ASTContextObject.Deallocate(StmtObject) (the latter not running the
        'Destroy' method).
      
      Along the way I also...
      - Made CompoundStmt allocate its array of Stmt* using the allocator in
        ASTContext (previously it used std::vector).  There are a whole
        bunch of other Stmt classes that need to be similarly changed to
        ensure that all memory allocated for ASTs comes from the allocator
        in ASTContext.
      - Added a new smart pointer ExprOwningPtr to Sema.h.  This replaces
        the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
        'delete' to free memory instead of a Stmt's 'Destroy' method.
      
      Big thanks to Doug Gregor for helping with the acrobatics of making
      'new/delete' private and the new smart pointer ExprOwningPtr!
      
      llvm-svn: 63997
      5a201951
  23. Feb 04, 2009
  24. Feb 03, 2009
Loading