Description
Description
On Glibc 2.38 (potentially other versions, but this is the one that reproduces), the parameter to fclose is marked __nonnull. When imported into Swift, that means that the parameter is made non-optional. This breaks some code in swift-tools-support-core:
Specifically, this causes a build failure in the Nixpkgs derivation for Swift, as reported by a friend of mine:
# nix shell 'nixpkgs#swift'
error: builder for '/nix/store/0g4cg7yvj9xlh5rpkbxb8i1jgpfqvb6b-swift-tools-support-core.drv' failed with exit code 1;
last 10 log lines:
> ^
> /build/swift-tools-support-core-ac4871e/Sources/TSCBasic/FileSystem.swift:458:24: note: coalesce using '??' to provide a default when the optional value contains 'nil'
> defer { fclose(fp) }
> ^
> ?? <#default value#>
> /build/swift-tools-support-core-ac4871e/Sources/TSCBasic/FileSystem.swift:458:24: note: force-unwrap using '!' to abort execution if the optional value contains 'nil'
> defer { fclose(fp) }
> ^
> !
> ninja: build stopped: subcommand failed.
For full logs, run 'nix log /nix/store/0g4cg7yvj9xlh5rpkbxb8i1jgpfqvb6b-swift-tools-support-core.drv'.As of Xcode 15.1, the macOS SDK does not have a similar non-null marking, resulting in a type signature mismatch across platforms.
Reproduction
Modified from the above-linked code in swift-tools-support-core:
import Glibc
let fp = fopen("test.txt", "r")
if fp == nil {
fatalError()
}
defer { fclose(fp) }Expected behavior
Code builds without issue.
Environment
The current nixpkgs derivation for Swift includes Swift 5.8 and glibc 2.38. Other reproductions of this issue (apple/swift-nio-ssl#429, jocosocial/swiftarr#244) occur in both Swift 5.8 and 5.9, but both with glibc 2.38.
Additional information
Nixpkgs is currently working around this issue by patching swift-tools-support-core to force-unwrap the handle returned by fopen (NixOS/nixpkgs#269015) but finding some way to reconcile this in Swift's glibc overlay would be ideal.