Skip to content
  1. Jun 27, 2013
    • Eli Friedman's avatar
      Handle all TemplateArguments in trivial TypeLocs. · 437313c2
      Eli Friedman authored
      Armed with a much better understanding of what
      TemplateSpecializationTypeLoc::initializeArgLocs actually does, I now
      understand that it's fine to just use an empty TemplateArgumentLocInfo
      for Integral, Declaration, and NullPtr TemplateArguments.
      
      Fixes PR14281. (The testcases are actually derived from libcxx_test in
      deduction-crash.cpp because the original testcase was impossible to reduce.)
      
      llvm-svn: 185038
      437313c2
  2. Jun 21, 2013
  3. Jun 20, 2013
  4. Jun 13, 2013
  5. Jun 11, 2013
  6. Jun 08, 2013
  7. Jun 06, 2013
  8. Jun 04, 2013
  9. May 22, 2013
  10. May 16, 2013
  11. May 04, 2013
  12. May 03, 2013
    • Douglas Gregor's avatar
      Use attribute argument information to determine when to parse attribute arguments as expressions. · d2472d4c
      Douglas Gregor authored
      This change partly addresses a heinous problem we have with the
      parsing of attribute arguments that are a lone identifier. Previously,
      we would end up parsing the 'align' attribute of this as an expression
      "(Align)":
      
       template<unsigned Size, unsigned Align>
       class my_aligned_storage
       {
         __attribute__((align((Align)))) char storage[Size];
       };
      
      while this would parse as a "parameter name" 'Align':
      
       template<unsigned Size, unsigned Align>
       class my_aligned_storage
       {
         __attribute__((align(Align))) char storage[Size];
       };
      
      The code that handles the alignment attribute would completely ignore
      the parameter name, so the while the first of these would do what's
      expected, the second would silently be equivalent to
      
       template<unsigned Size, unsigned Align>
       class my_aligned_storage
       {
         __attribute__((align)) char storage[Size];
       };
      
      i.e., use the maximal alignment rather than the specified alignment.
      
      Address this by sniffing the "Args" provided in the TableGen
      description of attributes. If the first argument is "obviously"
      something that should be treated as an expression (rather than an
      identifier to be matched later), parse it as an expression.
      
      Fixes <rdar://problem/13700933>.
      
      llvm-svn: 180973
      d2472d4c
    • Douglas Gregor's avatar
      Revert r180970; it's causing breakage. · 33ebfe36
      Douglas Gregor authored
      llvm-svn: 180972
      33ebfe36
    • Douglas Gregor's avatar
      Use attribute argument information to determine when to parse attribute arguments as expressions. · 44dff3f2
      Douglas Gregor authored
      This change partly addresses a heinous problem we have with the
      parsing of attribute arguments that are a lone identifier. Previously,
      we would end up parsing the 'align' attribute of this as an expression
      "(Align)":
      
        template<unsigned Size, unsigned Align>
        class my_aligned_storage
        {
          __attribute__((align((Align)))) char storage[Size];
        };
      
      while this would parse as a "parameter name" 'Align':
      
        template<unsigned Size, unsigned Align>
        class my_aligned_storage
        {
          __attribute__((align(Align))) char storage[Size];
        };
      
      The code that handles the alignment attribute would completely ignore
      the parameter name, so the while the first of these would do what's
      expected, the second would silently be equivalent to
      
        template<unsigned Size, unsigned Align>
        class my_aligned_storage
        {
          __attribute__((align)) char storage[Size];
        };
      
      i.e., use the maximal alignment rather than the specified alignment.
      
      Address this by sniffing the "Args" provided in the TableGen
      description of attributes. If the first argument is "obviously"
      something that should be treated as an expression (rather than an
      identifier to be matched later), parse it as an expression.
      
      Fixes <rdar://problem/13700933>.
      
      llvm-svn: 180970
      44dff3f2
  13. Apr 30, 2013
  14. Apr 29, 2013
  15. Apr 24, 2013
  16. Apr 08, 2013
    • Richard Trieu's avatar
      Fix PR15634, better error message for template deduction failure. · e373235c
      Richard Trieu authored
      When two template decls with the same name are used in this diagnostic,
      force them to print their qualified names.  This changes the bad message of:
      
      candidate template ignored: could not match 'array' against 'array'
      
      to the better message of:
      
      candidate template ignored: could not match 'NS2::array' against 'NS1::array'
      
      llvm-svn: 179056
      e373235c
  17. Apr 04, 2013
  18. Mar 28, 2013
  19. Mar 27, 2013
    • Douglas Gregor's avatar
      <rdar://problem/13267210> Ensure that Sema::CompareReferenceRelationship... · 45bb4834
      Douglas Gregor authored
      <rdar://problem/13267210> Ensure that Sema::CompareReferenceRelationship returns consistent results with invalid types.
      
      When Sema::RequireCompleteType() is given a class template
      specialization type that then fails to instantiate, it returns
      'true'. On subsequent invocations, it can return false. Make sure that
      this difference doesn't change the result of
      Sema::CompareReferenceRelationship, which is expected to remain stable
      while we're checking an initialization sequence.
      
      llvm-svn: 178088
      45bb4834
  20. Mar 14, 2013
    • John McCall's avatar
      Flag that friend function definitions are "late parsed" so that · e68672fe
      John McCall authored
      template instantiation will still consider them to be definitions
      if we instantiate the containing class before we get around
      to parsing the friend.
      
      This seems like a legitimate use of "late template parsed" to me,
      but I'd appreciate it if someone responsible for the MS feature
      would look over this.
      
      This file already appears to access AST nodes directly, which
      is arguably not kosher in the parser, but the performance of this
      path matters enough that perpetuating the sin is justifiable.
      Probably we ought to reconsider this policy for very simple
      manipulations like this.
      
      The reason this entire thing is necessary is that
      function template instantiation plays some very gross games
      in order to not associate an instantiated function template
      with the class it came from unless it's a definition, and
      the reason *that's* necessary is that the AST currently
      cannot represent the instantiation history of individual
      function template declarations, but instead tracks it in
      common for the entire function template.  That probably
      prevents us from correctly reporting ill-formed calls to
      ambiguously instantiated friend function templates.
      
      rdar://12350696
      
      llvm-svn: 177003
      e68672fe
  21. Mar 08, 2013
  22. Mar 05, 2013
  23. Feb 27, 2013
  24. Feb 22, 2013
  25. Feb 02, 2013
    • Richard Smith's avatar
      PR15132: Replace "address expression must be an lvalue or a function · c084bd28
      Richard Smith authored
      designator" diagnostic with more correct and more human-friendly "cannot take
      address of rvalue of type 'T'".
      
      For the case of & &T::f, provide a custom diagnostic, rather than unhelpfully
      saying "cannot take address of rvalue of type '<overloaded function type>'".
      
      For the case of &array_temporary, treat it just like a class temporary
      (including allowing it as an extension); the existing diagnostic wording
      for the class temporary case works fine.
      
      llvm-svn: 174262
      c084bd28
  26. Jan 31, 2013
  27. Jan 16, 2013
  28. Dec 22, 2012
Loading