Open briancoyner opened 2 days ago
I've been seeing a lot of these import errors on Android over the last couple months, where repos that compiled fine in July with the trunk 6.1 snapshot toolchain started complaining about these imports with an early August snapshot toolchain.
There are two possibilities I can think of for why:
I investigated this a bit last month and am leaning towards 2. as the likely reason. It doesn't seem to affect non-modularized overlays like Glibc
on linux servers, only modularized overlays like Musl
and Android
.
@al45tair, should we just start putting in a bunch of extra imports on these platforms to shut the compiler up? That's what I've started doing for Android.
Possibly. I'll try to reproduce this today and see if I can work out what's going on, which should help inform our approach. The Glibc
overlay isn't "non-modularised" so much as badly modularised, and that can cause its own problems. I think the difference is likely most that the CI and PR testing is set up for normal Linux, which uses Glibc
, so the Foundation folks tested their changes against that (hence it works there), and not with the Static SDK or Android, which is where we're seeing problems.
I don't think it's just some normal changes from the Foundation update, as I see many Swift repos checked out at the exact same source tag and with the same Android overlay starting to report import errors after the Foundation update.
Something clearly changed in the modules re-exported after July. I'm speculating that the Foundation rewrite and that clang re-exports leak is the reason, as I have not dug into it, but it appears to be a more substantive issue.
Appears to compile OK if import Musl
is outside of canImport
.
import NIOHTTP1
#if canImport(xlocale)
import xlocale
#elseif canImport(locale_h)
import locale_h
#elseif canImport(Darwin)
import Darwin
#elseif canImport(Musl)
import Musl
#elseif canImport(Glibc)
import Glibc
#endif
import CAsyncHTTPClient
import NIOCore
+ import Musl
Expected behavior
An application with a dependency on async-http-client successfully builds with a Swift 6 OSS toolchain + Static Linux SDK.
Note: The
swift-6.0-DEVELOPMENT-SNAPSHOT-2024-09-17-a
toolchain is used vs theswift-6.0-RELEASE
because of another issue withswift-collections
. That issue is fixed in the "09-17" toolchain release.Note: The
main
branch of SwiftNIO is used because it contains a fix needed to compile SwiftNIO.Note: Xcode 15.4.0 vs Xcode 16.0.0 because of an issue described here:
Actual behavior
main
branch error and 1.22.2 errorSteps to reproduce
swift-6.0-DEVELOPMENT-SNAPSHOT-2024-09-17-a
).main
or1.22.2
) and SwiftNIO (main
).Also, building without the Static Linux SDK succeeds:
Example Swift Package
Here's a basic
Package.swift
manifest that can be used:System & version information
Sonoma 14.6.1