================
@@ -665,6 +666,101 @@ OutlinedFunctionDecl
*BuildSYCLKernelEntryPointOutline(Sema &SemaRef,
return OFD;
}
+class KernelArgsChecker : public SubobjectVisitor<KernelArgsChecker> {
+ SemaSYCL &SemaSYCLRef;
+ bool IsValid = true;
+ using ObjectAccess =
+ llvm::PointerUnion<ParmVarDecl *, CXXBaseSpecifier *, FieldDecl *>;
+ SmallVector<ObjectAccess, 4> ObjectAccessPath;
+
+ void emitObjectAccessPathNotes() {
+ for (auto Parent : ObjectAccessPath) {
+ if (auto *FD = Parent.dyn_cast<FieldDecl *>()) {
+ SemaSYCLRef.Diag(FD->getParent()->getLocation(),
+ diag::note_within_field_of_type)
+ << FD->getParent();
+ } else if (auto *BS = Parent.dyn_cast<CXXBaseSpecifier *>()) {
+ CXXRecordDecl *RD = BS->getType()->getAsCXXRecordDecl();
+ assert(RD);
+ SemaSYCLRef.Diag(BS->getBeginLoc(), diag::note_within_base_of_type)
+ << RD;
+ } else {
+ // Nothing to emit for ParmVarDecl since its location just points to
+ // skep-attributed function template.
----------------
tahonermann wrote:
I appreciate that concern, but I think we should include the parameter in the
diagnostic, at least for now. The rationale is that we don't currently have a
way to link the diagnostic to an actual invocation of a SYCL kernel entry point
function; which is what we would ideally do. In the common case where the
kernel object is produced from a lambda expression at the call sight, the
diagnostics will likely point to captures there, but that isn't assured. By
including the parameter in the diagnostic, we at least ensure the user has a
way to track back through the template instantiation stack; even if it is an
ugly experience. The parameter details might prove useful to SYCL RT authors as
well.
We should explore better options at some point. There are at least a couple of
options we can consider. For example, an attribute the SYCL RT authors place on
the kernel parameter of the SYCL kernel invocation function to explicitly
opt-in to a kernel parameter validity check at that point (which would
circumvent the appearance of a template instantiation stack in the diagnostic).
Or perhaps a similar attribute that just notes the location of a SYCL kernel
invocation call that could be included in the diagnostic (perhaps instead of
the parameter details). But for now, I think we should err on the side of
providing more information, even if it is a little ugly.
https://github.com/llvm/llvm-project/pull/192957
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
