You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Package no longer builds on Xcode 26.3 (Swift 6.2.4) from 7.43.0: sending 'codecpar' risks causing data races in the undecodable-format gate #883
Every release from 7.43.0 through 7.47.0 fails to compile on Xcode 26.3 (17C529, Swift 6.2.4). 7.42.0 is the last release that builds; it is what we pin until we move to Xcode 27.
7.43.0 to 7.46.0 fail in one place, the forcesSoftware closure AE#348 added beside the pre-flight gate:
Sources/AetherEngine/AetherEngine.swift:5339:87: error: sending 'codecpar' risks causing data races
canHardwareDecode: { VTCapabilityProbe.canHardwareDecode(codecpar: codecpar) })
note: task-isolated 'codecpar' is captured by a main actor-isolated closure. main actor-isolated uses in closure may race against later nonisolated uses
(5300:87 in 7.43.0, 5339:87 in 7.45.0, 5343:87 in 7.46.0.) let forcesSoftware = { … } is inferred main-actor and captures the codecpar pointer bound in the if let above it.
7.47.0 also fails earlier, in the new stereo code:
Sources/AetherEngine/Video/StereoVideoSignal.swift:120:75: error: cannot convert value of type 'Int' to expected element type 'Array<UInt8>.ArrayLiteralElement' (aka 'UInt8')
let stri = box("stri", [0, 0, 0, 0, (packing.reversed ? 0x08 : 0) | 0x03])
Swift 6.2.4 types (… ? 0x08 : 0) | 0x03 as Int; Xcode 27 evidently infers UInt8 from the literal's context. The build stops on that file, so 7.47.0 may also carry the codecpar error.
Possible fixes, if Xcode 26 is still meant to be supported (7.38.1's notes suggest it is):
canHardwareDecode: make the local closure nonisolated, or call the probe directly instead of capturing codecpar in a stored closure.
Activity