The previous message was just suggesting unchecked Sendable, but instead
we should be suggesting to add final to the class. We also don't
outright suggest using unchecked Sendable -- following
https://github.com/swiftlang/swift/pull/81738 precedent.
Resolves rdar://155790695
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
The main effect of this change is that diagnostics about Sendable
conformances now follow the same minimal/full logic used for other
Sendable diagnostics, rather than having their own separate
computation.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
Parse and provide semantic checking for '@unchecked Sendable', for a
Sendable conformance that doesn't perform additional semantic checks
for correctness.
Part of rdar://78269000.
- Introduce an UnownedSerialExecutor type into the concurrency library.
- Create a SerialExecutor protocol which allows an executor type to
change how it executes jobs.
- Add an unownedExecutor requirement to the Actor protocol.
- Change the ABI for ExecutorRef so that it stores a SerialExecutor
witness table pointer in the implementation field. This effectively
makes ExecutorRef an `unowned(unsafe) SerialExecutor`, except that
default actors are represented without a witness table pointer (just
a bit-pattern).
- Synthesize the unownedExecutor method for default actors (i.e. actors
that don't provide an unownedExecutor property).
- Make synthesized unownedExecutor properties `final`, and give them
a semantics attribute specifying that they're for default actors.
- Split `Builtin.buildSerialExecutorRef` into a few more precise
builtins. We're not using the main-actor one yet, though.
Pitch thread:
https://forums.swift.org/t/support-custom-executors-in-swift-concurrency/44425
Actor inheritance was removed in the second revision of SE-0306. Remove
the ability to inherit actors.
Note that this doesn't fully eliminate all vestigates of inheritance
from actors. There are simplifications that need to be performed
still, e.g., there's no need to distinguish
designated/convenience/required initializers. That will follow.
The backs out of some early decisions we made about actor layout
that we don't need. Custom actors will use a different approach.
This should suffice for the remainder of rdar://70146827.
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
This patch cleans up how we emit the errors for disallowing the
properties and methods of an actor to be applied to the protocol
conformance. Rather than having multiple error messages for each case,
we keep one error message saying that the actor-isolated
method/variable/what-have-you cannot be used to satisfy a protocol
requirement, then allow multiple notes with fix-its to allow the
programmer to choose what they want to do. The notes have a better
description of what each option does.
With actor isolation checking for protocol witnesses moved out of the
witness-matching phase, move the corresponding diagnostics from notes
(that would have been on the "type does not conform" error) to
freestanding errors.
Actor classes are by definition new code, so only perform inference of
@asyncHandler from a protocol requirement to witnesses when those
witnesses are within an actor class. This is partly because
@asyncHandler might not have reasonable semantics outside of actor
classes anywhere (where would you execute the detached task?), and
partly because it is a source-compatibility problem due to the
combination of...
1) Inferring @asyncHandler on imported Objective-C protocol methods for
existing protocols,
2) Inferring @asyncHandler from those protocol methods to an existing
method in a class that conforms to that protocol, and
3) Using an API that is now overloaded for both synchronous and
asynchronous callers will end up preferring the asynchronous version,
then fail due to a missing "await".
The individual steps here are all reasonable, but the result is a
source break, so back off on @asyncHandler inference for witnesses
outside of actor classes. New code gets the more-asynchronous behavior
for free.
When an actor class has its `enqueue(partialTask:)` implicitly
synthesized, also synthesize a stored property for the actor's queue.
The type of the property is defined by the _Concurrency library
(`_DefaultActorQueue`), and it will be initialized with a call to
`_defaultActorQueueCreate` (also provided by the _Concurrency
library).
Also synthesize the body of the implicitly-generated
`enqueue(partialTask:)`, which will be a call to
`_defaultActorQueueEnqueuePartialTask(actor:queue:partialTask:)`.
Together, all of these allow us to experiment with the form of the
queue and the queue operation without affecting the type checker.
When `enqueue(partialTask:)` is not implicitly synthesized, the queue
storage is not synthesized either. In such cases, the user has taken
over the execution of tasks for the actor, rather than using the
default implementation.
Introduce a new Actor protocol, which is a class-bound protocol with only
one requirement:
func enqueue(partialTask: PartialAsyncTask)
All actor classes implicitly conform to this protocol, and will synthesize
a (currently empty) definition of `enqueue(partialTask:)` unless a suitable
one is provided explicitly.
