Otherwise, we'll in turn complain if the nonisolated lazy property was
@objc. This is also invalid, but the goal here is to avoid the source
break until -swift-version 6.
Fixes rdar://141967932.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Instead, use the `%target-swift-5.1-abi-triple` substitution to compile the tests
for deployment to the minimum OS versions required for use of _Concurrency APIs.
This means that:
1. In test cases where minimal is the default (swift 5 without
-warn-concurrency), I added RUN lines for targeted, complete, and complete +
sns.
2. In test cases where complete is the default (swift 6, -warn-concurrency,
specified complete with -strict-concurrency), I added a send non-sendable run
line.
In each of these cases, I added additional expected-* lines as appropriate so
the tests can compile in each mode successfully.
When synthesizing the default initializer for an actor, we'd sometimes hit
a cycle when that initializer needs to chain to NSObject.init. The cycle
only happens because we ask if the initializer we're trying to synthesize
is a convenience init in a scenario which only applies to non-final classes.
Since all actors are effectively "final" classes, it's valid to workaround the
cycle by only asking that initializer question for non-final classes, thus
breaking the cycle.
An @objc async thunk does not need to perform a
hop_to_executor if the native method the thunk is
wrapping is async, since the native method will do
its own hop.
This redundant hop was causing a crash in SILGen
with async actor-instance isolated @objc methods
declared in an actor, because SILGen was not
prepared to add the hop to to `self` within
the @objc thunk.
resolves rdar://80130628
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.
