apple / apple/swift-async-algorithms
Build failure with swift-nightly-main: region-isolation errors in MultiProducerSingleConsumerAsyncChannel
- Dominant language
- Swift
- Stars
- 3.7k
- Forks
- 226
- Avg merge
- 10d 3h
- Merged PRs (30d)
- 1
Description
swift-async-algorithms 1.1.3 fails to compile with the current swift-nightly-main toolchain.
All errors are in `MultiProducerSingleConsumerAsyncChannel+Internal.swift` and look like this:
```
error: '$0.enqueueContinuation' cannot be returned
note: returning '$0.enqueueContinuation' risks concurrent access to 'inout sending' parameter '$0'
as caller assumes '$0' and result can be sent to different isolation domains
```
Same pattern repeats for `enqueueProducer`, `cancelProducer`, `finish`, `next`, `suspendNext`, and `cancelNext`.
**To reproduce:**
```bash
docker run --rm swiftlang/swift:nightly-main-jammy \
bash -cl "git clone https://github.com/apple/swift-async-algorithms.git && cd swift-async-algorithms && swift build"
```
Looks like the nightly compiler tightened region-isolation checks around values returned from `Mutex.withLock` closures that use `inout sending` parameters.
Contributor guide
Research direction
Start with MultiProducerSingleConsumerAsyncChannel+Internal.swift and reproduce the failure using the provided swiftlang/swift:nightly-main-jammy Docker command. Inspect the Mutex.withLock closures around enqueueContinuation, enqueueProducer, cancelProducer, finish, next, suspendNext, and cancelNext. Done means swift build succeeds with the current nightly-main toolchain.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- swift
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100