[SYCL] Add an user-defined copy constructor

[eunakim0103]

The static verifier reported a missing user defined copy constructor as delete to match to the existing assignment operator.

[againull]

Can we =delete copy constructor as well, instead of adding both assignment and copy?

[againull]

And probably we should cover all related cases from here https://github.com/intel/llvm/pull/10452/files in one PR.

[eunakim0103]

Can we =delete copy constructor as well, instead of adding both assignment and copy?

We could. "delete" or "default". I thought it would be better to have default constructor and assignment operator then deleting them. @againull, do you prefer to delete?

[againull]

Can we =delete copy constructor as well, instead of adding both assignment and copy?

We could. "delete" or "default". I thought it would be better to have default constructor and assignment operator then deleting them. @againull, do you prefer to delete?

Considering the discussion in PR #10452 I believe "delete" is preferrable.

[eunakim0103]

Can we =delete copy constructor as well, instead of adding both assignment and copy?

We could. "delete" or "default". I thought it would be better to have default constructor and assignment operator then deleting them. @againull, do you prefer to delete?

Considering the discussion in PR #10452 I believe "delete" is preferrable.

We can leave the assignment operator (=) as "delete". The static verifier tool reported missing copy constructor with PR #10452 fix and we need to add a copy constructor.

To clear, which one do you do think it would be better?

1. copy & = both "delete"
2. copy & = both "default"
3. ="default" or "delete" & no copy constructor <-- this was reported as missing a copy constructor

[eunakim0103]

The two copy-assignment operators that were "delete" have been changed to "default"
in #10886

Here's the description in PR.

As part of version two of sycl_ext_oneapi_sub_group_mask the copy-assignment operator is defined as default but were deleted as part of #10564. This changes them to default ahead of version 2 of the extension to avoid regressions.

I thought it would be good have default copy = rather than delete them.

[againull]

The two copy-assignment operators that were "delete" have been changed to "default" in #10886

Here's the description in PR.

As part of version two of sycl_ext_oneapi_sub_group_mask the copy-assignment operator is defined as default but were deleted as part of #10564. This changes them to default ahead of version 2 of the extension to avoid regressions.

I thought it would be good have default copy = rather than delete them.

So, why operator= was deleted for classes in https://github.com/intel/llvm/pull/10452/files? I am proposing to apply same logic here and do:

1. copy & = both "delete"

[eunakim0103]

The two copy-assignment operators that were "delete" have been changed to "default" in #10886
Here's the description in PR.

As part of version two of sycl_ext_oneapi_sub_group_mask the copy-assignment operator is defined as default but were deleted as part of #10564. This changes them to default ahead of version 2 of the extension to avoid regressions.

I thought it would be good have default copy = rather than delete them.

So, why operator= was deleted for classes in https://github.com/intel/llvm/pull/10452/files? I am proposing to apply same logic here and do:

1. copy & = both "delete"

Yes, we can do that. Will fix both. Thanks!