The swift_async_name attribute provides a name for a function/method that can be used to call the async overload of this method from Swift. This name specified in this attribute assumes that the last parameter in the function/method its applied to is removed when Swift invokes it, as the the Swift's await/async transformation implicitly constructs the callback.
There's no information in either the attribute definition in Attr.td or in the documentation as to what subject this attribute applies to.
Do you actually need the ?: operator here, or is the conversion from bool sufficient?
Please do not add an additional parameter to the handle functions -- we have a stretch goal of automating more of the switch behavior in SemaDeclAttr.cpp someday and we can only do that if the handle* functions have the same signatures.
This diagnostic is too confusing for me -- a lot of people get parameter/argument confused and so this reads a bit like the *attribute* has too many arguments to it when the real issue is that the signature specified by the attribute argument has too many parameters.
How about: too many parameters in the signature specified by the 'swift_async_name' attribute or something along those lines?
Also, missing tests for the number of arguments passed to the attribute. :-)
It's not clear whether we should have additional tests around other subjects - like, can I apply this attribute to a virtual class function in C++? If you can apply it to a C++ class method, does the implicit this parameter count when checking for the right parameter count?
Should also have a test that the attribute applies to a vanilla function (the only test currently fails because the function has no args, but we should show an explicitly accepted case as well).
Added a subject list to the attribute.
Thanks, I dropped it.
Makes sense, thanks. I added a new function which should hopefully make it easier to automate in the future.
Thanks for the suggestion, I tweaked the warning text .
That's a good point. Added a regular function test as well. We don't need C++ support for this right now, but it might make sense to have it in the future when Swift and C++ interoperate, so added a test for C++ method as well.