[clang] [OpenACC] Implement compound construct parsing (PR #72692)

[Erich Keane via cfe-commits]

================
@@ -50,6 +52,35 @@ OpenACCDirectiveKind ParseOpenACCDirectiveKind(Parser &P) {
   if (DirKind == OpenACCDirectiveKind::Invalid)
     P.Diag(FirstTok, diag::err_acc_invalid_directive) << FirstTokSpelling;
 
+  // Combined Constructs allows parallel loop, serial loop, or kernels loop. Any
+  // other attempt at a combined construct will be diagnosed as an invalid
+  // clause.
+  Token SecondTok = P.getCurToken();
+  switch (DirKind) {
+  default:
+    // Nothing to do except in the below cases, as they should be diagnosed as
+    // a clause.
+    break;
+  case OpenACCDirectiveKind::Parallel:
+    if (P.getPreprocessor().getSpelling(SecondTok) == "loop") {
+      P.ConsumeToken();
+      return OpenACCDirectiveKind::ParallelLoop;
+    }
+    break;
+  case OpenACCDirectiveKind::Serial:
+    if (P.getPreprocessor().getSpelling(SecondTok) == "loop") {
+      P.ConsumeToken();
+      return OpenACCDirectiveKind::SerialLoop;
+    }
+    break;
+  case OpenACCDirectiveKind::Kernels:
+    if (P.getPreprocessor().getSpelling(SecondTok) == "loop") {
+      P.ConsumeToken();
+      return OpenACCDirectiveKind::KernelsLoop;
+    }
+    break;
+  }
----------------
erichkeane wrote:

That changes the meaning semantically, but I like the idea of inverting the check.  I initially shied away from it because of the additional cost (calculating the spelling and the string comparison on every directive, not just in the special cases), but perhaps that isn't so bad.  Using the `GetOpenACCDirectiveKind` here seems like doing significantly more work than necessary in every directive, so I think there is value to sticking to a single string comparison.

That said, I've done the check inversion in the next patch.

https://github.com/llvm/llvm-project/pull/72692