[clang] [OpenACC] Implement Atomic construct variants (PR #73015)

[Erich Keane via cfe-commits]

================
@@ -143,26 +139,25 @@ ParseOpenACCEnterExitDataDirective(Parser &P, Token FirstTok,
              : OpenACCDirectiveKind::ExitData;
 }
 
-OpenACCDirectiveKind ParseOpenACCAtomicDirective(Parser &P) {
+OpenACCAtomicKind ParseOpenACCAtomicKind(Parser &P) {
   Token AtomicClauseToken = P.getCurToken();
 
-  if (AtomicClauseToken.isAnnotation()) {
-    P.Diag(AtomicClauseToken, diag::err_acc_invalid_atomic_clause) << 0;
-    return OpenACCDirectiveKind::Invalid;
-  }
+  // #pragma acc atomic is equivilent to update:
+  if (AtomicClauseToken.isAnnotation())
+    return OpenACCAtomicKind::Update;
 
   std::string AtomicClauseSpelling =
       P.getPreprocessor().getSpelling(AtomicClauseToken);
+  OpenACCAtomicKind AtomicKind = getOpenACCAtomicKind(AtomicClauseSpelling);
 
-  OpenACCDirectiveKind DirKind =
-      getOpenACCAtomicDirectiveKind(AtomicClauseSpelling);
-
-  if (DirKind == OpenACCDirectiveKind::Invalid)
-    P.Diag(AtomicClauseToken, diag::err_acc_invalid_atomic_clause)
-        << 1 << AtomicClauseSpelling;
+  // If we don't know what this is, treat it as 'nothing', and treat the rest of
+  // this as a clause list, which, despite being invalid, is likely what the
+  // user was trying to do.
+  if (AtomicKind == OpenACCAtomicKind::Invalid)
+    return OpenACCAtomicKind::Update;
----------------
erichkeane wrote:

I don't believe so, since this is not diagnosing on it, I'm treating it as just `#pragma acc atomic` and treating the 'rest' as a 'clause-list'.  That way we can diagnose the rest as a 'clauses not allowed here'.

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