Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
1 result
Search by author
  • Any Author
  • Dr. Jorrit Fahlke Dr. Jorrit Fahlke jfahl_01
  • Jan Hönig hoenig
  • Marcel Dominique Koch marckoch
  • Martin Bauer bauermar
  • Michael Haidl m_haid02
  • Prof. Dr. Christian Engwer Prof. Dr. Christian Engwer cengw_01
  • René Heß hessr
  • Vladyslav Kucher kucher
8 authors
  1. Nov 11, 2017
  3. Oct 23, 2017
  5. Sep 09, 2017
  7. Sep 07, 2017
  9. Aug 31, 2017
  11. Aug 28, 2017
  13. Aug 25, 2017
  15. Aug 19, 2017
  17. Aug 11, 2017
  19. Jul 15, 2017
  21. Jul 06, 2017
  23. May 28, 2017
  25. May 26, 2017
  27. Mar 16, 2017
  29. Feb 22, 2017
  31. Feb 16, 2017
  33. Feb 14, 2017
  35. Feb 09, 2017
  37. Jan 13, 2017
  39. Dec 31, 2016
    • Richard Smith's avatar
      [c++17] Implement P0522R0 as written. This allows a template template argument · 2faed1c4
      Richard Smith authored 
      to be specified for a template template parameter whenever the parameter is at
least as specialized as the argument (when there's an obvious and correct
mapping from uses of the parameter to uses of the argument). For example, a
template with more parameters can be passed to a template template parameter
with fewer, if those trailing parameters have default arguments.

This is disabled by default, despite being a DR resolution, as it's fairly
broken in its current state: there are no partial ordering rules to cope with
template template parameters that have different parameter lists, meaning that
code that attempts to decompose template-ids based on arity can hit unavoidable
ambiguity issues.

The diagnostics produced on a non-matching argument are also pretty bad right
now, but I aim to improve them in a subsequent commit.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290792 91177308-0d34-0410-b5e6-96231b3b80d8
      2faed1c4
  41. Dec 19, 2016
  43. Dec 14, 2016
  45. Dec 08, 2016
    • Richard Smith's avatar
      [c++1z] P0003R5: Removing dynamic exception specifications. · 1f0155f2
      Richard Smith authored 
      We continue to support dynamic exception specifications in C++1z as an
extension, but produce an error-by-default warning when we encounter one. This
allows users to opt back into the feature with a warning flag, and implicitly
opts system headers back into the feature should they happen to use it.

There is one semantic change implied by P0003R5 but not implemented here:
violating a throw() exception specification should now call std::terminate
directly instead of calling std::unexpected(), but since P0003R5 also removes
std::unexpected() and std::set_unexpected, and the default unexpected handler
calls std::terminate(), a conforming C++1z program cannot tell that we are
still calling it. The upside of this strategy is perfect backwards
compatibility; the downside is that we don't get the more efficient 'noexcept'
codegen for 'throw()'.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@289019 91177308-0d34-0410-b5e6-96231b3b80d8
      1f0155f2
  47. Dec 07, 2016
  49. Dec 01, 2016
  51. Nov 12, 2016
  53. Nov 11, 2016
  55. Nov 01, 2016
  57. Oct 26, 2016
  59. Oct 22, 2016
  61. Oct 10, 2016
  63. Sep 29, 2016
    • Richard Smith's avatar
      Switch to a different workaround for unimplementability of P0145R3 in MS ABIs. · c15b46ec
      Richard Smith authored 
      Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.

We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.

Approach reviewed off-line by rnk.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@282777 91177308-0d34-0410-b5e6-96231b3b80d8
      c15b46ec