[clang] [SYCL] The sycl_kernel_entry_point attribute. (PR #111389)

[Aaron Ballman via cfe-commits]

================
@@ -14296,6 +14296,31 @@ void ASTContext::getFunctionFeatureMap(llvm::StringMap<bool> &FeatureMap,
   }
 }
 
+static SYCLKernelInfo BuildSYCLKernelInfo(ASTContext &Context,
+                                          CanQualType KernelNameType,
+                                          const FunctionDecl *FD) {
+  return { KernelNameType, FD };
+}
+
+void ASTContext::registerSYCLEntryPointFunction(FunctionDecl *FD) {
+  assert(!FD->isInvalidDecl());
+  assert(!FD->isDependentContext());
+
+  const auto *SKEPAttr = FD->getAttr<SYCLKernelEntryPointAttr>();
+  assert(SKEPAttr && "Missing sycl_kernel_entry_point attribute");
+
+  CanQualType KernelNameType = getCanonicalType(SKEPAttr->getKernelName());
+  auto IT = SYCLKernels.find(KernelNameType);
+  if (IT != SYCLKernels.end()) {
+    if (!declaresSameEntity(FD, IT->second.GetKernelEntryPointDecl()))
+      llvm::report_fatal_error("SYCL kernel name conflict");
----------------
AaronBallman wrote:

I would not expect a function prefixed with `register` to issue a diagnostic or report a fatal error, I would expect that to be handled by the caller, which is what it looks like the follow-up patch does.

I would expect this to be an assert (and we probably should write some documentation in the internals manual about this). Generally speaking, we prefer:

* issuing a user-facing diagnostic when the user has done something wrong
* using an assert when we think a situation exhibits a Clang developer holding an API incorrectly but we have a reasonable recovery path
* using a fatal error when we think a situation exhibits a Clang developer holding an API incorrectly and there's no possible way to recover from it
* using llvm_unreachable for code paths which should never be reached

This situation seems like an assert because 1) someone called the register function when they shouldn't have, the caller should have reported this as an error to the user (and that's what's happening in a follow-up), and 2) we have a reasonable recovery path, which is to not register the entrypoint.

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