Skip to content
  1. 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
    • Gabor Greif's avatar
      Use the instantiated expressions to build the ConditionalOperator. This... · 5e09283e
      Gabor Greif authored
      Use the instantiated expressions to build the ConditionalOperator. This addresses the second part of review feedback.
      
      llvm-svn: 67259
      5e09283e
  2. Mar 18, 2009
  3. Mar 17, 2009
  4. Mar 16, 2009
  5. Mar 15, 2009
  6. Mar 14, 2009
  7. Mar 13, 2009
    • Douglas Gregor's avatar
      Implement template instantiation for several more kinds of expressions: · 0950e41b
      Douglas Gregor authored
        - C++ function casts, e.g., T(foo)
        - sizeof(), alignof()
      
      More importantly, this allows us to verify that we're performing
      overload resolution during template instantiation, with
      argument-dependent lookup and the "cached" results of name lookup from
      the template definition.
      
      llvm-svn: 66947
      0950e41b
    • Douglas Gregor's avatar
      Remove an already-fixed FIXME · f50abb42
      Douglas Gregor authored
      llvm-svn: 66924
      f50abb42
    • 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
    • Chris Lattner's avatar
      introduce a new -fheinous-gnu-extensions flag that enables really · cda4d7e1
      Chris Lattner authored
      really horrible extensions that are disabled by default but that can
      be accepted by -fheinous-gnu-extensions (but which always emit a 
      warning when enabled).
      
      As our first instance of this, implement PR3788/PR3794, which allows
      non-lvalues in inline asms in contexts where lvalues are required. bleh.
      
      llvm-svn: 66910
      cda4d7e1
    • Steve Naroff's avatar
      Fix <rdar://problem/6675489> BlockDecl should not use llvm::smallvector. · c4b30e59
      Steve Naroff authored
      Also changed BlockDecl API to be more consistent (wrt FunctionDecl).
      
      llvm-svn: 66904
      c4b30e59
    • Steve Naroff's avatar
      Reimplement fix for <rdar://problem/6451399> problems with labels and blocks. · cfb6cf4c
      Steve Naroff authored
      This solution is much simpler (and doesn't add any per-scope overhead, which concerned Chris). 
      
      The only downside is the LabelMap is now declared in two places (Sema and BlockSemaInfo). My original fix tried to unify the LabelMap in "Scope" (which would support nested functions in general). In any event, this fixes the bug given the current language definition. If/when we decide to support GCC style nested functions, this will need to be tweaked.
      
      llvm-svn: 66896
      cfb6cf4c
    • Steve Naroff's avatar
      Remove ActiveScope (revert... · 846b1ec4
      Steve Naroff authored
      Remove ActiveScope (revert http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).
      
      Will replace with something better today...
      
      llvm-svn: 66893
      846b1ec4
    • Douglas Gregor's avatar
      Improve the representation of operator expressions like "x + y" within · d2b7ef6e
      Douglas Gregor authored
      C++ templates. In particular, keep track of the overloaded operators
      that are visible from the template definition, so that they can be
      merged with those operators visible via argument-dependent lookup at
      instantiation time. 
      
      Refactored the lookup routines for argument-dependent lookup and for
      operator name lookup, so they can be called without immediately adding
      the results to an overload set.
      
      Instantiation of these expressions is completely wrong. I'll work on
      that next.
      
      llvm-svn: 66851
      d2b7ef6e
  8. Mar 12, 2009
Loading