Recent versions of glibc marks some function parameters as __nonnull, changing type signatures

[QuietMisdreavus]

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:

https://github.com/apple/swift-tools-support-core/blob/0583d2619102bb7d579e357df191977c0027cd11/Sources/TSCBasic/FileSystem.swift#L492-L497

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.

[QuietMisdreavus]

cc @al45tair, @MaxDesiatov told me you were working in this area recently

[finagolfin]

Does swiftlang/swift-tools-support-core#444 fix this for you? I backported that pull to 5.9 and 5.10 also and run it on my Android CI.

[QuietMisdreavus]

That looks similar to the nixpkgs patch, just a bit cleaner. I don't personally run nix/NixOS, but i can pass that patch along and see if it helps.