The rule is that you cannot form a key path to
any actor-isolated members. This avoids issues
with having to track whether a keypath does
something 'async' in the KeyPath type.
An actor can have @objc members, but not if those members are "actor-isolated",
i.e., not accessible from outside the actor according to the fundamental design
of actors. For example, a sync function is considered actor-isolated since it
needs special protection, so it cannot be @objc.
But, we now have special capabilities to treat sync actor functions as
implicitly async at use-sites outside of the actor. Does this mean that we can
now allow sync actor functions to be @objc? No. Because the implicitly-async
functionality does not extend to the world of ObjC: it simply would not be
feasible to implement it there.
Thus, I've added some extra regression-test coverage to handle these cases,
and clarified the assertion here to not confuse others.
This patch updates the `actor class` spelling to `actor` in almost all
of the tests. There are places where I verify that we sanely handle
`actor` as an attribute though. These include:
- test/decl/class/actor/basic.swift
- test/decl/protocol/special/Actor.swift
- test/SourceKit/CursorInfo/cursor_info_concurrency.swift
- test/attr/attr_objc_async.swift
- test/ModuleInterface/actor_protocol.swift
The code in #selector doesn't execute, so don't perform actor-isolation
checking in there. It also happens to have subexpressions that don't
really follow the rules for references to instance methods, so
avoiding this checking eliminates both compiler crashes and
been spurious errors.
Fixes rdar://72945343.
