================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
