[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7dea2f84f26d454331d34b8536c261b6e96205d7 commit r10-9608-g7dea2f84f26d454331d34b8536c261b6e96205d7 Author: Jonathan Wakely Date: Thu Aug 27 22:36:03 2020 +0100 libstdc++: Make std::chrono::duration use reduced ratio for period This implements the changes from P0548 "common_type and duration". That was a change for C++17, but as it corrects some issues introduced by DRs I'm also treating it as a DR and changing it for all modes from C++11 up. The main change is that duration::period no longer denotes P, but rather P::type, the reduced ratio. The unary operator+ and operator- members of duration should now return a duration using that reduced ratio. The requirement that common_type::type is the same type as common_type::type (rather than simply T) was already implemented for PR 89102. The standard says that duration::operator+() and duration::operator-() should return common_type_t, but that seems unnecessarily expensive to compute. This uses duration, period> which is the same type, so we avoid a common_type specialization. As an optimization, this also adds partial specializations of common_type for two durations of the same type, a single duration, two time_points of the same type, and a single time_point. These specializations avoid instantiating other specializations of common_type and one or both of __duration_common_type or __timepoint_common_type for the cases where the answer is trivial to obtain. libstdc++-v3/ChangeLog: * include/std/chrono (__duration_common_type): Ensure the reduced ratio is used. Remove unused partial specialization using __failure_type. (common_type): Pass reduced ratios to __duration_common_type. Add partial specializations for simple cases involving a single duration or time_point type. (duration::period): Use reduced ratio. (duration::operator+(), duration::operator-()): Return duration type using the reduced ratio. * testsuite/20_util/duration/requirements/typedefs_neg2.cc: Adjust expected errors. * testsuite/20_util/duration/requirements/reduced_period.cc: New test. (cherry picked from commit 82030d51017323c5706d58d8c8626324ece007e4)
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:82030d51017323c5706d58d8c8626324ece007e4 commit r11-2913-g82030d51017323c5706d58d8c8626324ece007e4 Author: Jonathan Wakely Date: Thu Aug 27 22:36:03 2020 +0100 libstdc++: Make std::chrono::duration use reduced ratio for period This implements the changes from P0548 "common_type and duration". That was a change for C++17, but as it corrects some issues introduced by DRs I'm also treating it as a DR and changing it for all modes from C++11 up. The main change is that duration::period no longer denotes P, but rather P::type, the reduced ratio. The unary operator+ and operator- members of duration should now return a duration using that reduced ratio. The requirement that common_type::type is the same type as common_type::type (rather than simply T) was already implemented for PR 89102. The standard says that duration::operator+() and duration::operator-() should return common_type_t, but that seems unnecessarily expensive to compute. This change just uses duration which is the same type, so we don't need to instantiate common_type. As an optimization, this also adds partial specializations of common_type for two durations of the same type, a single duration, two time_points of the same type, and a single time_point. These specializations avoid instantiating other specializations of common_type and one or both of __duration_common_type or __timepoint_common_type for the cases where the answer is trivial to obtain. libstdc++-v3/ChangeLog: * include/std/chrono (__duration_common_type): Ensure the reduced ratio is used. Remove unused partial specialization using __failure_type. (common_type): Pass reduced ratios to __duration_common_type. Add partial specializations for simple cases involving a single duration or time_point type. (duration::period): Use reduced ratio. (duration::operator+(), duration::operator-()): Return duration type using the reduced ratio. * testsuite/20_util/duration/requirements/typedefs_neg2.cc: Adjust expected errors. * testsuite/20_util/duration/requirements/reduced_period.cc: New test.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- The abominable function types handling is fixed for gcc 8.4 and the full C++2a common_type spec is implemented on trunk now.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Tue May 7 22:46:39 2019 New Revision: 270987 URL: https://gcc.gnu.org/viewcvs?rev=270987=gcc=rev Log: PR libstdc++/89102 implement new common_type rules (P0435R1, P0548R1) This change ensures that std::common_type<> is a complete type (LWG 2408), and that std::common_type, std::common_type, and std::common_type will use program-defined specializations for std::common_type (LWG 2465). The implementation of common_type is changed to use void_t, and the specializations for duration and time_point are modified to also use void_t instead of depending on implementation details of common_type. PR libstdc++/89102 * doc/xml/manual/intro.xml: Document DR 2408 and 2465 changes. * include/std/chrono (__duration_common_type_wrapper): Replace with ... (__duration_common_type): New helper. (common_type, chrono::duration>): Use __duration_common_type. (__timepoint_common_type_wrapper): Replace with ... (__timepoint_common_type): New helper. (common_type, chrono::time_point>): Use __time_point_common_type. * include/std/type_traits (common_type<>): Define, as per LWG 2408. (__common_type_impl): If either argument is transformed by decay, use the common_type of the decayed types. (__common_type_impl<_Tp, _Up, _Tp, _Up>): If the types are already decayed, use __do_common_type_impl to get the common_type. (common_type<_Tp>): Use common_type<_Tp, _Tp>. (__do_member_type_wrapper, __member_type_wrapper) (__expanded_common_type_wrapper): Remove. (__common_type_pack, __common_type_fold): New helpers. (common_type<_Tp, _Up, _Vp...>): Use new helpers instead of __member_type_wrapper and __expanded_common_type_wrapper. * testsuite/20_util/common_type/requirements/explicit_instantiation.cc: Test zero-length template argument list. * testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: Test single argument cases and argument types that should decay. * testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc: Adjust expected error. * testsuite/20_util/duration/literals/range_neg.cc: Use zero for dg-error lineno. * testsuite/20_util/duration/requirements/typedefs_neg1.cc: Likewise. * testsuite/20_util/duration/requirements/typedefs_neg2.cc: Likewise. * testsuite/20_util/duration/requirements/typedefs_neg3.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/std/chrono trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc trunk/libstdc++-v3/testsuite/20_util/duration/literals/range_neg.cc trunk/libstdc++-v3/testsuite/20_util/duration/requirements/typedefs_neg1.cc trunk/libstdc++-v3/testsuite/20_util/duration/requirements/typedefs_neg2.cc trunk/libstdc++-v3/testsuite/20_util/duration/requirements/typedefs_neg3.cc
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Tue May 7 15:46:44 2019 New Revision: 270968 URL: https://gcc.gnu.org/viewcvs?rev=270968=gcc=rev Log: PR libstdc++/89102 fix common_type<> and common_type specializations This is a partial implementation of the revised std::common_type rules from P0435R1. Backport from mainline 2019-02-06 Jonathan Wakely PR libstdc++/89102 (partial) * include/std/type_traits (common_type<>): Define. (common_type): Derive from common_type. * testsuite/20_util/common_type/requirements/explicit_instantiation.cc: Test zero-length template argument list. * testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: Test additional single argument cases. * testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc: Adjust expected error. Modified: branches/gcc-8-branch/libstdc++-v3/ChangeLog branches/gcc-8-branch/libstdc++-v3/include/std/type_traits branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 Jakub Jelinek changed: What|Removed |Added Target Milestone|8.3 |8.4 --- Comment #5 from Jakub Jelinek --- GCC 8.3 has been released.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.3
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #4 from Jonathan Wakely --- Minimal fix committed to trunk, with a complete fix posted to https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00346.html for stage 1.
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Wed Feb 6 17:25:26 2019 New Revision: 268586 URL: https://gcc.gnu.org/viewcvs?rev=268586=gcc=rev Log: PR libstdc++/89102 fix common_type<> and common_type specializations This is a partial implementation of the revised std::common_type rules from P0435R1. PR libstdc++/89102 (partial) * include/std/type_traits (common_type<>): Define. (common_type): Derive from common_type. * testsuite/20_util/common_type/requirements/explicit_instantiation.cc: Test zero-length template argument list. * testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: Test additional single argument cases. * testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc: Adjust expected error. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #2 from Jonathan Wakely --- That changed with P0548R1 (which is not a DR).
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-02-06 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- We implement the C++14 rules still, where common_type::type is just decay::type.
