Skip to content

[SYCL] Add sycl_khr_properties container and classification traits - #23075

Open
koparasy wants to merge 1 commit into
intel:syclfrom
koparasy:khr/properties/container-and-traits
Open

[SYCL] Add sycl_khr_properties container and classification traits#23075
koparasy wants to merge 1 commit into
intel:syclfrom
koparasy:khr/properties/container-and-traits

Conversation

@koparasy

@koparasy koparasy commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

This is partial implementation of KhronosGroup/SYCL-Docs#980

@koparasy
koparasy requested a review from a team as a code owner September 1, 2026 21:18
@KseniyaTikhomirova

KseniyaTikhomirova commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

@koparasy the khr extension you are referring to is in draft state. Do you expect it to be reviewed and merged in advance? @dm-vodopyanov, @gmlueck I am not aware about process for this case, could you please clarify?

@koparasy

koparasy commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

@koparasy the khr extension you are referring to is in draft state. Do you expect it to be reviewed and merged in advance? @dm-vodopyanov, @gmlueck I am not aware about process for this case, could you please clarify?

@KseniyaTikhomirova the KHR is expected to be updated and be undrafted (soonish). I don't know the process, but the code is guarded with the __DPCPP_ENABLE_UNFINISHED_KHR_EXTENSIONS, and I have used that in the split-headers KHR as well. So, there is precedent. @dm-vodopyanov do you think we need to wait?

@KseniyaTikhomirova KseniyaTikhomirova left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have found that we have a process for this https://github.com/intel/llvm/blob/sycl/sycl/doc/developer/KHRExtensions.md
To me it looks like draft/unmerged PRs against main are not intended to be merged in advance. Although I don't work with extensions so may be wrong here. @dm-vodopyanov kindly ping for your opinion.

changes itself LGTM, just a few comments

is_property_v<alignment_key::__detail_property_t<alignment_key, int, 4>>);
static_assert(!is_property_v<int> && !is_property_v<enable_profiling_key>);
static_assert(is_property_key_v<enable_profiling_key> &&
is_property_key_v<alignment_key> &&

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

&& for alignment_type_key?


// is_property_key_for / is_property_for / is_property_list_for.
static_assert(is_property_key_for_v<enable_profiling_key, MyClass>);
static_assert(!is_property_key_for_v<enable_profiling_key, OtherClass>);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice to have this check for all types of properties

static_assert(!empty_properties_t::has_property<enable_profiling_key>());

// is_property_list_for over a populated and the empty list.
static_assert(is_property_list_for_v<decltype(p), MyClass>);

@KseniyaTikhomirova KseniyaTikhomirova Sep 3, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we have a diagnostic test for the case when property list contains properties applicable to different classes to check that these traits handle it correctly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants