`arm_neon_state32_t` and `arm_neon_state64_t` are not bridged properly

[nmggithub]

Description

These two structs make use of __uint128_t which seems to only recently have been implemented in Swift.

Technically, they use __uint128_t arrays, but I don't think that distinction matters that much.

Their definitions are here: https://github.com/apple-oss-distributions/xnu/blob/xnu-10063.101.15/osfmk/mach/arm/_structs.h#L529

Note that the above definitions are from xnu-10063.101.15, which released with macOS 14.6. Apple hasn't released the sources for the version of XNU used in Sequoia, but these headers are also in the SDK's included with XCode. The definitions for these structs doesn't seem to have changed from macOS 14.6 to macOS 15.

Reproduction

import Darwin.Mach
func printBitwiseCopyable(_ value: BitwiseCopyable) { print(value) }
printBitwiseCopyable(arm_neon_state32_t()) // error
printBitwiseCopyable(arm_neon_state64_t()) // error
printBitwiseCopyable(arm_pagein_state_t()) // no error

Expected behavior

The code compiles.

Environment

swift-driver version: 1.115 Apple Swift version 6.0 (swiftlang-6.0.0.9.10 clang-1600.0.26.2)
Target: arm64-apple-macosx15.0

Additional information

I made my own test package with a C header target (with my own struct that uses __uint128_t and a Swift target that imports it. It also exhibited this behavior, so this might actually be an issue with my setup, but I'm not sure.

EDIT: To note, I'm using BitwiseCopyable conformance as analogous to "was the __uint128_t bridged?" because it seems to be the case in my experience (as the rest of the members in these structs are indeed bridged correctly, only the __uint128_t members aren't).

On that note, I think it is a good thing that BitwiseCopyable conformance doesn't happen for C structs that aren't fully bridged. Good job!

[DougGregor]

@stephentyrone Is this expected?

[stephentyrone]

I don't think we've implemented bridging yet.

[stephentyrone]

We should, though, and this is a perfectly reasonable excuse to do so.

[nmggithub]

I don't think we've implemented bridging yet.

The proposal I was linked says:

• Status: Implemented (Swift 6.0)

[...]

The clang importer will be updated to bridge __uint128_t to UInt128 and __int128_t to Int128. Source: https://github.com/swiftlang/swift-evolution/blob/main/proposals/0425-int128.md

Is bridging still a "will" case then, despite the proposal being marked as "implemented"?

Also, on a tangential note, both in the Apple docs, and when working with Swift in my editor, UInt128 is marked as only being available on macOS 15+. But since this is a toolchain implementation isn't OS version irrelevant? I can open a separate issue if that is another bug.

[stephentyrone]

But since this is a toolchain implementation isn't OS version irrelevant?

No. New standard library types always have availability requirements.

[nmggithub]

But since this is a toolchain implementation isn't OS version irrelevant?

No. New standard library types always have availability requirements.

Interesting. Is this just a design decision or is there truly something that would make types like UInt128 binary-incompatible with older OS's?

[grynspan]

The type metadata isn't available on older ABI-stable OSes—it simply doesn't exist there. So any operation that needs the type metadata (which includes allocation, generics, any non-frozen API referencing the type…) can't function.