Feedback wanted: confusing concurrency diagnostic messages

hborla · June 16, 2024, 4:43pm

Hey folks! I'm currently doing a pass over the compiler's concurrency-related diagnostic messages to make them friendlier and more understandable. If there are any specific diagnostics that you struggled to understand or weren't actionable enough, please let me know in this thread. Feel free to link to existing forum topics that discussed how to resolve specific concurrency diagnostics.

I look forward to your feedback!

siracusa · June 16, 2024, 9:02pm

Just in case you haven’t already seen this suggestion from Matt: https://github.com/apple/swift/issues/74388

KeithBauerANZ · June 16, 2024, 10:29pm

For most of them, the problem is that you have to have quite a deep understanding of the concurrency features, to understand what the right solution is. Makes it quite hard for people new to concurrency to pick the solution that's going to work, and I don't really know what to do about that.

One that is often simple to resolve is the "global var of non-Sendable type"; I'd love a fix-it on that to change var to let, so long as the type is Sendable and non-optional.

mattie · June 17, 2024, 10:45am

Here's one about implicit vs explicit async calls I'm currently confused by:

github.com/apple/swift

This diagnostic tells me an explicitly async call is implicit

opened 10:42AM - 17 Jun 24 UTC

mattmassicotte

bug triage needed

### Description Perhaps I'm misunderstanding, but it sure looks to me like this… call is *explicitly* asychronous. ``` 1 | class Foo { | `- note: class 'Foo' does not conform to the 'Sendable' protocol 2 | init() async { 3 | : 10 | 11 | init() async { 12 | let value = await Foo() | `- error: non-sendable type 'Foo' returned by implicitly asynchronous call to nonisolated function cannot cross actor boundary 13 | 14 | self.foo = value ``` ### Reproduction ```swift class Foo { init() async { } } @MainActor class Bar { let foo: Foo init() async { let value = await Foo() self.foo = value } } ``` ### Expected behavior I would not expect the diagnostic to tell me a call explicitly marked with async is implicit. ### Environment Apple Swift version 6.0-dev (LLVM bf8bbb910874156, Swift a0bb875256e41ae) Target: arm64-apple-macosx14.0 ### Additional information _No response_

ddenis · June 17, 2024, 2:37pm

This is great!

Here is my post about potentially erroneous warning from the compiler: Is it incorrect to use Array.forEach with strict concurrency? - #8 by Jon_Shier

Also see in comments there is another case where compiler things there is a throwing function when in fact there are none Is it incorrect to use Array.forEach with strict concurrency? - #8 by Jon_Shier

mattie · June 17, 2024, 9:15pm

This one is a little silly Hyphenation difference between "nonisolated" and other forms of isolation diagnostics · Issue #73982 · apple/swift · GitHub

vanvoorden · June 17, 2024, 9:29pm

This might be "outside" a discussion specifically about Swift (the language itself)… but I've seen a few instances of SwiftUI protocols that (I would think) should conform to execute only on MainActor that currently are not specified for MainActor. This is a little ambiguous right now because it's not completely clear if this MainActor conformance is coming from the SwiftUI team (in a future beta this summer) or if MainActor conformance is never coming and engineers have to defensively code around that. But this might be an appropriate discussion for Apple Developer Forums.

mattie · June 20, 2024, 9:43am

Here’s a good one about initializers Bad diagnostic when constructor can't initialize isolated property · Issue #74557 · apple/swift · GitHub

mattie · June 20, 2024, 2:01pm

I think the diagnostics have been much-improved since Swift 5.10 here. But, I do really like explicit distinction between "actor" and "main actor" since it's such a common thing.

github.com/apple/swift

Mis-leading error about isolation problem

opened 09:52AM - 14 Mar 24 UTC

mattmassicotte

bug triage needed

### Description This code, while problematic for a few reasons, produces two di…fferent errors for the same problem. The second error is pretty mis-leading and makes it a lot harder to understand what the underlying issue is. ### Reproduction ```swift class MyClass { static let shared = MyClass() @MainActor var data: Data? } func testFunction() async { MyClass.shared.data = Data() Task.detached { MyClass.shared.data = Data() } } ``` ### Expected behavior First error: `Main actor-isolated property 'data' can not be mutated from a non-isolated context` Second error: `Main actor-isolated property 'data' can not be mutated from a Sendable closure` But the problem is the same in both cases. Is the issue really that the closure is Sendable, or that it is non-isolated? ### Environment Xcode 15.3 beta 3 ### Additional information _No response_

mattie · June 20, 2024, 2:05pm

