To help support incremental adoption of the concurrency model, a number
of concurrency-related diagnostics are enabled only in "new" code that
takes advantage of concurrency features---async, @concurrent functions,
actors, etc. This warning flag opts into additional warnings that better
approximate the eventual concurrency model, and which will become
errors a future Swift version, allowing one to both experiment with
the full concurrency model and also properly prepare for it.
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.
* [Sema]: Add Codable synthesis for enums with associated values
* Incorporate review feedback for enum Codable synthesis
* Implement enum specific versions of existing Codable tests
* Encode parameterless enum cases as
* Add test for overloaded case identifiers
* Align code generation with latest proposal revision
* Put enum codable derivation behind flag
* clang-format sources
* Address review feedback and fix tests
* Add diagnostic for conflicting parameter identifiers
* Restructure code after rebase
Make both Error and CodingKey conform to ConcurrentValue, so that
thrown errors always conform to ConcurrentValue. Downgrade (to
warnings) and ConcurrentValue-related diagnostics that are triggered
by this change in existing Error and CodingKey-conforming types to
reduce the impact on source compatibility.
The order of diagnostic emission absolutely does not matter. What this transaction was actually doing was suppressing valid diagnostics. This is a deeply unsound thing to do since if errors are emitted but Codable synthesis succeeds then invalid code can make its way past Sema.
rdar://74392492
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 old fixit mistakenly used getLoc() instead of getEndLoc() on the
type repr, which for simple identifiers will do the right thing. For
compound ones like `[T]`, it instead points inside of the repr inside
which leads to nonsensical fixes like [ { get }T]
rdar://73632764
Protocol requirements don't support default arguments. Although this is
a "semantic" diagnostics, we currently do this for 'func' and 'init' in
Parser. So for fixing a crash, let's to it for 'subscript' in Parser
too.
rdar://problem/73159041
Associated type inference will synthesize typealiases in
constrained extensions for conditional conformances, but
then we might later flag them as re-declarations.
Let's not do this, since name lookup does check if generic
requirements are satisfied, so such redeclarations are not
in fact erroneous.
Fixes <rdar://problem/68933045>.
When overriding a method or witnessing a requirement that comes from
Objective-C and has no actor annotation, allow the overriding method
or witness to specify a global actor (any global actor, but probably
almost always the main actor) without triggering the actor-isolation
errors one would normally get if both entities were written in Swift.
This opens up a hole in actor-isolation checking, because nothing
guarantees that code won't call these methods through the superclass
or protocol from the wrong actor. On the other hand, it's a very
convenient hole, because it allows us to state when we "know" that an
Objective-C framework will only call a method on (e.g.) the main
actor, and make that known to Swift to be enforced everywhere else in
Swift. If this is a good idea, it's plausible to introduce runtime
assertions of some form to tell the user when such an annotation is
wrong.
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.
Use the FullyQualified<Type> abstraction from the prior commit plus DescriptiveDeclKind to give a bit more information when issuing a missing member type diagnostic during type resolution.
Review over a large number of APIs has found that most of the time, the
result type of an Objective-C completion handler method that becomes
"async throws" should be optional. Change the default behavior to
match this, and replace _Nullable_on_error with _Nullable_result to
capture the case where the result should be optional.
The code here used to use the location of the nearest place to insert
attributes, which makes no sense. Use the pattern binding's location
instead to ensure that we actually replace the 'let' part of the
pattern every time.
rdar://69971194
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 concurrency is enabled, the same Objective-C method on a protocol can
be imported as two different protocol requirements, both of which have the
same selector. When performing conformance checking, only treat a
given @objc protocol requirement as "unsatisfied" by a conformance if
none of the requirements with the same Objective-C selector (+
instance/class designation) are satisfied.
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.
While we're here, remove the return on a null generic signature. The request for
the generic signature of a protocol is a trivial computation that is never expected
to fail
* [CSDiagnostics] Emit fix-its to insert requirement stubs in editor mode for missing protocols in context
* [CSDiagnostics] Only include missing requirements in stub fix-it for missing protocols in context
The conforming type may already have declarations that could satisfy a requirement, so we shouldn't include it in the fix-it
Codable's magic previously relied on the subject of every qualified lookup in an
unqualified lookup stack to force the synthesis of this member. This
allowed users to reference CodingKeys transitively through a non-primary input
without qualification. As part of the requestification of name lookup,
this synthesis was moved out of the normal qualified lookup path and into the
Type Checker's semantic lookup entrypoints in order to prevent wild
cycles caused by protocol conformance resolution. In the process, we
forget to restore the synthesis check at this entrypoint.
To patch up the source break this caused, we need to walk the context
stack again and force synthesis. Unfortunately, we're stuck with a hack like
this until we bring Codable's implementation back out of the realm of magic
once more. A future implementation of synthesizeSemanticMembersIfNeeded
should aim to just craft the AST for CodingKeys, but not actually run
any of the semantic checks until we check the conformance to CodingKey.
rdar://65088901, SR-13137
