in favor of explicit available ones.
The type checker does not support the notion of multiple protocol
conformances; there can only be one conformance, and if that conformance
is unavailable, you cannot specify your own available conformance. This
is important for Sendable checking; if a framework specifies that a type
is explicitly not Sendable with an unavailable Sendable conformance,
clients cannot ignore Sendable violations involving that type. If a
superclass wants to allow subclasses to add a Sendable conformance, it
should not declare an unavailable Sendable conformance.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
When diagnosing a case where an actor-isolated witness cannot satisfy
a non-isolated requirement, also suggest that the conformance could be
annotated with `@preconcurrency`.
Add the machinery to support suppression of inference of conformance to
protocols that would otherwise be derived automatically.
This commit does not enable any conformances to be suppressed.
One of the request triggers added to `ConformanceLookupTable` in
https://github.com/apple/swift/pull/68384 can cause circular request
evaluation. Revert the request trigger since it doesn't appear to be necessary
for the test cases introduced in that PR.
Resolves rdar://115314044
Previously, conformances inherited through a base class could be missed in lazy
typechecking mode if types in the inheritance clause were not already resolved.
Provide member macros with similar information about conformances to
what extension macros receive, allowing member macros to document
which conformances they care about (e.g., Decodable) and then
receiving the list of conformances that aren't already available for
the type in question. For example, a macro such as
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
Expanded on a type that is not already Decodable/Encodable would be
provided with Decodable and Encodable (via the new
`missingConformancesTo:` argument to the macro implementation) when
the type itself does not conform to those types.
Member macros still cannot produce conformances, so this is likely to
be used in conjunction with extension macros most of the time. The
extension macro declares the conformance, and can also declare any
members that shouldn't be part of the primary type definition---such
as initializers that shouldn't suppress the memberwise initializer. On
the other hand, the member macro will need to define any members that
must be in the primary definition, such as required initializers,
members that must be overridable by subclasses, and stored properties.
Codable synthesis is an example that benefits from member macros with
conformances, because for classes it wants to introduce a required
initializer for decoding and an overridable encode operation, and
these must be members of the nominal type itself. Specifically, the
`Codable` macro above is likely to have two attached member roles:
@attached(member, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
@attached(extension, conformances: Decodable, Encodable, names:
named(init(from:), encode(to:)))
macro Codable() = ...
where the "extension" role is responsible for defining the conformance
(always), and the "member" creates the appropriate members for classes
(`init` vs. `required init`).
Tracked by rdar://112532829.
Wrap the `InheritedEntry` array available on both `ExtensionDecl` and
`TypeDecl` in a new `InheritedTypes` class. This class will provide shared
conveniences for working with inherited type clauses. NFC.
Fix two inter-related issues with extension macros that provide
conformances to a protocol, the combined effect of which is that one
cannot meaningfully provide extension macros that implement
conformances to a protocol like Equatable or Hashable that also
supports auto-synthesis.
The first issue involves name lookup of operators provided by macro
expansions. The logic for performing qualified lookup in addition to
unqualified lookup (for operators) did not account for extension
macros in the same manner as it did for member macros, so we would not
find a macro-produced operator (such as operator==) in witness
matching.
The second issue is more fundamental, which is that the conformance
lookup table would create `NormalProtocolConformance` instances for
pre-macro-expansion conformance entries, even though these should
always have been superseded by explicit conformances within the macro
expansion buffers. The end result is that we could end up with two
`NormalProtocolConformance` records for the same conformance. Some
code was taught to ignore the pre-expansion placeholder conformances,
other code was not. Instead, we now refuse to create a
`NormalProtocolConformance` for the pre-expansion entries, and remove
all of the special-case checks for this, so we always using the
superseding explicit conformances produced by the macro expansions (or
error if the macros don't produce them).
Fixes rdar://113994346 / https://github.com/apple/swift/issues/66348
stated in the original source.
If an extension macro can introduce protocol conformances, macro expansion
will check which of those protocols already have a stated conformance in the
original source. The protocols that don't will be passed as arguments to
extension macro expansion, indicating to the macro that it should only add
conformances to those protocols.
The conformance lookup table is the central point of truth to
establish which protocols a nominal type conforms to. Ensure that we
expand conformance macros into that table.
Fixes rdar://106886651.
Remove the allowUnavailable parameter to lookupConformance(), and instead
explicitly check the result for hasUnavailableConformance() in the places
where we used to pass 'false'.
Also, narrow down this check in those places to the Sendable protocol
only, fixing a regression with Hashable conformance synthesis.
Fixes rdar://problem/94460143.
When a class has an unavailable conformance to a protocol, do not
inherit that unavailable conformance, because it can get in the way of
subclasses defining their own (properly-available) conformance.
Fixes rdar://89992569.
A recent change to `Sendable` conformance handling resulted in subclasses of global-actor-confined classes being rejected if they explicitly declared a conformance to `Sendable`.
This behavior is technically correct because actor-isolated types are implicitly `Sendable`, but the source compatibility regression was not desirable. We are also considering requiring subclasses to explicitly repeat their superclass's `Sendable` conformance, so it makes sense to allow these redundant conformances in the general case to ease that potential transition.
Fixes rdar://88700507.
Many, many, many types in the Swift compiler are intended to only be allocated in the ASTContext. We have previously implemented this by writing several `operator new` and `operator delete` implementations into these types. Factor those out into a new base class instead.
Implicit synthesis of `Sendable` conformances for global actor-isolated
class types interacts poorly with the conformance lookup table's
attempt at modeling inherited conformances, so a `Sendable` conformance
will get created and inherited, but is then "missing" when we try to
form the actual inherited conformance.
The proper fix for this issue is likely to eliminate the modeling of
inherited conformances within the conformance lookup table, which
introduces a lot of redundance and, apparently, some bugs. For now,
patch over the issue to work around a crash.
Narrowly works around rdar://81700570.
It's been quite a long time since this unused parameter was introduced.
The intent is to produce the module as a root for the search - that is,
computing the set of conformances visible from that module, not the set
of conformances inside of that module. Callers have since been providing
all manner of module-scoped contexts to it.
Let's just get rid of it. When we want to teach protocol conformance
lookup to do this, we can revert this commit as a starting point and try
again.
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.
If a conformance is found in an imported module as well as the current module,
and one of the two conformances is conditionally unavailable on the current
deployment target, pick the one that is always available.
Fixes <rdar://problem/78633800>.
The uncached, rarely-used getLocalProtocols() does not benefit from
having its own distinct implementation. Reimplement it on top of
getLocalConformances() to simplify things and benefit from the
request-evaluator infrastructure.