Here's another of me just typo'ing while trying to use an isolated parameter and getting very confused about the resulting error. I wouldn't be surprised if this actually really tricky to address, but thought I'd include it just in case.

github.com/apple/swift

Typo of `any` vs `Any` resulted in an unhelpful error message

opened 06:30PM - 27 May 24 UTC

mattmassicotte

feature triage needed

### Motivation I was experimenting with some features from SE-420, and I made a… typo. I found it quite hard to figure out what was going on from the error message produced. I have no idea if such a thing is possible to handle more gracefully, but I thought I'd point it out anyways. ```swift protocol Thingy { func doThing(isolation: isolated (any Actor)?) } actor MyActor { var value = 1 } extension Thingy { func doThing(isolation: isolated (Any Actor)? = #isolation) { print(value) } } ``` And here are the warnings being produced: ``` test.swift:10:45: error: expected ':' following argument label and parameter name 8 | 9 | extension Thingy { 10 | func doThing(isolation: isolated (Any Actor)? = #isolation) { | `- error: expected ':' following argument label and parameter name 11 | print(value) 12 | } test.swift:10:45: error: expected type 8 | 9 | extension Thingy { 10 | func doThing(isolation: isolated (Any Actor)? = #isolation) { | `- error: expected type 11 | print(value) 12 | } test.swift:10:26: error: 'isolated' parameter type '()?' does not conform to 'Actor' or 'DistributedActor' 8 | 9 | extension Thingy { 10 | func doThing(isolation: isolated (Any Actor)? = #isolation) { | `- error: 'isolated' parameter type '()?' does not conform to 'Actor' or 'DistributedActor' 11 | print(value) 12 | } test.swift:11:9: error: cannot find 'value' in scope 9 | extension Thingy { 10 | func doThing(isolation: isolated (Any Actor)? = #isolation) { 11 | print(value) | `- error: cannot find 'value' in scope 12 | } 13 | } ``` ### Proposed solution I think it would be great if I could get some feedback about the possibility that I just typoed here. Especially in this specific example, I think `Any` is actually totally invalid. But, it would be even cooler if it could be solved more generally. ### Alternatives considered _No response_ ### Additional information _No response_

And another that I personally find confusing about the "implicit" vs "explicit" nature of the asynchronous call in question.

github.com/apple/swift

This diagnostic tells me an explicitly async call is implicit

opened 10:42AM - 17 Jun 24 UTC

mattmassicotte

bug triage needed

### Description Perhaps I'm misunderstanding, but it sure looks to me like this… call is *explicitly* asychronous. ``` 1 | class Foo { | `- note: class 'Foo' does not conform to the 'Sendable' protocol 2 | init() async { 3 | : 10 | 11 | init() async { 12 | let value = await Foo() | `- error: non-sendable type 'Foo' returned by implicitly asynchronous call to nonisolated function cannot cross actor boundary 13 | 14 | self.foo = value ``` ### Reproduction ```swift class Foo { init() async { } } @MainActor class Bar { let foo: Foo init() async { let value = await Foo() self.foo = value } } ``` ### Expected behavior I would not expect the diagnostic to tell me a call explicitly marked with async is implicit. ### Environment Apple Swift version 6.0-dev (LLVM bf8bbb910874156, Swift a0bb875256e41ae) Target: arm64-apple-macosx14.0 ### Additional information _No response_

I think this is a wonderful one where RBI detecting a pretty subtle issue, but the diagnostics make it hard to understand.

github.com/swiftlang/swift

Can RBI give me a better clue here?

opened 01:17PM - 21 Jun 24 UTC

mattmassicotte

feature triage needed

### Motivation Here is a pretty reduced example that shows the problem. This *i…s* unsafe, but its really har to figure out why from the diagnostic alone. ```swift class NonSendableData { } class NonSendable { let data: NonSendableData init(data: NonSendableData) { self.data = data } func doWork() async { } } actor MyActor { let data = NonSendableData() func useNonSendable() async { // the compiler is noticing here that `value` depends on `data` // but data is owned by the actor... let value = NonSendable(data: data) // ... and this makes the non-isolated async call here unsafe await value.doWork() } } ``` ``` error: sending 'value' risks causing data races 24 | 25 | // ... and this makes the non-isolated async call here unsafe 26 | await value.doWork() | |- error: sending 'value' risks causing data races | `- note: sending 'self'-isolated 'value' to nonisolated instance method 'doWork()' risks causing data races between nonisolated and 'self'-isolated uses 27 | } 28 | } ``` ### Proposed solution I'd like something pointing me to this line of code: ``` let value = NonSendable(data: data) ``` ### Alternatives considered _No response_ ### Additional information _No response_

