The compiler derived implementations of `Codable` conformances for enums did
not take enum element unavailability into account. This could result in
unavailable values being instantiated at runtime, leading to a general
violation of the invariant that unavailable code is unreachable at runtime.
This problem is possible because synthesized code is not type checked; had the
conformances been hand-written, they would have been rejected for referencing
unavailable declarations inside of available declarations.
This change specifically alters derivation for the following declarations:
- `Decodable.init(from:)`
- `Encodable.encode(to:)`
- `CodingKey.init(stringValue:)`
Resolves rdar://110098469
Opened existentials should be erased to the dependent upper bound
if the dependent member can be reduced to a concrete type. This
allows the generic signature to support parameterized protocol types
and bound generic class types by producing a more specific constraint
instead of just a plain protocol or class.
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
In https://github.com/apple/swift/pull/63898 conformance requirement
typechecking was relaxed to allow unavailable decls to witness conformance
requirements as long as the conforming nominal was also unavailable. However,
only nominals that were directly marked unavailable were accepted. Nominals
that are declared in unavailable scopes should also be allowed to have
unavailable wintesses.
Resolves rdar://107052715
Specifically:
1. Fix the error message so that when we say you can't have a deinit that a
deinit can be on a noncopyable type along side a class or an actor.
2. Even though we already error on @objc enums and say they cannot be
noncopyable, we did not emit an error on the deinit saying that @objc enums
cannot have a deinit. I put in a nice to have error just to make it even
clearer.
rdar://105855978
rdar://106566054
[Distributed] generic and inner test; without one edge case
[Distributed] fix distributed_thunk test; unsure about those extra hops, could remove later
[Distributed] Remove type pretending in getSILFunctionType; it is not needed
It seems our constant replacement in the earlier phases is enough, and
we don't need this trick at all.
[Distributed] Use thunk when calling cross-actor on DA protocols
Refactor ObjC conflict diagnosis code to sort conflict data more thoroughly, filter out unwanted declarations earlier, and just generally behave in ways that are more likely to work correctly.
This change increases the determinism of the ordering of diagnostics and the selection of the “correct” declaration that the others are considered to conflict with, increasing my confidence that the diagnostics will work correctly in untested corner cases or if the compiler is refactored so that declarations are recorded in a different order. It also adds a new selection rule—@objc without vs. with explicit selector—that I believe will slightly improve the diagnostics we produce. And it replaces a lot of really dodgy-looking logic that may have only worked reliably when a conflict involved exactly two methods.
the conformance to the corresponding inherited protocol
- originates in a superclass
- originates in a different module
- and the current conformance have mismatching conditional requirements
This can turn out badly in two ways:
- Foremost, we must not *alter* conformances originating in superclasses
or other modules. In other cases, we may hit an assertion in an attempt
to overwrite an already recorded type witness with a different one.
For example, the recorded type witness may be invalid, whereas the
other one---valid, and vice versa.
- If the current conformance is more restrictive, this type witness may
not be a viable candidate for the overridden associated type.
We can't just ignore unavailable conformances because the
generic signature we're computing might itself be attached
to an unavailable declaration.
Until we get a proper fix, only drop unavailable conformances
to Sendable here.
Fixes rdar://problem/94305457.
Operator function witnesses are looked up globally. However, an additional, qualified lookup is warranted if the conforming type is declared in a local context.
Refusing to acknowledge unavailable conformances at this point in the
requirement machine doesn't allow us to make use of unavailable
conformances from unavailable contexts, something which code currently
depends on. Limit the new filtering behavior to `Sendable` conformances
where we need them, as a narrow fix for this regression. We'll revisit
the approach here later.
Fixes rdar://94154905.
When determining whether a superclass conforms to a particular protocol,
skip unavailable conformances. This way, we don't minimize away a
constraint that might only apply to subclasses of the specified
superclass.
Fixes rdar://91853658.
Instead of checking for presence of `where` clause, let's use
requirement signature and check whether any of the requires are
anchored on a particular associated type.
Accessing members on the protocol could result in existential opening and subsequence
result erasure, which requires explicit coercion if there is any loss of generic requirements.
