GRDB compatiblity with Swift 6.0

[groue]

Pull Request Description

Hello, this pull request adds compatibility check for GRDB with Swift 6.0.

Acceptance Criteria

To be accepted into the Swift source compatibility test suite, a project must:

• be an Xcode or swift package manager project
• support building on either Linux or macOS
• target Linux, macOS, or iOS/tvOS/watchOS device
• be contained in a publicly accessible git repository
• maintain a project branch that builds against Swift 4.0 and passes any unit tests
• have maintainers who will commit to resolve issues in a timely manner
• be compatible with the latest GM/Beta versions of Xcode and swiftpm
• add value not already included in the suite
• be licensed with one of the following permissive licenses:
  • BSD
  • MIT
  • Apache License, version 2.0
  • Eclipse Public License
  • Mozilla Public License (MPL) 1.1
  • MPL 2.0
  • CDDL
• pass ./project_precommit_check script run

The last check does not pass, due to the lack of support for Swift 6.0 in project_precommit_check (see #963).

[groue]

Hello, is there anything I should do for having this PR reviewed and merged?

[justice-adams-apple]

@groue no my apologies on the late review! 👁️

[justice-adams-apple]

@swift-ci test

[justice-adams-apple]

@groue error: stored property 'qos' of 'Sendable'-conforming struct 'Configuration' has non-sendable type 'DispatchQoS'

Was this able to build locally for you using a recent compiler?

[groue]

Hello @justice-adams-apple,

@groue error: stored property 'qos' of 'Sendable'-conforming struct 'Configuration' has non-sendable type 'DispatchQoS'

Was this able to build locally for you using a recent compiler?

Yes, I can build the specified commit 3ecb5c54553559217592d21a6d9841becb891b38 with multiple Swift 6.0+ toolchains:

Xcode 16.0 ✅

$ swiftc -version
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
$ swift build
Building for debugging...
[171/171] Linking libGRDB-dynamic.dylib
Build complete! (7.45s)

Xcode 16.1 ✅

$ swiftc -version
swift-driver version: 1.115 Apple Swift version 6.0.2 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)

Xcode 16.2 ✅

$ swiftc -version
swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)

Linux builds ✅ I don't know which version specifically, but this PR was recently merged, and at the time we were already relying on the sendability of DispatchQoS: groue/GRDB.swift#1644

[groue]

My interpretation of the failure is that the toolchain used by the compatibility suite is not identical to the released toolchains.

Since projects.json does not currently contain any compatibility commit that targets Swift 6.0, I understand that we see early glitches. This pull request targets uncharted territory! I'm happy to make this contribution to Swift-6.0 compatibility with GRDB, a rich package that mixes Swift 6 language mode in the main target, and Swift 5 language mode in the test target.

Swift 6 comes with strict concurrency checkings, so it is crucial that the compatibility suite runs with the exact same concurrency annotations as the released toolchains (stdlib, Foundation, Dispatch, etc.) Any difference in Sendable conformances, sending annotations, actor isolation, etc. will trigger false positive errors.

[groue]

I hope I haven't uncovered a problem that can not be addressed in this repository.

If I have, what is my best option for successfully have this pull request merged? I could perform changes in the GRDB repo, in order to make it compatible with the particular toolchain that is used here, for example?

I could add the following line to GRDB:

// DispatchQoS already conforms to Sendable, except
// in swiftlang/swift-source-compat-suite, which needs
// this extra conformance.
extension DispatchQoS: @retroactive Sendable { }

Still, I'm sorry to repeat myself, but I find it concerning that the compatibility suite does not use the same toolchain as the released one. This weakens the "compatibility" that is tested. Given the sensitivity of Swift 6 to concurrency annotations, the compatibility we need involves the compiler, the standard lib, and core libraries as well (Foundation, Dispatch, Synchronization, Observation, etc.)

[justice-adams-apple]

My interpretation of the failure is that the toolchain used by the compatibility suite is not identical to the released toolchains.

We use nightly toolchains so that we can catch issues before release as opposed to released toolchains which have already shipped

I could perform changes in the GRDB repo, in order to make it compatible with the particular toolchain that is used here, for example?

Yeah it's probably best to make the change in the repo because eventually when this compiler is released it would break your project. Sorry for the confusion, let me know if I can help out/answer anything else

[groue]

Yeah it's probably best to make the change in the repo because eventually when this compiler is released it would break your project. Sorry for the confusion, let me know if I can help out/answer anything else

? I don't get it. Isn't it exactly what the compatibility suite is supposed to prevent?

In the particular case we're discussing, I find it hard to believe that DispatchQoS will lose its Sendable conformance.

I was instead expecting an answer that would read like:

Thank you for spotting a regression in the toolchain! We will fix the DispatchQoS declaration in a future release. Until then, we accept this pull request, because it has 100% fulfilled the goal of this repository. Again, thank you!

[groue]

We use nightly toolchains so that we can catch issues before release as opposed to released toolchains which have already shipped

This makes sense when looking for regressions (such as the loss of the Sendable conformance of DispatchQoS), but it makes less sense when considering the acceptance of pull requests to this repository such as this one.

A build failure with a nightly toolchain reveals a regression in the nightly toolchain, which is exactly the purpose of this repository. It should not prevent the merge of a pull request like this one, which submits code that compiles with multiple released compilers.

I don't understand why this pull request is not already merged.

I question the methodology in place.