[flang-commits] [clang] [flang] [llvm] [CLANG][OpenMP] Add support for OpenMP6.0 transparent clause (PR #166810)

[Abhinav Gaba via flang-commits]

================
@@ -17424,6 +17437,52 @@ OMPClause *SemaOpenMP::ActOnOpenMPThreadsetClause(OpenMPThreadsetKind Kind,
       OMPThreadsetClause(Kind, KindLoc, StartLoc, LParenLoc, EndLoc);
 }
 
+static OMPClause *CreateTransparentClause(Sema &SemaRef, ASTContext &Ctx,
+                                          Expr *ImpexTypeArg,
+                                          SourceLocation StartLoc,
+                                          SourceLocation LParenLoc,
+                                          SourceLocation EndLoc) {
+  ExprResult ER = SemaRef.DefaultLvalueConversion(ImpexTypeArg);
+  if (ER.isInvalid())
+    return nullptr;
+
+  return new (Ctx) OMPTransparentClause(ER.get(), StartLoc, LParenLoc, EndLoc);
+}
+
+OMPClause *SemaOpenMP::ActOnOpenMPTransparentClause(Expr *ImpexTypeArg,
+                                                    SourceLocation StartLoc,
+                                                    SourceLocation LParenLoc,
+                                                    SourceLocation EndLoc) {
+  QualType Ty = ImpexTypeArg->getType();
+
+  if (const auto *TT = Ty->getAs<TypedefType>()) {
+    const TypedefNameDecl *TypedefDecl = TT->getDecl();
+    llvm::StringRef TypedefName = TypedefDecl->getName();
+    IdentifierInfo &II = SemaRef.PP.getIdentifierTable().get(TypedefName);
+    ParsedType ImpexTy =
+        SemaRef.getTypeName(II, StartLoc, SemaRef.getCurScope());
+    if (!ImpexTy.getAsOpaquePtr() || ImpexTy.get().isNull()) {
+      SemaRef.Diag(StartLoc, diag::err_omp_implied_type_not_found)
+          << TypedefName;
+      return nullptr;
+    }
+    return CreateTransparentClause(SemaRef, getASTContext(), ImpexTypeArg,
+                                   StartLoc, LParenLoc, EndLoc);
+  }
+
+  if (Ty->isEnumeralType())
----------------
abhinavgaba wrote:

I think it's a quality-of-implementation/usability vs maintainability decision. From OpenMP's point of view, the impex-type argument does not need to be a constant, so a user can have something like:

```c
// (A)
int var = 123;
... transparent(var)
```

in which case, this cannot be diagnosed at compile-time, so the runtime will have to handle it.

Unlike `allocator_handle` type, for which OpenMP says it can be a scoped enum in C++, which would prevent such cases involving using an integer as an argument, there is no such wording for `OpenMP impex type`, which means such implicit conversion is allowed even for C++ as it's just defined as a `typedef enum` in omp.h.

While for cases where the user specifies a constant, it can theoretically be diagnosed at compile-time, it's not mandatory as the runtime should do it eventually anyway.

It is however more user-friendly to diagnose at compile-time, at the cost of adding some redundancy.

```c
// (B)
... transparent(123) // Can be diagnosed at compile-time, but if not,
                     // the runtime can do it since it has to handle (A) anyway.
```


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