Tests for deprecated features.

[khronosgroup]

Tests for deprecated features.

[keryell]

That is an interesting question.
While it makes sense to test for something expected to work even as deprecated, on the other hand it put some legacy burden on new implementers of SYCL2020 to be conformant.
So, I do not have a clear answer in a world with limited resources on different sides.

[psalz]

Why should deprecated APIs be treated any different from regular APIs (by introducing a separate "category")? Other than maybe surrounding them with a #pragma GCC diagnostic ignored "-Wdeprecated-declarations" , I see no reason why they couldn't just live next to the other tests for a particular feature.

Regarding that point, #163 should probably not have removed the tests for .has_extension() , but rather added a separate case for .has().

Edit: Maybe we could introduce helper macros like CTS_SUPPRESS_2020_DEPRECATIONS_START / CTS_SUPPRESS_2020_DEPRECATIONS_STOP to make the reason for ignoring diagnostics more explicit.

[fraggamuffin]

Sept 9:

• do impl have to impl deprecated feature to be conformant? they do
• its a warning to user that it could be removed in future
• introduce way to turn off deprecation warning in CTS seems reasonable
• have a pragma for conditional compilation or to don't warn about deprecated features
• OPenCL header has the same feature to remove the warning but its only C API
• split CTS between deprecated and non-deprecated?
• We can hide tests for deprecated feature under SYCL_CTS_ENABLE_FULL_CONFORMANCE option.
• App A3 device info descriptors is still there
• RK compile list of PR to revert and PK to make adjustments

[fraggamuffin]

not critical
but need control on duplicated features in CTS