[all-commits] [llvm/llvm-project] 8ea8e7: [SYCL] Basic diagnostics for the sycl_kernel_entry...

[Tom Honermann via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8ea8e7f52908a831ab44ffca1e0c8fe207a409c8
      https://github.com/llvm/llvm-project/commit/8ea8e7f52908a831ab44ffca1e0c8fe207a409c8
  Author: Tom Honermann <tom.honermann at intel.com>
  Date:   2025-01-09 (Thu, 09 Jan 2025)

  Changed paths:
    M clang/include/clang/AST/ASTContext.h
    M clang/include/clang/Basic/Attr.td
    M clang/include/clang/Basic/AttrDocs.td
    M clang/include/clang/Basic/DiagnosticGroups.td
    M clang/include/clang/Basic/DiagnosticSemaKinds.td
    M clang/include/clang/Sema/SemaSYCL.h
    M clang/lib/AST/ASTContext.cpp
    M clang/lib/Sema/SemaDecl.cpp
    M clang/lib/Sema/SemaLambda.cpp
    M clang/lib/Sema/SemaSYCL.cpp
    M clang/lib/Serialization/ASTReaderDecl.cpp
    M clang/test/ASTSYCL/ast-dump-sycl-kernel-entry-point.cpp
    A clang/test/SemaSYCL/sycl-kernel-entry-point-attr-appertainment.cpp
    M clang/test/SemaSYCL/sycl-kernel-entry-point-attr-grammar.cpp
    A clang/test/SemaSYCL/sycl-kernel-entry-point-attr-kernel-name-module.cpp
    A clang/test/SemaSYCL/sycl-kernel-entry-point-attr-kernel-name-pch.cpp
    A clang/test/SemaSYCL/sycl-kernel-entry-point-attr-kernel-name.cpp
    A clang/test/SemaSYCL/sycl-kernel-entry-point-attr-sfinae.cpp

  Log Message:
  -----------
  [SYCL] Basic diagnostics for the sycl_kernel_entry_point attribute. (#120327)

The `sycl_kernel_entry_point` attribute is used to declare a function that
defines a pattern for an offload kernel entry point. The attribute requires
a single type argument that specifies a class type that meets the requirements
for a SYCL kernel name as described in section 5.2, "Naming of kernels", of
the SYCL 2020 specification. A unique kernel name type is required for each
function declared with the attribute. The attribute may not first appear on a
declaration that follows a definition of the function. The function is
required to have a non-deduced `void` return type. The function must not be
a non-static member function, be deleted or defaulted, be declared with the
`constexpr` or `consteval` specifiers, be declared with the `[[noreturn]]`
attribute, be a coroutine, or accept variadic arguments.

Diagnostics are not yet provided for the following:
- Use of a type as a kernel name that does not satisfy the forward
  declarability requirements specified in section 5.2, "Naming of kernels",
  of the SYCL 2020 specification.
- Use of a type as a parameter of the attributed function that does not
  satisfy the kernel parameter requirements specified in section 4.12.4,
  "Rules for parameter passing to kernels", of the SYCL 2020 specification
  (each such function parameter constitutes a kernel parameter).
- Use of language features that are not permitted in device functions as
  specified in section 5.4, "Language restrictions for device functions",
  of the SYCL 2020 specification.

There are several issues noted by various FIXME comments.
- The diagnostic generated for kernel name conflicts needs additional work
  to better detail the relevant source locations; such as the location of
  each declaration as well as the original source of each kernel name.
- A number of the tests illustrate spurious errors being produced due to
  attributes that appertain to function templates being instantiated too
  early (during overload resolution as opposed to after an overload is
  selected).

Included changes allow the `SYCLKernelEntryPointAttr` attribute to be
marked as invalid if a `sycl_kernel_entry_point` attribute is used incorrectly.
This is intended to prevent trying to emit an offload kernel entry point
without having to mark the associated function as invalid since doing so
would affect overload resolution; which this attribute should not do.
Unfortunately, Clang eagerly instantiates attributes that appertain to
functions with the result that errors might be issued for function
declarations that are never selected by overload resolution. Tests have
been added to demonstrate this. Further work will be needed to address
these issues (for this and other attributes).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications