Currently, we have support for SYCL 1.2.1 (also known as SYCL 2017). This patch introduces the start of support for SYCL 2020 mode, which is the latest SYCL standard available at (https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html). This sets the default SYCL to be 2020 in the driver, and introduces the notion of a "default" version (set to 2020) when cc1 is in SYCL mode but there was no explicit -sycl-std= specified on the command line.
Given that it's already scoped to LangOptions, I think a scoped enum adds more noise than anything. It'd make it awkward to name the actual enumerators due to using dates. I think we'd wind up needing to write LangOptions::SYCLMajorVersion::Ver2017 (or something along those lines), which doesn't seem like a huge win to me. WDYT?
FWIW, I think it's because LangOptions::Ver1 would be hard to understand compared to LangOptions::ClangABI::Ver1, whereas in this case, LangOptions::SYCL_2020 is reasonably clear as to what's meant.
I don't think the presence of the word 'Major' in Aaron's version above is the most offensive to me. While I think a good case can be made to make this just SYCLVersion (I don't think we have a minor version?), I think making this a scoped-enum is just going to end up with a worse experience. LangOptions::SYCL_2020 is equally as descriptive as LangOptions::SYCLVersion::Ver2020. And I'd say is even MORE descriptive, since Ver2020 has a very low information density.
To me, those convey the same amount of information, so the use of the scoped enum doesn't get us much (but it would mean we can't use LangOptions::SYCL for any other purpose in the future).