Re: [committed] libstdc++: Add deduction guide for std::ranges::join_view [LWG 3474]
I thought LWG approved the other option in the PR (changing views::join to not use CTAD)? On Mon, Aug 24, 2020 at 10:22 AM Jonathan Wakely via Gcc-patches < gcc-patches@gcc.gnu.org> wrote: > This implements the proposed resolution for LWG 3474. > > libstdc++-v3/ChangeLog: > > * include/std/ranges (join_view): Add deduction guide (LWG 3474). > * testsuite/std/ranges/adaptors/join_lwg3474.cc: New test. > > Tested powerpc64le-linux. Committed to trunk. > >
Re: [committed] libstdc++: std::make_signed_t should be ill-formed
On Mon, Oct 10, 2022 at 8:09 AM Patrick Palka via Libstdc++
wrote:
>
> On Mon, 10 Oct 2022, Jonathan Wakely via Libstdc++ wrote:
>
> > Tested powerpc64le-linux. Pushed to trunk.
> >
> > -- >8 --
> >
> > Currently we only reject std::make_signed_t but not cv bool.
> > Similarly for std::make_unsigned_t.
> >
> > As well as making those ill-formed, this adds a requires-clause to the
> > make_signed and make_unsigned primary templates. This makes
> > non-integral, non-enum cases fail immediately with a clear error, rather
> > than giving an error about __make_signed_selector being
> > incomplete.
>
> IIUC the requires-clause turns what was once a hard error into a SFINAE
> error, so e.g. for
>
> template typename make_signed::type f(int);
> template void f(...);
> int main() { f(0); }
>
> the call to f would previously be rejected due to an error outside the
> immediate context about incomplete __make_signed_selector, and now with
> the requires-clause resolves to the second overload. I wonder if this
> new behavior is conforming -- the examples in [structure.specifications]
> of how to implement 'Mandates' suggest that a failed 'Mandates' should
> yield a hard error?
I'm also concerned about the inability to name make_signed in a
context that doesn't require its instantiation (e.g.,
conditional_t, make_signed,
type_identity>::type). That seems a plausible use case, and
breaking it doesn't seem great to me (conformance aside).
Re: [PATCH] libstdc++: Avoid hard error in ranges::unique_copy [PR100770]
I noticed that output_iterator_wrapper still has a (non-void)
value_type. Perhaps we can get better coverage if it doesn't have one?
The existing tests should have caught this case with that change, at least.
On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++
wrote:
>
> - else if constexpr (input_iterator<_Out>
> - && same_as,
> iter_value_t<_Out>>)
> + else if constexpr (requires { requires (input_iterator<_Out>
> + &&
> same_as,
> +
> iter_value_t<_Out>>); })
It's arguably cleaner to extract this into a concept which can then
also be used in the constraint.
Re: [PATCH] libstdc++: Avoid hard error in ranges::unique_copy [PR100770]
On Wed, May 26, 2021 at 1:43 PM Patrick Palka wrote:
>
> On Wed, 26 May 2021, Tim Song wrote:
> >
> > On Wed, May 26, 2021 at 12:00 PM Patrick Palka via Libstdc++
> > wrote:
> > >
> > > - else if constexpr (input_iterator<_Out>
> > > - && same_as,
> > > iter_value_t<_Out>>)
> > > + else if constexpr (requires { requires (input_iterator<_Out>
> > > + &&
> > > same_as,
> > > +
> > > iter_value_t<_Out>>); })
> >
> > It's arguably cleaner to extract this into a concept which can then
> > also be used in the constraint.
>
> Sounds good, though I'm not sure what name to give to this relatively
> ad-hoc set of requirements. Any suggestions? :)
>
Something along the lines of "__can_reread_output", perhaps?
Re: [PATCH] libstdc++: Avoid hard error in ranges::unique_copy [PR100770]
On Wed, May 26, 2021 at 2:55 PM Jonathan Wakely wrote: > > On Wed, 26 May 2021 at 20:11, Patrick Palka via Libstdc++ > wrote: > > > > On Wed, 26 May 2021, Tim Song wrote: > > > > > I noticed that output_iterator_wrapper still has a (non-void) > > > value_type. Perhaps we can get better coverage if it doesn't have one? > > > The existing tests should have caught this case with that change, at > > > least. > > > > Good point, and I guess it should be fine to make its pointer and > > reference void as well. I'm testing: > > Defining difference_type as void is also OK. C++20 requires (new-style) output iterators to have a valid difference_type too (that requirement comes from weakly_incrementable).
Re: [committed] libstdc++: Implement monadic operations for std::optional (P0798R8)
On Tue, Oct 19, 2021 at 9:05 AM Jonathan Wakely via Gcc-patches
wrote:
>
> +constexpr bool
> +test_copy_elision()
> +{
> + return true;
> +}
> +
> +static_assert( test_copy_elision() );
> +
This isn't much of a test :)
Re: [PATCH] libstdc++: Implement P2328 changes to join_view
On Fri, Apr 30, 2021 at 12:11 PM Patrick Palka via Libstdc++
wrote:
>
> + template
> + _Tp&
> + _M_emplace_deref(const _Iter& __i)
> + {
> + this->reset();
> + return this->emplace(*__i);
> + }
This incurs a move, avoiding of which is the sole reason for
emplace-deref's existence.
> + };
> + }
> +
Re: [PATCH] libstdc++: Fix iterator caching inside range adaptors [PR100479]
On Mon, May 17, 2021 at 11:46 AM Patrick Palka via Libstdc++
wrote:
> constexpr void
> _M_set(const _Range&, const iterator_t<_Range>& __it)
> {
> __glibcxx_assert(!_M_has_value());
> - _M_iter = __it;
> + this->_M_payload._M_payload._M_value = __it;
> + this->_M_payload._M_engaged = true;
> }
>};
This part looks questionable - if we don't have a value then we can't
assign to a nonexistent object.
Also, I believe the offset partial specialization of _CachedPosition
needs a change to invalidate the source on move.
Re: [PATCH] libstdc++: Fix access issues in elements_view::_Sentinel [PR100631]
On Mon, May 17, 2021 at 12:21 PM Patrick Palka via Gcc-patches
wrote:
>
> using _Base = elements_view::_Base<_Const>;
> sentinel_t<_Base> _M_end = sentinel_t<_Base>();
> @@ -3800,7 +3807,7 @@ namespace views::__adaptor
> requires sized_sentinel_for, iterator_t<_Base2>>
> friend constexpr range_difference_t<_Base>
Preexisting, but this one should be _Base2 - we always want to get the
difference type from the iterator being used.
> operator-(const _Sentinel& __x, const _Iterator<_Const2>& __y)
> - { return __x._M_end - __y._M_current; }
> + { return __x._M_distance_from(__y); }
>
Re: [PATCH] libstdc++: Fix iterator caching inside range adaptors [PR100479]
On Mon, May 17, 2021 at 2:59 PM Patrick Palka wrote:
>
> + constexpr _CachedPosition&
> + operator=(_CachedPosition&& __other) noexcept
> + {
> + if (std::__addressof(__other) != this)
I don't think we need this check - self-move-assigning the underlying
view isn't required to be a no-op, so we should still invalidate.
> + {
> + // Propagate the cached offset, but invalidate the source.
> + this->_M_offset = __other._M_offset;
> + __other._M_offset = -1;
> + }
> + return *this;
> + }
Re: [committed] libstdc++: Add std::is_scoped_enum for C++23
On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++
wrote:
>
> Implement this C++23 feature, as proposed by P1048R1.
>
> This implementation assumes that a C++23 compiler supports concepts
> already. I don't see any point in using preprocessor hacks to detect
> compilers which define __cplusplus to a post-C++20 value but don't
> support concepts yet.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_scoped_enum): Define.
> * include/std/version (__cpp_lib_is_scoped_enum): Define.
> * testsuite/20_util/is_scoped_enum/value.cc: New test.
> * testsuite/20_util/is_scoped_enum/version.cc: New test.
>
> Tested powerpc64le-linux. Committed to trunk.
>
Using __underlying_type breaks for incomplete enumeration types. GCC
doesn't have incomplete scoped enums due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89025 but unscoped ones
exist:
enum E {
x = std::is_scoped_enum_v
};
Re: [committed] libstdc++: Add std::is_scoped_enum for C++23
On Sat, Mar 20, 2021 at 3:58 AM Jonathan Wakely wrote:
>
>
>
> On Sat, 20 Mar 2021, 01:13 Tim Song via Libstdc++,
> wrote:
>>
>> On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++
>> wrote:
>> >
>> > Implement this C++23 feature, as proposed by P1048R1.
>> >
>> > This implementation assumes that a C++23 compiler supports concepts
>> > already. I don't see any point in using preprocessor hacks to detect
>> > compilers which define __cplusplus to a post-C++20 value but don't
>> > support concepts yet.
>> >
>> > libstdc++-v3/ChangeLog:
>> >
>> > * include/std/type_traits (is_scoped_enum): Define.
>> > * include/std/version (__cpp_lib_is_scoped_enum): Define.
>> > * testsuite/20_util/is_scoped_enum/value.cc: New test.
>> > * testsuite/20_util/is_scoped_enum/version.cc: New test.
>> >
>> > Tested powerpc64le-linux. Committed to trunk.
>> >
>>
>> Using __underlying_type breaks for incomplete enumeration types. GCC
>> doesn't have incomplete scoped enums due to
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89025 but unscoped ones
>> exist:
>>
>> enum E {
>> x = std::is_scoped_enum_v
>> };
>
>
> Thanks, I'll just use int then. Maybe not until Monday though.
>
>
Using int avoids the hard error, but it appears to give the wrong
answer (presumably because the is_convertible check fails due to E
being incomplete). This may need to be handled explicitly?
Re: [committed] libstdc++: Make ranges CPOs final and not addressable
CPOs are specified as actual semiregular function objects that can be copied and constructed freely, so it seems a bit hostile to make them final/non-addressable? (It's debatable whether the type of a CPO is a type "specified in the C++ standard library" for which [derivation]/4 would apply.) On Tue, Jun 15, 2021 at 1:34 PM Jonathan Wakely via Gcc-patches wrote: > > This restricts the API of the CPOs and other function objects so they > cannot be misused by deriving from them or taking their addresses. > > Signed-off-by: Jonathan Wakely > > libstdc++-v3/ChangeLog: > > * include/bits/ranges_base.h (ranges::begin, ranges::end) > (ranges::cbegin, ranges::cend, ranges::rbeing, ranges::rend) > (ranges::crbegin, ranges::crend, ranges::size, ranges::ssize) > (ranges::empty, ranges::data, ranges::cdata): Make types final. > Add deleted operator& overloads. > (ranges::advance, ranges::distance, ranges::next, ranges::prev): > Likewise. > * testsuite/std/ranges/headers/ranges/synopsis.cc: Replace > ill-formed & expressions with using-declarations. Add checks for > other function objects. > > Tested powerpc64le-linux. Committed to trunk. >
Re: [committed] libstdc++: Implement LWG 2762 for std::unique_ptr::operator*
That example violates http://eel.is/c++draft/unique.ptr.runtime.general#3
On Thu, Jun 24, 2021 at 1:55 PM Patrick Palka via Gcc-patches
wrote:
>
> On Thu, 24 Jun 2021, Jonathan Wakely via Libstdc++ wrote:
>
> > The LWG issue proposes to add a conditional noexcept-specifier to
> > std::unique_ptr's dereference operator. The issue is currently in
> > Tentatively Ready status, but even if it isn't voted into the draft, we
> > can do it as a conforming extensions. This commit also adds a similar
> > noexcept-specifier to operator[] for the unique_ptr partial
> > specialization.
>
> The conditional noexcept added to unique_ptr::operator[] seems to break
> the case where T is complete only after the fact:
>
> struct T;
> extern std::unique_ptr p;
> auto& t = p[1];
> struct T { };
>
> /include/c++/12.0.0/bits/unique_ptr.h: In instantiation of ‘typename
> std::add_lvalue_reference<_Tp>::type std::unique_ptr<_Tp [],
> _Dp>::operator[](std::size_t) co
> nst [with _Tp = A; _Dp = std::default_delete; typename
> std::add_lvalue_reference<_Tp>::type = A&; std::size_t = long unsigned int]’:
> testcase.cc:5:14: required from here
> /include/c++/12.0.0/bits/unique_ptr.h:658:48: error: invalid use of
> incomplete type ‘struct A’
> 658 |
> noexcept(noexcept(std::declval()[std::declval()]))
> | ~~~^
> testcase.cc:3:8: note: forward declaration of ‘struct A’
> 3 | struct A;
> |^
>
> >
> > Also ensure that all dereference operators for shared_ptr are noexcept,
> > and adds tests for the std::optional accessors modified by the issue,
> > which were already noexcept in our implementation.
> >
> > Signed-off-by: Jonathan Wakely
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/shared_ptr_base.h (__shared_ptr_access::operator[]):
> > Add noexcept.
> > * include/bits/unique_ptr.h (unique_ptr::operator*): Add
> > conditional noexcept as per LWG 2762.
> > * testsuite/20_util/shared_ptr/observers/array.cc: Check that
> > dereferencing cannot throw.
> > * testsuite/20_util/shared_ptr/observers/get.cc: Likewise.
> > * testsuite/20_util/optional/observers/lwg2762.cc: New test.
> > * testsuite/20_util/unique_ptr/lwg2762.cc: New test.
> >
> > Tested powerpc64le-linux. Committed to trunk.
> >
> >
