[parallel] Fix hpx::nth_element to correctly support C++20 projections and sentinels

[aneek22112007-tech]

This PR fixes a regression where hpx::nth_element ignored user-provided projections in its sequential and parallel paths. It also adds full support for sentinels and aligns the algorithm with C++20 Ranges standards.

Proposed Changes

• CPO Enhancement & Sentinel Support: Upgraded hpx::nth_element_t to natively accept C++20 sentinels (Sent) and projections (Proj) across both sequential and parallel execution overloads.
• Robust Internal Projection Handling: A major issue was that internal helper algorithms (min_element, sort, make_heap) were being called with raw, un-projected comparators. I have standardized all of these internal calls to cleanly wrap the base comparator with hpx::parallel::util::compare_projected, guaranteeing that custom projections are reliably evaluated before any structural comparisons are made.
• Parallel Partition Correctness: Fixed a deeply hidden type-mismatch bug inside the parallel hpx::parallel::detail::partition lambda and pivot9 selection logic. The parallel lambda now correctly evaluates the projected value directly in the traversal loop. This resolves the compiler errors that would trigger whenever users passed in non-trivial type-transforming projections.
• Comprehensive Regression Tests: Added nth_element_projection.cpp to the unit test suite, aggressively testing both struct-member projections (&S::val) and complex type-transforming projections (e.g. mapping internal strings to sizes) across seq, par, and par_unseq execution policies.

Any background context you want to provide?

While working through the parallel algorithm surfaces, I noticed that hpx::nth_element had an incomplete implementation of the C++20 Ranges specification. Specifically, while the CPO technically accepted custom projections, the projection targets were inadvertently dropped when the work was dispatched to internal loops.

This meant that if a user tried to partition a dataset by using a projection that fundamentally altered the type—for example, projecting a list of strings out to their integer lengths—the parallel partitioner would attempt to compare a raw std::string directly against a size_t, failing entirely at compile time.

This PR properly threads the projection directly into the innermost parallel computation lambdas, tightening the CPO layer and effectively hardening hpx::nth_element against modern C++20 usage patterns to match the rest of the HPX algorithms ecosystem!

Checklist

Not all points below apply to all pull requests.

• I have added a new feature and have added tests to go along with it.
• I have fixed a bug and have added a regression test.
• I have added a test using random numbers; I have made sure it uses a seed, and that random numbers generated are valid inputs for the tests.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[StellarBot]

Can one of the admins verify this patch?

[hkaiser]

What is the rationale of this change?

[aneek22112007-tech]

I found that the underlying detail::min_element implementation in minmax.hpp actually fails on macOS Clang when a projection changes the value type (it tries to store the result in a variable of the original element type). Using the wrapped comparison here is a necessary workaround to keep the macOS builds green.

[hkaiser]

Wouldn't it be better to fix the actual problem instead of adding a workaround here?

[hkaiser]

Would you be able to fix this problem (in an independent PR)?

[aneek22112007-tech]

Thanks for the feedback! I've followed your suggestion and separated the core fix for minmax.hpp into an independent Pull Request. You can find it here: #7208.

On this current branch, I have:

Reverted the changes to minmax.hpp to match master.
Restored the wrapped_comp_type workaround in nth_element.hpp specifically for the min_element call.
This keeps this PR functional and 'Green' in CI while the core fix is being reviewed. Once the independent minmax PR is merged, I will come back here to remove the temporary workaround. Let me know if that works for you!

[hkaiser]

@aneek22112007-tech Please pay attention to the CIs. The clang-format CI raised some issue.

[aneek22112007-tech]

Thanks for the review! I’ve gone ahead and consolidated that comparison wrapper at the top of the function to clean things up. I also switched to std::make_heap as suggested. Fixed the formatting issues too, so CI should be all clear now.