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

[Tom Honermann 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");
----------------
tahonermann wrote:

I pushed changes to replace the call to `llvm::report_fatal_error()` with `assert()` following discussion with other colleagues. I still disagree with this direction. As a user, I would much prefer that the compiler fail catastrophically than continue merrily along generating a binary that doesn't behave as expected (In these days of safety consciousness, we would really rather continue into UB land than abort? Really?) . I acknowledge such eventualities will only occur if we fail to properly diagnose elsewhere, so the stakes are hopefully not so high. Still, I reserve the right to be unhappy and say, "I told you so" while vigorously wagging a finger if we end up getting a bug report detailing someone's difficult experience debugging why their application was mysteriously invoking the wrong SYCL kernel. I'm now resolving this conversation.

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