Skip to content
Snippets Groups Projects
  1. Apr 15, 2017
    • Serge Pavlov's avatar
      Do not run tests for crash recovery if libstdc++ safe mode is enabled · f246e7a5
      Serge Pavlov authored
      If expensive checks are enabled, safe mode of libstdc++ is enabled too.
      In this mode the library uses more complex data that allow additional
      checks, for instance, a container may keep list of iterators that points
      to it. If a code crashes it can leave these complex library objects in
      inconsistent state. It occurs in a few tests that check error recovery
      if compiler crashes. These test hang in expensive check mode, as the
      library tries to synchronize access to the iterators pointing to some
      container, but corresponding mutex remains locked after the crash.
      
      This fix marks these tests as unsupported if clang is built with
      libstdc++ safe mode enabled.
      
      Differential Revision: https://reviews.llvm.org/D31126
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@300392 91177308-0d34-0410-b5e6-96231b3b80d8
      f246e7a5
  2. Apr 11, 2017
  3. Mar 23, 2017
  4. Mar 21, 2017
  5. Mar 18, 2017
  6. Mar 16, 2017
  7. Mar 13, 2017
  8. Mar 10, 2017
  9. Mar 07, 2017
  10. Mar 04, 2017
  11. Feb 27, 2017
  12. Feb 26, 2017
  13. Feb 25, 2017
  14. Feb 17, 2017
  15. Feb 15, 2017
  16. Feb 13, 2017
  17. Feb 10, 2017
  18. Feb 01, 2017
  19. Jan 30, 2017
  20. Jan 29, 2017
  21. Jan 26, 2017
  22. Jan 24, 2017
  23. Jan 23, 2017
  24. Jan 19, 2017
    • Richard Smith's avatar
      PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310). · a669043d
      Richard Smith authored
      Under this defect resolution, the injected-class-name of a class or class
      template cannot be used except in very limited circumstances (when declaring a
      constructor, in a nested-name-specifier, in a base-specifier, or in an
      elaborated-type-specifier). This is apparently done to make parsing easier, but
      it's a pain for us since we don't know whether a template-id using the
      injected-class-name is valid at the point when we annotate it (we don't yet
      know whether the template-id will become part of an elaborated-type-specifier).
      
      As a tentative resolution to a perceived language defect, mem-initializer-ids
      are added to the list of exceptions here (they generally follow the same rules
      as base-specifiers).
      
      When the reference to the injected-class-name uses the 'typename' or 'template'
      keywords, we permit it to be used to name a type or template as an extension;
      other compilers also accept some cases in this area. There are also a couple of
      corner cases with dependent template names that we do not yet diagnose, but
      which will also get this treatment.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292518 91177308-0d34-0410-b5e6-96231b3b80d8
      a669043d
  25. Jan 16, 2017
  26. Jan 11, 2017
  27. Jan 10, 2017
    • Richard Smith's avatar
      Check that template template arguments match template template parameters · b6254454
      Richard Smith authored
      properly even when a non-type template parameter has a dependent type.
      
      Previously, if a non-type template parameter was dependent, but not dependent
      on an outer level of template parameter, we would not match the type of the
      parameter. Under [temp.arg.template], we are supposed to check that the types
      are equivalent, which means checking for syntactic equivalence in the dependent
      case.
      
      This also fixes some accepts-invalids when passing templates with auto-typed
      non-type template parameters as template template arguments.
      
      
      git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291512 91177308-0d34-0410-b5e6-96231b3b80d8
      b6254454
  28. Jan 09, 2017
  29. Jan 06, 2017
  30. Jan 03, 2017
Loading