Skip to content
  1. Jul 15, 2010
    • Douglas Gregor's avatar
      When there are extra or missing template parameter lists in a template · 5f0e252f
      Douglas Gregor authored
      definition, we're likely going to end up breaking the invariants of
      the template system, e.g., that the depths of template parameter lists
      match up with the nesting template of the template. So, make sure we
      mark such ill-formed declarations as invalid or don't even build them
      at all.
      
      llvm-svn: 108372
      5f0e252f
  2. Jul 14, 2010
  3. Jul 13, 2010
    • Douglas Gregor's avatar
      When computing the canonical profile of a DeclRefExpr or MemberExpr, · f5b160f8
      Douglas Gregor authored
      don't include the nested-name-specifier or template arguments: they
      were only relevant when resolving the declaration. Fixes PR7460.
      
      llvm-svn: 108235
      f5b160f8
    • Douglas Gregor's avatar
      When forming a function call or message send expression, be sure to · 603d81bf
      Douglas Gregor authored
      strip cv-qualifiers from the expression's type when the language calls
      for it: in C, that's all the time, while C++ only does it for
      non-class types. 
      
      Centralized the computation of the call expression type in
      QualType::getCallResultType() and some helper functions in other nodes
      (FunctionDecl, ObjCMethodDecl, FunctionType), and updated all relevant
      callers of getResultType() to getCallResultType().
      
      Fixes PR7598 and PR7463, along with a bunch of getResultType() call
      sites that weren't stripping references off the result type (nothing
      stripped cv-qualifiers properly before this change).
      
      llvm-svn: 108234
      603d81bf
    • Douglas Gregor's avatar
      Provide a special diagnostic for attempts to explicitly specialize · 6cc1df5d
      Douglas Gregor authored
      class templates within class scope (which is ill-formed), and recover
      by dropping the explicit specialization entirely. Fixes the infinite
      loop in PR7622.
      
      llvm-svn: 108217
      6cc1df5d
  4. Jul 12, 2010
  5. Jul 10, 2010
  6. Jul 08, 2010
  7. Jun 30, 2010
  8. Jun 29, 2010
  9. Jun 25, 2010
    • Chandler Carruth's avatar
      Implement dependent alignment attribute support. This is a bit gross given the · f40c42f2
      Chandler Carruth authored
      current attribute system, but it is enough to handle class templates which
      specify parts of their alignment in terms of their template parameters.
      
      This also replaces the attributes test in SemaTemplate with one that actually
      tests working attributes instead of broken ones. I plan to add more tests here
      for non-dependent attributes in a subsequent patch.
      
      Thanks to John for walking me through some of this. =D
      
      llvm-svn: 106818
      f40c42f2
  10. Jun 22, 2010
  11. Jun 18, 2010
  12. Jun 17, 2010
  13. Jun 16, 2010
  14. Jun 15, 2010
  15. Jun 11, 2010
  16. May 27, 2010
  17. May 26, 2010
  18. May 24, 2010
  19. May 22, 2010
    • Douglas Gregor's avatar
      Don't look for a destructor in a dependent type. Fixes PR7198. · 024d80e5
      Douglas Gregor authored
      llvm-svn: 104445
      024d80e5
    • Douglas Gregor's avatar
      Implement support for variable length arrays in C++. VLAs are limited · 959d5a0c
      Douglas Gregor authored
      in several important ways:
      
        - VLAs of non-POD types are not permitted.
        - VLAs cannot be used in conjunction with C++ templates.
      
      These restrictions are intended to keep VLAs out of the parts of the
      C++ type system where they cause the most trouble. Fixes PR5678 and
      <rdar://problem/8013618>.
      
      llvm-svn: 104443
      959d5a0c
    • Douglas Gregor's avatar
      Improve recovery when we see a dependent template name that is missing · 20c38a7c
      Douglas Gregor authored
      the required "template" keyword, using the same heuristics we do for
      dependent template names in member access expressions, e.g.,
      
      test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
            keyword to treat 'getAs' as a dependent template name
          T::getAs<U>();
             ^
             template 
      
      Fixes PR5404.
      
      llvm-svn: 104409
      20c38a7c
    • Douglas Gregor's avatar
      Improve parser recovery when we encounter a dependent template name · 786123dc
      Douglas Gregor authored
      that is missing the 'template' keyword, e.g., 
      
        t->getAs<T>()
      
      where getAs is a member of an unknown specialization. C++ requires
      that we treat "getAs" as a value, but that would fail to parse since T
      is the name of a type. We would then fail at the '>', since a type
      cannot be followed by a '>'.
      
      This is a very common error for C++ programmers to make, especially
      since GCC occasionally allows it when it shouldn't (as does Visual
      C++). So, when we are in this case, we use tentative parsing to see if
      the tokens starting at "<" can only be parsed as a template argument
      list. If so, we produce a diagnostic with a fix-it that states that
      the 'template' keyword is needed:
      
      test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
            is required to treat 'getAs' as a dependent template name
          t->getAs<T>();
             ^
             template 
      
      This is just a start of this patch; I'd like to apply the same
      approach to everywhere that a template-id with dependent template name
      can be parsed.
      
      llvm-svn: 104406
      786123dc
  20. May 21, 2010
  21. May 19, 2010
  22. May 18, 2010
  23. May 14, 2010
  24. May 13, 2010
    • Douglas Gregor's avatar
      Rework when and how vtables are emitted, by tracking where vtables are · 88d292cc
      Douglas Gregor authored
      "used" (e.g., we will refer to the vtable in the generated code) and
      when they are defined (i.e., because we've seen the key function
      definition). Previously, we were effectively tracking "potential
      definitions" rather than uses, so we were a bit too eager about emitting
      vtables for classes without key functions. 
      
      The new scheme:
        - For every use of a vtable, Sema calls MarkVTableUsed() to indicate
        the use. For example, this occurs when calling a virtual member
        function of the class, defining a constructor of that class type,
        dynamic_cast'ing from that type to a derived class, casting
        to/through a virtual base class, etc.
        - For every definition of a vtable, Sema calls MarkVTableUsed() to
        indicate the definition. This happens at the end of the translation
        unit for classes whose key function has been defined (so we can
        delay computation of the key function; see PR6564), and will also
        occur with explicit template instantiation definitions.
       - For every vtable defined/used, we mark all of the virtual member
       functions of that vtable as defined/used, unless we know that the key
       function is in another translation unit. This instantiates virtual
       member functions when needed.
        - At the end of the translation unit, Sema tells CodeGen (via the
        ASTConsumer) which vtables must be defined (CodeGen will define
        them) and which may be used (for which CodeGen will define the
        vtables lazily). 
      
      From a language perspective, both the old and the new schemes are
      permissible: we're allowed to instantiate virtual member functions
      whenever we want per the standard. However, all other C++ compilers
      were more lazy than we were, and our eagerness was both a performance
      issue (we instantiated too much) and a portability problem (we broke
      Boost test cases, which now pass).
      
      Notes:
        (1) There's a ton of churn in the tests, because the order in which
        vtables get emitted to IR has changed. I've tried to isolate some of
        the larger tests from these issues.
        (2) Some diagnostics related to
        implicitly-instantiated/implicitly-defined virtual member functions
        have moved to the point of first use/definition. It's better this
        way.
        (3) I could use a review of the places where we MarkVTableUsed, to
        see if I missed any place where the language effectively requires a
        vtable.
      
      Fixes PR7114 and PR6564.
      
      llvm-svn: 103718
      88d292cc
  25. May 12, 2010
  26. May 11, 2010
Loading