Incremental strict concurrency adoption

Using Swift
, ,
1

I have a large code base which I am migrating to strict concurrency. One of the target has resolved all concurrency warnings except those which are region based isolation bugs:

Now I am at a state where I can't adopt swift 6 version as these warnings will become error with Swift 6. Until the fixes land in future swift versions I can't adopt Swift 6. This puts the codebase in a state where new concurrency errors can still be introduced without the Swift 6 adoption.

I am looking for a way where these warnings will remain as is, while introducing any new concurrency warnings will cause errors. Is there any way to achieve this?

Alternatively, is there any way I can toggle Swift 6 for all the files in a target excluding specific files?

2

Have you tried the Swift 6.4 / Xcode 27 beta to see if anything has changed? You could also try using the new @diagnose attribute to control the diagnostic, but I'm not sure it would apply to that specific issue. Really your only option here is to move the problematic code into a separate framework or package which builds in Swift 5 mode (with complete checking and concurrency-related upcoming features enabled) while the rest of your targets enable Swift 6 mode.

3

I’m still looking into the first two issues, but I think it should work if you use @Sendable.

4

Have you tried the Swift 6.4 / Xcode 27 beta to see if anything has changed?

I tested with latest main snapshot and one of the issue is resolved. The other two still aren't.

You could also try using the new @diagnose attribute to control the diagnostic, but I'm not sure it would apply to that specific issue.

This is something I tried to implement but these warnings have no diagnostics category, making it impossible to control them via @diagnose.

Really your only option here is to move the problematic code into a separate framework or package which builds in Swift 5 mode (with complete checking and concurrency-related upcoming features enabled) while the rest of your targets enable Swift 6 mode.

This is something what I want to avoid as this would require lot of changes in the code base. Due to the inter dependency of these code.

5

As of this change, there are diagnostic groups for this type of issue (RegionIsolationUnknownPattern). Per the github history, I would expect this to be in the 6.4 compiler release, but I've not definitively confirmed if that's the case (some toolchains I tried that I expected to include it seemingly did not).

However, in the Swift 6 language mode, AFAIK you cannot downgrade RBI diagnostics, even with the new diagnostic groups from that PR. This is presumably because it would give you a way to subvert the language's safety goals in that language mode without anything clearly indicating they've been undermined (e.g. by using something with unsafe in the name). In the near term I think your best bet may be to use the Swift 5 mode with -strict-concurrency=complete, and use the diagnostic controls to have targeted opt-outs where necessary to work around bugs, etc.

1 Like
6

This is good to hear. I couldn't find this in the latest public release. This would help me once this is available.

I think your best bet may be to use the Swift 5 mode with -strict-concurrency=complete, and use the diagnostic controls to have targeted opt-outs where necessary to work around bugs, etc.

Yes this is what I want to achieve as well. Without adopting Swift 6, I want to set all the warnings as errors and downgrade these types of diagnostics to warnings.

7

In the closure expression, not in the type signature. If you want to keep the global-actor isolation, you should do so explicitly for now.

8

Actually, in the second issue (#89953), you should either remove sending or replace it with @Sendable, since sending doesn't really have any effect here.

9

Actually this is something not blocking me for Swift 6 adoption currently and you are right remving sending should fix the issue.

Originally my code didn't have sending and when checking build with trunk main snapshot I got warning:

Passing arguments to initializer 'init(action:)' could allow for references between values exposed to code in the current isolation context and actor-isolated code risking data races; this will be an error in a future Swift language mode

Fortunately this warning doesn't appear in current mode and doesn't seem to indicate to block Swift 6 adoption. But this prompted me to add sending which now gives the region based isolation bug warning.

Wierd thing is I tried to create a reproducer that can produce above warning in trunk main snapshot but wasn't able to do so.

The Input and Stored types can be non-Sendable. Hence, I can't use @Sendable here.

10

The new diagnostic is emitted in cases like this:

// A function type with an `isolated` parameter
// is currently considered non-Sendable. For now, you must add `@Sendable` manually.

@MainActor
func f(_: (isolated Actor) -> Void) {}

@MainActor
func main() {
    f { _ in }
}

// Same story here, the async closure is non-Sendable.

@globalActor
actor GA {
    static let shared = GA()
}

@MainActor
func f(_: () async -> Void) {}

@MainActor
func ff() {
    f { @GA in }
}
11

I took a quick look. It looks like one of the issues (Region based isolation check fail on valid code · Issue #86180 · swiftlang/swift · GitHub) is fixed on main. I am looking at the other 2.

4 Likes
12

In these cases what will happen if sending is used instead of @Sendable?

13

Did you mean in cases like this?

func send(_: sending (isolated Actor) -> Void) {}

func f() {
  send { _ in }
}
14

In cases like:

@MainActor
func f(_: sending (isolated Actor) -> Void) {}

@MainActor
func main() {
    f { _ in }
}
15

You will get a sending diagnostic because you cannot send a non-disconnected value (the non-Sendable closure is isolated to its isolated parameter). For a value to be an argument to a sending parameter, it must be disconnected.