nd defines the value_type, pointer and reference of output_iterator_wrapper
to void but leaves alone its difference_type. Tested on x86_64-pc-linux-gnu.
OK for 10, 11 and trunk, thanks.
-- >8 --
Subject: [PATCH] libstdc++: Avoid hard error in ranges::unique_copy [PR100770]
Here, in the const
t", perhaps?
Works for me. Here's v2, which factors out the condition into a concept
and defines the value_type, pointer and reference of output_iterator_wrapper
to void but leaves alone its difference_type. Tested on x86_64-pc-linux-gnu.
-- >8 --
Subject: [PATCH] libstdc++: Avoid h
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 i
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 ca
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_
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
On Wed, 26 May 2021 at 18:00, Patrick Palka via Libstdc++
wrote:
>
> When input_iterator<_Out> isn't satisfied, we need to avoid substituting
> into iter_value_t<_Out> because the latter isn't necessarily
> well-formed in that case. To that end, this patch rewrites the
> problematic condition in
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
When input_iterator<_Out> isn't satisfied, we need to avoid substituting
into iter_value_t<_Out> because the latter isn't necessarily
well-formed in that case. To that end, this patch rewrites the
problematic condition in ranges::unique_copy into a nested requirement
which has the correct short-ci
