Simplify new_kernel_name implementation in tests

[SergeyKopienko]

This PR centralizes and simplifies the new_kernel_name machinery for tests by moving common templates into a single header and removing redundant definitions elsewhere.

• Introduce uniq_kernel_index, unique_kernel_name, and new_kernel_name in utils_sycl_defs.h
• Remove duplicated template definitions from utils_invoke.h, test_dynamic_selection_utils.h, and test_dynamic_load_utils.h
• Include utils_sycl_defs.h where those utilities were previously declared inline

[danhoeflinger]

Can we take this opportunity to consolidate this to a single instance of this implementation?

[danhoeflinger]

Is there a reason there are 2 nested copies of TestUtils::unique_kernel_name here?
Are they redundant? If we change the number from 0 to 1, in your code, do both copies of the TestUtils::unique_kernel_name change their number? If so, there is some other issue we can fix I think.

[SergeyKopienko]

Is there a reason there are 2 nested copies of TestUtils::unique_kernel_name here? Are they redundant? If we change the number from 0 to 1, in your code, do both copies of the TestUtils::unique_kernel_name change their number? If so, there is some other issue we can fix I think.

In any case now new_kernel_name is implemented in this PR exactly as

template <typename Policy>
using __policy_kernel_name = typename ::std::decay_t<Policy>::kernel_name;

[danhoeflinger]

In any case now new_kernel_name is implemented in this PR exactly as

template <typename Policy>
using __policy_kernel_name = typename ::std::decay_t<Policy>::kernel_name;

Yes, but in your "after" result, we still have 2 nested TestUtils::unique_kernel_name. Perhaps that is because of nesting in the test function you are using to generate the "before" and "after", and is required and intentional.

[SergeyKopienko]

In any case now new_kernel_name is implemented in this PR exactly as

template <typename Policy>
using __policy_kernel_name = typename ::std::decay_t<Policy>::kernel_name;

Yes, but in your "after" result, we still have 2 nested TestUtils::unique_kernel_name. Perhaps that is because of nesting in the test function you are using to generate the "before" and "after", and is required and intentional.

As example I have used the policy creation at

oneDPL/test/parallel_api/algorithm/alg.sorting/alg.binary.search/binary.search/binary_search.pass.cpp

Line 74 in f5bd154

auto new_policy = make_new_policy<new_kernel_name<Policy, 0>>(exec);

:

auto new_policy = make_new_policy<new_kernel_name<Policy, 0>>(exec);

at this point the type of exec is oneapi::dpl::execution::__dpl::device_policy<TestUtils::unique_kernel_name<test_binary_search<unsigned long long>,0>> &
and the type of new_policy is
oneapi::dpl::execution::__dpl::device_policy<TestUtils::unique_kernel_name<TestUtils::unique_kernel_name<test_binary_search<unsigned long long>,0>,0>>

So I think it's the question for test environment staff, not for new_kernel_name :

• this type name starts from

template <::std::size_t CallNumber = 0>
struct invoke_on_all_hetero_policies::operator()(Op op, Args&&... rest)

[Copilot]

Pull Request Overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull Request Overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull Request Overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[danhoeflinger]

As long as tests work after this, the changes LGTM.
(may require more than the per-commit CI to cover this well either locally or in the CI)