[Bug c++/95578] New: std::ranges::copy and std::views::take_while don't want to play together

[Bug c++/95578] New: std::ranges::copy and std::views::take_while don't want to play together

[gcc-bugs at marehr dot dialup.fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578

            Bug ID: 95578
           Summary: std::ranges::copy and std::views::take_while don't
                    want to play together
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc-team,

the following code does not compile (10.1.0 and trunk)

```c++
#include <ranges>
#include <algorithm>

int main()
{
    std::vector<int> v{};
    // auto && rng = v; // does work
    auto && rng = v | std::views::take_while([](auto &&){return true;}); //
does not work

    std::vector<int> rng_copy{};
    std::ranges::copy(rng, std::back_inserter(rng_copy));
    return 0;
}
```
https://godbolt.org/z/nmRQgo

[Bug c++/95578] std::ranges::copy and std::views::take_while don't want to play together

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-06-09
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Confirmed.  When writing the normal/reverse/move iterator optimizations for the
ranges algos, I wrongly assumed that if the begin() of a range is a
normal_iterator (or reverse_iterator, or move_iterator) then the end() must be,
too.  But as this testcase shows, it's perfectly valid to have a range whose
begin() is a normal_iterator but its end() is not.  So these optimizations
should check that the iterator and sentinel have the same type before
proceeding.

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.2

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:a73051a0ea9ce8281e748a74dd924a6eb8fb3723

commit r11-1186-ga73051a0ea9ce8281e748a74dd924a6eb8fb3723
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Jun 10 17:37:53 2020 -0400

    libstdc++: Fix some ranges algos optimizations [PR95578]

    ranges::copy and a number of other ranges algorithms have unwrapping
    optimizations for iterators of type __normal_iterator, move_iterator and
    reverse_iterator.  But in the checks that guard these optimizations we
    currently only test that the iterator of the iterator/sentinel pair has
    the appropriate type before proceeding with the corresponding
    optimization, and do not also test the sentinel type.

    This breaks the testcase in this PR because this testcase constructs via
    range adaptors a range whose begin() is a __normal_iterator and whose
    end() is a custom sentinel type, and then performs ranges::copy on it.
    From there we bogusly perform the __normal_iterator unwrapping
    optimization on this iterator/sentinel pair, which immediately leads to
    a constraint failure since the custom sentinel type does not model
    sentinel_for<int*>.

    This patch fixes this issue by refining each of the problematic checks
    to also test that the iterator and sentinel types are the same before
    applying the corresponding unwrapping optimization.  Along the way, some
    code simplifications are made.

    libstdc++-v3/ChangeLog:

            PR libstdc++/95578
            * include/bits/ranges_algo.h (__lexicographical_compare_fn):
            Also check that the iterator and sentinel have the same type before
            applying the unwrapping optimization for __normal_iterator.
            Split the check into two, one for the first iterator/sentinel
            pair and another for second iterator/sentinel pair.  Remove uses
            of __niter_base, and remove uses of std::move on a
            __normal_iterator.
            * include/bits/ranges_algobase.h (__equal_fn): Likewise.
            (__copy_or_move): Likewise.  Perform similar adjustments for
            the reverse_iterator and move_iterator optimizations.  Inline
            the checks into the if-constexprs, and use using-declarations to
            make them less visually noisy.  Remove uses of __niter_wrap.
            (__copy_or_move_backward): Likewise.
            * testsuite/25_algorithms/copy/95578.cc: New test.
            * testsuite/25_algorithms/copy_backward/95578.cc: New test.
            * testsuite/25_algorithms/equal/95578.cc: New test.
            * testsuite/25_algorithms/lexicographical_compare/95578.cc: New
test.
            * testsuite/25_algorithms/move/95578.cc: New test.
            * testsuite/25_algorithms/move_backward/95578.cc: New test.

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:3e9261f0e013108135bf09f0f91b279b9c5cbd9e

commit r10-8271-g3e9261f0e013108135bf09f0f91b279b9c5cbd9e
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Jun 10 17:37:53 2020 -0400

    libstdc++: Fix some ranges algos optimizations [PR95578]

    ranges::copy and a number of other ranges algorithms have unwrapping
    optimizations for iterators of type __normal_iterator, move_iterator and
    reverse_iterator.  But in the checks that guard these optimizations we
    currently only test that the iterator of the iterator/sentinel pair has
    the appropriate type before proceeding with the corresponding
    optimization, and do not also test the sentinel type.

    This breaks the testcase in this PR because this testcase constructs via
    range adaptors a range whose begin() is a __normal_iterator and whose
    end() is a custom sentinel type, and then performs ranges::copy on it.
    From there we bogusly perform the __normal_iterator unwrapping
    optimization on this iterator/sentinel pair, which immediately leads to
    a constraint failure since the custom sentinel type does not model
    sentinel_for<int*>.

    This patch fixes this issue by refining each of the problematic checks
    to also test that the iterator and sentinel types are the same before
    applying the corresponding unwrapping optimization.  Along the way, some
    code simplifications are made.

    libstdc++-v3/ChangeLog:

            PR libstdc++/95578
            * include/bits/ranges_algo.h (__lexicographical_compare_fn):
            Also check that the iterator and sentinel have the same type before
            applying the unwrapping optimization for __normal_iterator.
            Split the check into two, one for the first iterator/sentinel
            pair and another for second iterator/sentinel pair.  Remove uses
            of __niter_base, and remove uses of std::move on a
            __normal_iterator.
            * include/bits/ranges_algobase.h (__equal_fn): Likewise.
            (__copy_or_move): Likewise.  Perform similar adjustments for
            the reverse_iterator and move_iterator optimizations.  Inline
            the checks into the if-constexprs, and use using-declarations to
            make them less visually noisy.  Remove uses of __niter_wrap.
            (__copy_or_move_backward): Likewise.
            * testsuite/25_algorithms/copy/95578.cc: New test.
            * testsuite/25_algorithms/copy_backward/95578.cc: New test.
            * testsuite/25_algorithms/equal/95578.cc: New test.
            * testsuite/25_algorithms/lexicographical_compare/95578.cc: New
test.
            * testsuite/25_algorithms/move/95578.cc: New test.
            * testsuite/25_algorithms/move_backward/95578.cc: New test.

    (cherry picked from commit a73051a0ea9ce8281e748a74dd924a6eb8fb3723)

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 10.2+, thanks for the bug report.

[Bug libstdc++/95578] std::ranges::copy and std::views::take_while don't want to play together

[gcc-bugs at marehr dot dialup.fu-berlin.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95578

--- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for the quick response and quick fix :)