Swift 6.0.2 aligns Sendable conformance handling for older targets
A compiler maintenance fix makes protocol dependency analysis agree with conformance resilience when library evolution and older deployment targets interact.
A protocol can have the correct source declaration while the compiler disagrees internally about how its conformance should appear in a binary. Swift 6.0.2 includes a correction for one such disagreement involving protocols that inherit from Sendable. The failure depends on library evolution and deployment targets that predate Swift 6.
The official release archive dates Swift 6.0.2 to October 28. Its compiler backport explains the relevant mismatch. The compiler's decision about whether a protocol conformance was dependent used a different notion of resilience from other parts of intermediate-representation generation. The correction makes those decisions use the same conformance-level query.
I find this kind of maintenance relevant to Swift's explicit type model. A declaration's guarantees depend on the compiler preserving them through code generation. Correct source-level isolation checking is only part of the implementation needed to support those interfaces across runtime and deployment boundaries.
The conformance has more context than the protocol
The backport identifies a particular case in which both the protocol and its conforming type are in the same module as the user. Looking only at the protocol's resilience did not account for that relationship in the same way as the compiler's existing conformance logic.
The change therefore replaces a protocol-level resilience test with a call to isResilientConformance. That query considers the conformance being used. The distinction matters because a protocol declaration and a particular type's implementation of that protocol are different entities, with different information available about their relationship to the current module.
The commit and regression test make the affected arrangement concrete. A local protocol inherits from Sendable. Another local protocol inherits from the first and also names Sendable. The local structure conforms to the derived protocol and implements its requirements. A generic function then accepts that structure through the base protocol constraint.
This is ordinary-looking source code. Its significance lies in the representation emitted for the conformance under the selected compilation conditions. The regression test checks the generated witness table, so it verifies more than the type checker's willingness to accept the declarations.
Older deployment targets change the obligation
The backport scopes the fix to binaries using conformances of Sendable-conforming protocols, with library evolution enabled and deployment targets older than Swift 6. That combination should be retained when explaining the defect. A general claim that every Sendable protocol is broken would discard the conditions that made the compiler's disagreement relevant.
The added test runs include macOS 14 and macOS 15 targets. It adds runs with -enable-library-evolution to the existing coverage. The point is to exercise the compiler's representation choices under different runtime-availability assumptions and with the compilation mode that triggered the mismatch.
Library evolution is relevant because emitted code has to account for how conformances may change across binary boundaries. The implementation comment describes resilient conformance handling in terms of witness tables that need runtime instantiation for requirements added with default implementations. Dependency analysis must agree with that handling.
The corrected query has an ignoreGenericity argument for this use. The source comment explains that it bypasses an optimization under which non-generic conformances are treated as non-resilient. This is a specific adjustment to the compiler's internal decision, allowing the dependency calculation to use the needed notion of conformance resilience.
The regression checks the representation
The test checks entries in a local type's witness table, including its relationship to the base protocol. That makes the intended result observable at the generated-IR level. A source-only compilation test would establish that the declarations are accepted while leaving the original representation mismatch insufficiently constrained.
The backport reports testing against an affected project as well as adding new tests. It also describes the change as further narrowing an earlier correction. The public explanation does not supply a universal runtime symptom for all programs matching the broad topic, so this maintenance update should not be reduced to a claim that it fixes every crash involving concurrency protocols.
For library authors, the useful information is the combination of build settings and declaration relationships. A library using evolution support while retaining older deployment targets has obligations that differ from a single application compiled only for a new runtime. The compiler needs consistent decisions across both cases.
Maintenance preserves the released model
The Swift 6 announcement made data-race-safe language mode an explicit choice and described broader ownership support. This patch operates beneath those source-level capabilities. It does not introduce a new rule requiring application authors to redesign the local protocol hierarchy shown in the regression test.
My interest is in keeping the language's abstractions usable under the deployment choices its compiler supports. The correction belongs in code generation because the declarations already describe the intended relationships. Swift 6.0.2 makes the dependent-conformance decision consult the same resilience logic used elsewhere, including the same-module information that the earlier decision missed.