* [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
Since it's now possible to refer to static members declared on a protocol
metatype if result type conforms to the protocol we need to adjust failure
detection to identify that conformance failure means and invalid reference
in certain situations.
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
Before lookup was requestified, the entire lookup stack would
install semantic members. As this caused cycles in the lookup path, it
was refactored to instead only occur at the TypeChecker::lookup*
entrypoints. Unfortunately, these entrypoints were not kept in sync with
the stack building code in qualified lookup, so a case was missed:
class-bound archetypes. We need to synthesize semantic members for them
as well or we'll non-deterministically fail to find synthesizable
members in incremental mode.
rdar://74174749
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
If the typealias here is generic, we return an UnboundGenericType
where getAnyNominal() returns nullptr. This would fail by returning
an ErrorType to the caller without diagnosing anything.
This was a regression after some recent refactoring to remove code
duplication and some TypeLoc usages, because one of the copies of
this code did not have this check, so it happened to work for
property wrappers.
Relax the check by looking through a TypeAliasDecl explicitly.
I believe we can't end up here anyway, because if the type was
not a nominal we would fail earlier in CustomAttrNominalRequest, and
we wouldn't attempt to compute the type of the property wrapper at
all. However it's better to keep the assertion in place just in case.
Fixes https://bugs.swift.org/browse/SR-14143 / rdar://problem/73888684.
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.
The `try await` ordering is both easier to read and indicates the order
of operations better, because the suspension point occurs first and
then one can observe a thrown error.
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.
We haven't implemented any support for top-level async code yet, so
reject it in effects checking rather than crashing in the SIL verifier.
Fixes rdar://71512818.