flexlixrup · June 21, 2024, 9:27pm

Some things SwiftUI are definitely still buggy regarding the Main Actor isolation.
E.g. SwiftUI.Commands has a nonisolated protocol requirement but has an internal method which is main-actor isolated which produces an error in Swift 6.
As the UI should always run on the main actor, I guess Apple will add the missing isolation annotations in future betas and I would not start working around the warnings/errors (in some cases impossible) just to make the first beta happy.

twof · June 24, 2024, 2:04am

Actor-isolated value of type '() async -> ()' passed as a strongly transferred parameter; later accesses could race
I think some guidance would be helpful for this one. It's unclear what I should do to fix that. I'm also not sure what it means from reading it without also reading a few proposals, but that might be an unrealistic goal.

hborla · June 24, 2024, 7:26am

Oh, thank you for pointing this out! I also don't know what it means for a value to be "strongly" transferred I know what "transferring" means, but it's now called "sending", and I don't know what it means for that operation to happen "strongly" or why that would have any implication on what you need to do in source to avoid the risk of a data race.

hborla · June 24, 2024, 7:31am

Yes, concurrency annotations in SwiftUI are outside of the core language, and feedback about the annotations themselves or the lack thereof should be provided via Apple Feedback reports. However, if you're getting any compiler diagnostics that don't make sense that involve the SwiftUI concurrency annotations, please feel free to post specific cases here, as I'm sure the associated compiler error messages could use improvement.

gwendal.roue · June 24, 2024, 8:52am

This one can also be a false positive: Swift 6: incorrect compiler error when passing a `sending` closure from a global-actor-isolated function · Issue #74382 · swiftlang/swift · GitHub

twof · June 25, 2024, 5:34am

Apologies if this is out of scope for your project. Here I'm conforming an actor to a standard protocol.

public protocol FooProtocol {
  var callCount: Int { get set }
}

public actor Foo: FooProtocol {
  public var callCount = 0 // error here
}

Error

Actor-isolated property 'callCount' cannot be used to satisfy nonisolated protocol requirement
Fixit: Add '@preconcurrency' to the 'FooProtocol' conformance to defer isolation checking to run time

The fixit feels like a stopgap solution. My understanding (which could easily be wrong) is that the longer term solution is to have FooProtocol inherit from Actor. It also could just be me, but the use of isolated and nonisolated feels unfamiliar. Better wording might note that the compiler needs to understand when a property has to be accessed asynchronously, and the protocol currently doesn't provide that information.

twof · June 25, 2024, 5:47am

I'm going to start splitting off branches from my current project for better context. Two more errors.
The use of self here is confusing because we're in a function.
Sending 'self'-isolated value of type 'repeat each A' with later accesses to actor-isolated context risks causing data races

A minimal repro case with the same error. I don't understand at all why this isn't allowed. This one could be an odd interaction between parameter packs and actors because I couldn't get it to reproduce without a parameter pack.

actor FooActor<each T> {
  var messages: [(repeat each T)] = []
  
  func message(_ num: repeat each T) {
    messages.append((repeat each num))
  }
}

func foo() async {
  let fooActor = FooActor<Int>()
  await fooActor.message(10)
}

This is from the error above that one in the screenshot. I think we're getting some compiler-internal keywords here or something.

Relevant code: FunctionSpy/Sources/FunctionSpy/FunctionSpy.swift at ErrorExample · twof/FunctionSpy · GitHub
Current toolchain: 6.0-DEVELOPMENT-SNAPSHOT-2024-06-22-a
Let me know if I should upgrade from that one.

mattie · June 25, 2024, 2:26pm

Unforutnately, I don't know if adding an Actor conformance to your protocol will actually help in this situation. Synchronous setters and actors don't mix well, so I think you may be just kicking the can down the road to the call sites. Actors are fundamentally asynchronous so they are hard to use with synchronous protocols.

But I agree that more context could help. Another note indicating that you could use a nonisolated computed property could be nice. But, that would prevent you from using actor-isolated state.

I guess the compiler could also suggest a change to the protocol, if it is defined within the same module. But I'm not sure what suggestion would be reasonable...

mattie · June 25, 2024, 2:37pm

I don't have a lot of experience with parameter packs, but this looks like it should work. I filed a bug about it: Parameter packs seem to interfer with region-based isolation · Issue #74688 · swiftlang/swift · GitHub

Michael_Gottesman · June 25, 2024, 6:56pm

That looks like a bug rather than a diagnostic message issue. Thank you for the report.