<algorithm>: The bidirectional common range version of ranges::find_end returns the wrong value

[hewillk]

STL/stl/inc/algorithm

Lines 2361 to 2372 in 8833270

	for (auto _Candidate = _Last1;; --_Candidate) { // try a match at _Candidate
	auto _Next1 = _Candidate;
	auto _Next2 = _Last2;
	for (;;) { // test if [_First2, _Last2) is a suffix of [_First1, _Candidate)
	if (_First2 == _Next2) { // match found
	return {_STD move(_First1), _STD move(_Last1)};
	}
	if (_First1 == _Next1) {
	// [_First1, _Candidate) is shorter than [_First2, _Last2); remaining candidates nonviable
	return {_Last1, _Last1};
	}

IIUC, the first return statement should return {std::move(_Next1), std::move(_Candidate)};.

Test case:

#include <ranges>
#include <algorithm>

constexpr auto find = [] {
  auto r = std::views::iota(0, 2)
         | std::views::filter([](int) { return true; });
  auto s = std::ranges::find_end(r, std::views::single(1));
  return s.front() == 1;
}();

static_assert(find);

https://godbolt.org/z/1dzq8Pe1K

[fsb4000]

I tried "possible implementation" from https://en.cppreference.com/w/cpp/algorithm/ranges/find_end
it gives the answer as gcc. So yeah, I think you're right.

[CaseyCarter]

Yes, this is completely bogus and lacking test coverage. We went light on some test coverage for range algorithms that were virtually transcriptions of the std flavor with the expectation that the guts were known good and the interface bits were likely to be correct if they compiled. That policy obviously failed here, and we should have full test coverage of ranges::find_end.