Swift 6.1 regression in Sendable checking

[groue]

Description

The Swift 6.1 compiler does not compile code that compiles with the Swift 6.0 compiler.

Reproduction

Compile the code below from Xcode 16.2 (16C5032a) with swift-6.1-DEVELOPMENT-SNAPSHOT-2025-01-13-a.xctoolchain

import Foundation

enum MyEnum: Sendable {
    // Compiler error:
    // Associated value 'formatted' of 'Sendable'-conforming enum 'MyEnum'
    // has non-sendable type 'DateFormatter'
    case formatted(DateFormatter)
    
    nonisolated(unsafe) static let iso8601Formatter: ISO8601DateFormatter = {
        fatalError()
    }()
}

(Note that Foundation.DateFormatter is declared as Sendable).

Expected behavior

The code compiles, as it does with a Swift 6.0 compiler, because it is correct.

Environment

Development Snapshots swift-6.1-DEVELOPMENT-SNAPSHOT-2025-01-13-a

Additional information

This regression was found because Swift 6.1 can not compile https://github.com/groue/GRDB.swift/tree/v7.0.0-beta.6.

This kind of regression is supposed to be caught by https://github.com/swiftlang/swift-source-compat-suite, but unfortunately this is not possible: swiftlang/swift-source-compat-suite#963 :-/

[theoks]

With Xcode 16.3 beta now released, the issue mentioned here will start appearing in the wild causing build failures in multiple projects. Can this be addressed before the 16.3 stable release?

[hborla]

The problem is that DateFormatter is marked Sendable, but Formatter explicitly has an unavailable conformance to Sendable. It's not valid for a subclass to have an available conformance while a superclass does not -- types can only have one conformance to a protocol, and superclass conformances are inherited by subclasses. This is ultimately an issue with the Sendable annotations in Foundation, which @jmschonfeld is aware of.

This was exposed by #75135, which fixed an issue where people were getting bogus diagnostics because different parts of the compiler saw different conformances between the unavailable conformance and the available conformance.

[groue]

Hello and thank you @hborla. If I understand well, the Sendable conformance of DateFormatter should never have shipped, so this issue is not an actual regression. It's something else, revealing a compiler that somehow gets better at dealing with the inconsistencies of the toolchain 😅

(Note the extra weirdness in this issue: the compiler error on the line with DateFormatter only happens when ISO8601DateFormatter is used below.)

Anyway. What I wrote above was wrong:

The code compiles, as it does with a Swift 6.0 compiler, because it is correct.
[...] (Note that Foundation.DateFormatter is declared as Sendable).

The reality is that the code was not correct, because DateFormatter should never have been Sendable in the first place. The error can only be fixed by modifying the code, not by waiting for a fix in the compiler.

That's the actionable information I was missing, so thank you again.

[hborla]

If I understand well, the Sendable conformance of DateFormatter should never have shipped, so this issue is not an actual regression.

Sorry, no, that's not what I meant. DateFormatter is indeed thread safe and its conformance to Sendable is correct. What's incorrect is the unavailable conformance to Sendable on the Formatter superclass. Formatter itself does not have any unprotected mutable state. It should have no conformance to Sendable at all - that means something different than an unavailable conformance to Sendable. The unavailable Sendable conformance is what needs to be removed. This allows subclasses to declare their own conformances to Sendable that may be available in the subclass is thread safe, or unavailable if the subclass introduces its own unprotected mutable state.

I'm also debating reverting my compiler change that exposed this while I figure out whether there's a way prevent mistakes in libraries from being exposed as errors in clients.