Please help me understand the decision to add Swift 6 warnings to Swift 5

Using Swift
1

The Swift 6 compiler available in Xcode 16 beta introduces many warnings related to the new concurrency model, even when compiling in Swift 5 mode.

In some cases, it's completely impossible to avoid warnings.
Consider the following code:

import WebKit

This produces the following warning: Add '@preconcurrency' to suppress 'Sendable'-related warnings from module 'WebKit'

If the suggestion is applied:

@preconcurrency import WebKit

Now, the following warning is produced: '@preconcurrency' attribute on module 'WebKit' has no effect

My projects always use -warnings-as-errors.
This makes it impossible to compile Swift 5 code with the new Swift 6 compiler.

I created a radar about that problem (FB14338964) just to be told to disable -warnings-as-errors.
This is not an acceptable solution for me.

What’s the point of the Swift 5 mode if perfectly valid Swift 5 code now raises warnings?
Some warnings might be beneficial when planning a migration, but there should at least be a way to disable them.

As I understand, some concurrency-related warnings were introduced in Swift 5.5.x and then relaxed in Swift 5.6 (SE-0302 / SE-0337).

Am I the only one to think that the behavior of the Swift 6 compiler feels like a regression?
How do you folks deal with these warnings in your codebases?

12 Likes
2

I can offer you to turn off warnings as errors and use warnings limit (locally or CI), it will allow you to prevent adding new warnings, but iteratively fix Swift 6 related ones. Of course, if you're willing to migrate... Or able to live with fixed number of warnings

1 Like
3

I think it is safe to assume that in such case your project at the time has no warnings. I think it is a valid solution in that case temporarily disable this, migrate concurrency warnings and turn back on.

3 Likes
4

FWIW, I went ahead and disabled this particular warning in Swift 6.0. We'll only bring back this "@preconcurrency has no effect" warning when we're certain to have fixed all of the cases where it was emitted incorrectly.

Doug

13 Likes
5

I feel like everyone’s missing the original complaint: why are concurrency-related warnings enabled in code compiled with -swift-version 5 at all, when the original code (assumedly) isn’t using concurrency features at all? Including anything regarding Sendable.

8 Likes
6

Even in Swift 5, adoption of concurrency markup in modules will trigger warnings and errors in consumers, presumably because doing otherwise would violate the safety guarantees the module made. To avoid that modules can mark their concurrency APIs as @preconcurrency.

However, there’s something weird going on with WebKit that triggers the back and forth with the consumer’s @preconcurrency.

1 Like
7

That's not the intention, and I believe this bug is a case where the "add @preconcurrency" warning is emitted on its own, with no other warnings that caused it, because the warnings that caused it (which come from @preconcurrency APIs) are suppressed under minimal checking.

4 Likes
8

That's excellent news; thanks for the fix!
I'm looking forward to the next Xcode beta.

9

I'm glad to hear this is not the intended behavior. :slight_smile:

10

Thanks for the suggestion.
As I mentioned, disabling "warnings as errors" is not a solution for me or my team.
It might be OK as a very short term fix, but not in the long term.

We'll indeed migrate to Swift 6, but the codebase is huge and this will take time.
I the meanwhile, we still need a way to compile valid Swift 5 code that was warning free while keeping "warnings as errors".

Anyway, it looks this is going to be solved. :slight_smile:

11

The code was indeed warning-free.
The issue was we could not migrate since the migration was introducing new erroneous warnings.
So there was non way we could turn "warnings as errors" ever back on in such a scenario.

Glad to hear this is goinf to be fixed!

12

Thanks.
I can understand the motivation behind having warnings even in Swift 5 mode, as it can help you plan a migration and know what to expect.

I'm not against it as long as it's an optional feature that we can opt out of.

It would be great to have better control over diagnostics in Swift, especially when it comes to deprecations and new language features, but this is another subject. :wink:

1 Like
13

Have you already solved this problem? Maybe you should check the protocol method of the WebKit, some may miss the @MainActor and @Sendable attributes. I fixed this issue by modifying them.
Like this:

IMG_2427
IMG_24272532Ă—1170 245 KB

3 Likes
14

With Xcode 16 beta 5 I'm getting some errors in a 3rd party library "Mutable capture of xxx is not allowed in concurrently-executing code".

However, my Xcode settings have treat warnings as errors set to now.

So with beta 5, Apple have broken backwards compatibility and that raises the ops original question once again, which hasn't actually been answered that I can see. Why add swift 6 warnings to swift 5 if they cannot be ignored?
Surely this must be a bug in beta 5?

15

Related question: is Swift 6 in 5 mode fully compatible with Swift 5.10? I.e. will Swift 6 compile my 5.10 code with the same outcome in terms of warnings and errors?

16

We currently set warnings-as-errors. We are also currently at "targeted" concurrency across all of our project (and complete in a few places). When trying to use Xcode 16 with swift 5, we now get new warnings about concurrency in swift 6 mode.

We know about many of these warnings as we're actively working to fix them using the "complete" concurrency level in swift 5. It was my understanding that this was the mechanism to use to see swift 6 warnings.

We need some mechanism for disabling these Swift 6 concurrency warnings in Swift 5 mode. We have a large team, and do not want to remove warnings-as-errors otherwise new warnings (unrelated to concurrency) can be introduced.

1 Like