Remove usage of deprecated CL/sycl.hpp header and deprecated ::cl::sycl namespace

[illuhad]

Following the discussion in #403, this PR

• removes usages of the CL/sycl.hpp header that has been deprecated in SYCL 2020
• removes usages of the ::cl::sycl namespace that has been deprecated in SYCL 2020

Fixes #403

[dmitriy-sobolev]

DPC++ compiler which is available as a part of Intel® oneAPI toolkits (you can download it e.g. here) does not contain <sycl/sycl.hpp>. The solution is:

#if __has_include(<sycl/sycl.hpp>)
#include <sycl/sycl.hpp>
#else
#include <CL/sycl.hpp>
#endif

However, having such code in a sample is not good idea: it should be as simple as possible. The idea of omitting all the headers is not good either, because we should show which oneDPL headers to include. Having only oneDPL headers will look strange due to incompleteness of the samples. I suggest using <CL/sycl.hpp>. The comment applies to all the samples from documentation/library_guide and examples folders.

@MikeDvorskiy, what do you think?

[illuhad]

Waiting for final decision on this one. I'd like to point out that this is not just a matter of taste; for any other compliant SYCL compiler apart from DPC++ users following the example may get compiler errors if CL/sycl.hpp is used.

[MikeDvorskiy]

Yes, "DPC++ compiler and libraries" does not contain <sycl/sycl.hpp> yet.
Can we distinguish SYCL compiler apart from DPC++ by a compiler version macro?
In that case we can write something like that:

#if defined(__INTEL_LLVM_COMPILER) && SYCL_LANGUAGE_VERSION < "version_value"
#include <CL/sycl.hpp>
#else
#include <sycl/sycl.hpp>
#endif

[MikeDvorskiy]

Regarding the examples. I think we may(or even must) omit <sycl/sycl.hpp> in the examples and other user's code which uses OneDPL, because the SYCL main header should be included once, within OneDPL library. For example, here https://github.com/oneapi-src/oneDPL/blob/main/include/oneapi/dpl/pstl/hetero/dpcpp/sycl_defs.h#L24
So, when a user includes any OneDPL public header, he gets SYCL library inclusion implicitly.

[dmitriy-sobolev]

@MikeDvorskiy, GitHub version of DPC++ has both <sycl/sycl.hpp> and <CL/sycl.hpp> while DPC++ supplied as a part of Intel® oneAPI toolkits has only <CL/sycl.hpp>.
What is benefit of using:

#if defined(__INTEL_LLVM_COMPILER) && SYCL_LANGUAGE_VERSION < "version_value"
#include <CL/sycl.hpp>
#else
#include <sycl/sycl.hpp>
#endif

instead of:

#if __has_include(<sycl/sycl.hpp>)
#include <sycl/sycl.hpp>
#else
#include <CL/sycl.hpp>
#endif

?

Meanwhile, the second approach does not require specifying version of the macro and its uplifting if necessary.

[dmitriy-sobolev]

I discussed the thread with @MikeDvorskiy offline. We agreed on the following:

• Get rid of inclusion of sycl.hpp in the examples and the guide.
• Use the approach with __has_include in sycl_defs.h.

[dmitriy-sobolev]

As the issue has been already addressed (see #403), I am closing this PR.

Anyway, thank you, @illuhad. The adjustments made separately were inspired by this PR. If you wish to be mentioned as a contributor, create a PR with the changes in https://github.com/oneapi-src/oneDPL/blob/main/CREDITS.txt. It may have a note like this one: "Identified the issue with non-compliant namespaces and headers (SYCL 2020), and submitted an extensive change request, which served as a basis for the finalized solution.".