Synthesized conformances ignore availability & deprecation

[KeithBauerANZ]

Description

When synthesizing conformance (at least to Equatable and Hashable), the compiler ignores the availability of conformances on constituent properties.

I discovered this because in the Xcode 16 SDK, CGSize has a conformance to Hashable that's only available from iOS 18.

Reproduction

struct S {}

@available(macOS 90, *)
extension S: Equatable {
    static func == (lhs: S, rhs: S) -> Bool {
        if #available(macOS 90, *) {
            true
        } else {
            fatalError("this function does not exist")
        }
    }
}

struct T: Equatable {
    var s: S
}

_ = T(s: S()) == T(s: S())

$ swiftc -swift-version 6 ConditionalConformanceBackDeploy.swift
ConditionalConformanceBackDeploy.swift:6:12: warning: unnecessary check for 'macOS'; enclosing scope ensures guard will always be true
 2 | 
 3 | @available(macOS 90, *)
 4 | extension S: Equatable {
   | `- note: enclosing scope here
 5 |     static func == (lhs: S, rhs: S) -> Bool {
 6 |         if #available(macOS 90, *) {
   |            `- warning: unnecessary check for 'macOS'; enclosing scope ensures guard will always be true
 7 |             true
 8 |         } else {
$ ./ConditionalConformanceBackDeploy
ConditionalConformanceBackDeploy/ConditionalConformanceBackDeploy.swift:9: Fatal error: this function does not exist
zsh: trace trap  ./ConditionalConformanceBackDeploy

Expected behavior

Ideally, I guess the synthesized conformance would also get synthesized availability, intersecting the availabilities of all the constituent properties.

I'd also accept that the conformance simply cannot be synthesized where the availability of its type/extension doesn't match/exceed the availability of the constituent properties

Environment

swift-driver version: 1.115 Apple Swift version 6.0 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)
Target: arm64-apple-macosx14.0
(Xcode 16.0)

Additional information

No response

[KeithBauerANZ]

Relatedly, no warning is generated for a synthesized conformance that relies on a deprecated conformance:

struct S {}

@available(*, deprecated)
extension S: Equatable {}

struct T: Equatable {
    var s: S
}

swiftc -swift-version 6 SynthesizedDeprecated.swift 
# no output

[KeithBauerANZ]

Other things that are probably affected:

• synthesized setters/lazy vars where the type conforms to NSCopying with different availability
• conformances to BitwiseCopyable with availability, at least as they propagate to tuples containing them
• synthesized Differentiable where constituent properties conform with different availability
• Dynamic callables where the type's conformance to ExpressibleByStringLiteral or ExpressibleByDictionaryLiteral has different availability
• passing nontrivial types as pointers with & where the BitwiseCopyable or FixedWidthInteger conformance has different availability
• throws(E) functions where E's conformance to Error has availability (normally the throw is checked against Error and that check does handle availability, but in the case of typed throws the availaibility is missed at the declaration, and the throw is only checked against E, so you can throw a non-Error type)
• lifetime dependence checks where conformance to BitwiseCopyable has different availability
• derived conformance to Sendable where constituent types are Sendable with different availability
• something with distributed actors (what do you do if the availability of the type on the receiving end differs from the sending end anyway?)
• consume of BitwiseCopyable with availability
• synthesized conformances to Codable and Decodable where constituent properties' availability is limited

[tshortli]

Thanks for the detailed report! The correct behavior is for the compiler to refuse to create a synthesized conformance, since it can't be assumed that inserting something like a fatalError() on the else branch is the appropriate way to handle the missing conformance.