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.

[finagolfin]

Now that my linked fix is in the latest releases, are you seeing any other problems with newer glibc? Android's Bionic C library has been adding a lot of nullability annotations, so I and others have been adding checks in the Swift stdlib and corelibs where needed.

If the latest glibc isn't causing any further problems, please close whenever you think this is resolved.