[onedpl][ranges][productization] Range API productization, MVP plan, Part 2

[MikeDvorskiy]

[onedpl][ranges][productization] Range API productization, MVP plan, Part 2: count, count_if, equal, is_sorted, sort, stable_sort, min_element, max_element, copy, copy_if, merge.

[dmitriy-sobolev]

I've found that the tests for ranges fail for clang++14 when using libstdc++. This issue llvm/llvm-project#52696 looks the same. Basing on the reproducer from the issue, it affects clang++15 and older. I was not about to find a workaround after a quick look.

With libc++ I got this issue:

/oneDPL/test/parallel_api/ranges/std_ranges_transform.pass.cpp:77:28: error: use of undeclared identifier '__cpp_lib_ranges'
    return TestUtils::done(_ENABLE_STD_RANGES_TESTING);
                           ^
/oneDPL/test/support/test_config.h:120:36: note: expanded from macro '_ENABLE_STD_RANGES_TESTING'
#define _ENABLE_STD_RANGES_TESTING _ONEDPL_CPP20_RANGES_PRESENT
                                   ^
/oneDPL/include/oneapi/dpl/internal/../pstl/onedpl_config.h:307:43: note: expanded from macro '_ONEDPL_CPP20_RANGES_PRESENT'
#    define _ONEDPL_CPP20_RANGES_PRESENT (__cpp_lib_ranges >= 201911L)

This definitely should be fixable.

Upd. the first issue is related to the fact that clang++15 and older do not support range adapters. Reproducer: https://godbolt.org/z/hqd9qrfch. I've turned off the ranges with these compilers in MVP1.

Upd. the second issue is fixed in MVP1

[dmitriy-sobolev]

Minor suggestion: align template parameter order with the function argument order.

Suggested change

	template <typename _BackendTag, typename _ExecutionPolicy, typename _R, typename _Proj, typename _Comp>
	template <typename _BackendTag, typename _ExecutionPolicy, typename _R, typename _Comp, typename _Proj>

[dmitriy-sobolev]

We need separate patterns for std::ranges::sort due to std::indirectly_swappable requirement, which implies the use of std::ranges::iter_swap, which can be customized externally.

oneapi::dpl::__internal::__pattern_sort will use std::sort as a brick, which uses std::sort as a brick instead of std::range::sort.

[dmitriy-sobolev]

I've added such patterns in this patch:
add_sort_ranges_patterns.patch

@rarutyun, lets discuss whether we want to include this patch in this PR or not.

[dmitriy-sobolev]

I've created a branch containing these changes: #1815

[rarutyun]

Assuming the CI (except clang-format) is green I am totally for merging this PR. There might be some small improvements/fixes before code freeze but we definitely don't have enough time to make any significant improvements