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
RequirementEnvironment wasn't prepared to handle a protocol
requirement with additional 'where' clause constraints but
no generic parameters.
Since such a requirement necessarily runs afoul of the existing
"protocol requirements cannot constrain Self" rule, it suffices
to ignore such requirements when matching witnesses and let
the declaration checker diagnose this situation later.
Fixes <rdar://problem/61876053>.
In the included test case, conformance checking of Wrapper : B would
pick up typealias Foo as a witness for the associated type B.Foo.
However, this typealias Foo is defined in a constrained extension where
T : A, and the underlying type references the associated type A.Foo
on T.
The resulting substitution is invalid when the conformance Wrapper : B
is used in a context where T does not conform to A.
Instead, we should ignore this typealias entirely, since it appears
in an unusable constrained extension.
Fixes <rdar://problem/60219705>, <https://bugs.swift.org/browse/SR-12327>,
<https://bugs.swift.org/browse/SR-12663>.
Use the proper `swift_only_stable_abi` check to ensure that the tests do
not run on targets that do not support the pre-stable ABI.
Thanks to @slavapestov for pointing out that there was a better way!
* [Diagnostics] Update 'does not override' diagnostic message to include protocol context as well
* [Sema] Check whether the override context is a class or a protocol for diagnostic purposes
* [Test] Update tests with new diagnostic message for overrides in protocol context
* [Sema] Adjust diagnostic for overrides in structs and enums to use the existing 'override_nonclass_decl' diagnostic
* [Diagnostic] Fix diagnostic when checking conformance for IUO of generic parameter
Prints TypeRepr in diagnostic if possible to throw
accurate diagnostic for IUO conformance checking
Fixes [rdar://problem/64953106]. Fixes SR-13119
* Nested name lookup tests update
Name lookup will see the innermost name anyway and
preferred over fully qualified name. Hence the test
cases are also updated.
* Replaced a letter in test case that inadvertently got added
* Code format, corrections and better comments
This commit includes better comments for easy
understanding, formatted the bug fix code with
clang-format and fixes wrong variables inadvertently
introduced.
* [Test] Update type in struct codable test
This commit changes diagnostic type from error type
to Int. Although this diagnostic updated is incorrect, this will
be resolved when 32371 gets pulled.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
We should allow an associated type's default to reference the
same associated type with a base other than 'Self'.
Note that it now becomes easier to defeat this check, but it
was never air-tight anyway -- for example, you could have a
cycle of length two if each associated type's default was the
other associated type.
This is fine, because this check is purely 'cosmetic'; nothing
goes really wrong if you have a cycle here, except that the
diagnostic shifts from the declaration of the protocol to the
conforming type.
Fixes <rdar://problem/62355224>.
