SystemExtras: stop shadowing the C stat type (fixes build with swift-system 1.7.0)

[jackguac]

Summary

SystemExtras fails to compile when the resolved swift-system is 1.7.0:

Sources/SystemExtras/FileOperations.swift:335:22: error: cannot convert value of type 'Stat' to specified type 'stat'
335 |     var stat: stat = stat()
    |                      `- error: cannot convert value of type 'Stat' to specified type 'stat'
Sources/SystemExtras/FileAtOperations.swift:190:22: error: cannot convert value of type 'Stat' to specified type 'stat'

Both call sites write:

var stat: stat = stat()

The local variable is named stat, which shadows the imported C stat type. swift-system 1.7.0 adds a public top-level struct Stat. With that type now in scope, the unqualified initializer stat() no longer resolves to the C stat struct — it binds to swift-system's Stat (whose initializer is even throws), so the value is a Stat while the annotation still wants the C stat, and the file no longer type-checks.

WasmKit's Package.swift requires swift-system with an open upper bound (from: "1.5.0"), so any consumer whose dependency graph floats swift-system to 1.7.0 hits this — even with WasmKit itself pinned. swift-system ≤ 1.6.x is unaffected (no top-level Stat).

Fix

Rename the local so it no longer shadows the C type, and construct it through an explicitly-typed .init() so the C stat type is selected unambiguously regardless of which swift-system version resolves:

var statBuffer: stat = .init()

No behavior change — statBuffer is still a zeroed C stat passed by reference to system_fstat / system_fstatat. The two affected functions are FileDescriptor._attributes() (fstat) and FileDescriptor._attributes(at:options:) (fstatat).

Verification

Built SystemExtras (and the full package) on macOS / Apple Swift 6.3.2 with swift-system pinned to 1.7.0 (reproduces the failure on main, compiles clean with the fix) and to 1.6.4 (still compiles — backward compatible):

swift-system	main	with this PR
1.7.0	❌ compile error	✅ Build complete!
1.6.4	✅	✅ Build complete!

Notes

• A follow-up worth considering separately: tightening WasmKit's swift-system requirement to an explicit supported range so consumers get a clear resolution diagnostic rather than a deep compile error when a future swift-system changes these APIs. This PR is the minimal source fix and is independent of that.

[jackguac]

This is just a variable rename to avoid the collision mentioned in the description, so if there's any chance of getting this in soon that would be great to save me a fork!

[MaxDesiatov]

Thanks for the contribution! The change makes sense to me overall, but it introduces CI failures. Would you be able to address those?

[jackguac]

Thanks for the contribution! The change makes sense to me overall, but it introduces CI failures. Would you be able to address those?

Hi @MaxDesiatov - thanks for flagging, sorry I didn't see this earlier.

I've had a look into this and I'm 99% sure it's unrelated to this change (especially given this change is so minor).

• The latest version of swift-system was published roughly 14 hours ago.
• That version restructured the stat members into CSystem, and swift-nio's _NIOFileSystem doesn't yet build against it on Linux/Swift 6.2.
• The last WasmKit build that succeeded happened an hour before the swift-system bump

To get CI to pass, I've pinned swift-system to pre 1.7.0 - but it's a little unrelated to my change here so if you'd prefer to fix separately or you want me to open a separate branch, let me know.

It works locally for me now against Mac and Linux but I'll keep an eye on the CI steps when you run those.

Edit: this was the swift-system push a few hours ago: https://github.com/apple/swift-system

[jackguac]

Looks like everything passed except formatting - pushed a commit for that

[jackguac]

All green now! :) Thanks for your patience

[jackguac]

Incidentally this will fix a few of the other PRs' CI checks I think because they started failing for the same reason as the above^