Swift Numerics started randomly having compilation errors since the March 13 trunk Swift 6.2 snapshot

[finagolfin]

Description

I started seeing this error on my Android CI lately, which I can reproduce on Fedora 40 x86_64 with the native command given below also:

swift-numerics/Tests/IntegerUtilitiesTests/SaturatingArithmeticTests.swift:170:32: error: member 'max' in 'Int8' produces result of type 'SignedInteger', but context expects 'Int8'
168 |     _ type: T.Type, rounding rule: RoundingRule
169 |   ) {
170 |     for count in Int8.min ... .max {
    |                                `- error: member 'max' in 'Int8' produces result of type 'SignedInteger', but context expects 'Int8'
171 |       testSaturatingShift(0, count, rounding: rule)
172 |       for bits in 0 ..< T.bitWidth {

swift-numerics/Tests/IntegerUtilitiesTests/SaturatingArithmeticTests.swift:170:32: error: contextual member reference to static property 'max' requires 'Self' constraint in the protocol extension
168 |     _ type: T.Type, rounding rule: RoundingRule
169 |   ) {
170 |     for count in Int8.min ... .max {
    |                                `- error: contextual member reference to static property 'max' requires 'Self' constraint in the protocol extension
171 |       testSaturatingShift(0, count, rounding: rule)
172 |       for bits in 0 ..< T.bitWidth {

Swift.SignedInteger:1:11: note: missing same-type requirement on 'Self'
1 | extension SignedInteger where Self : FixedWidthInteger {
  |           `- note: missing same-type requirement on 'Self'
2 |     @inlinable public init<T>(_ source: T) where T : BinaryInteger
3 |     @inlinable public init?<T>(exactly source: T) where T : BinaryInteger

What's extremely strange is that simply re-running the same build command a few more times always results in the build completing! I thought it might be a concurrency race, but I can reproduce when adding the -j 1 flag also.

Reproduction

1. cd swift-numerics
2. ~/swift-DEVELOPMENT-SNAPSHOT-2025-03-13-a-fedora39/usr/bin/swift build --build-tests

Expected behavior

All tests to build every time, as they do with the prior March 10 trunk snapshot.

Environment

Swift 6.2 since March 13 building natively for linux x86_64 and cross-compiling from a linux or macOS host for Android

Additional information

I thought this wasn't reproducible when building natively on linux at first, because it would build fine initially. Run swift package clean and rebuild, running both commands five times to reliably trigger this compilation failure.

[finagolfin]

@artemcm, looking internal to the Swift compiler itself for concurrency that may be causing this random failure, I tried appending the flag you added in #68252 a couple years ago -Xswiftc -Xfrontend -Xswiftc -no-parallel-scan -j 1 to the above command, but it had no effect, ie the compilation error would randomly show up and then go away as always. Is there some other form of internal concurrency in the Swift compiler that might be causing this random flakiness?

[finagolfin]

Some more data: my Android CI tries to build the latest Numerics commit with the latest trunk toolchain and Android SDK bundle everyday, for each of the three Android architectures AArch64, x86_64, and armv7 from linux and macOS. I ran the trunk build a dozen times and it was never able to complete all three arch builds, failing something like 23 out of 35 attempts for an abysmal failure rate of 65.7%, seemingly worse on macOS.

@stephentyrone, you're probably going to start seeing reports of this as more people build Numerics with the trunk toolchain, just letting you know.

[finagolfin]

I've gone ahead and disabled cross-compiling Numerics with the trunk toolchain and Android SDK bundle on my daily Android CI, finagolfin/swift-android-sdk@60c72d1ff, so I can get the rest of the trunk portion of that CI building and testing again. If anyone knows what's going on here, let me know: I'm still able to reproduce with the latest Mar. 28 trunk snapshot toolchain building the Numerics tests natively for Fedora linux x86_64.

Since this is only reproducible with Numerics and the trunk 6.2 toolchain, some interaction is going on between these two.

@marcprux, can you reproduce with the trunk OSS toolchain for macOS? Hopefully this is the last time I ask you about macOS. 😉

[marcprux]

@marcprux, can you reproduce with the trunk OSS toolchain for macOS? Hopefully this is the last time I ask you about macOS. 😉

Yeah, I see the exact same thing on macOS. It fails 7 out of 10 builds for me, and -Xswiftc -Xfrontend -Xswiftc -no-parallel-scan -j 1 makes no difference.

~/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2025-03-28-a.xctoolchain/usr/bin/swift build -v -Xswiftc -Xfrontend -Xswiftc -no-parallel-scan -j 1 --build-tests

I've attached the verbose build logs from 10 runs, in case it might help shed light on the issue (e.g., if it has something to do with indeterministic ordering of compilation).

swift-numerics-build-logs.zip

[finagolfin]

something to do with indeterministic ordering of compilation

Oh, that's an interesting theory: I took a look at SwiftPM commits before March 13 and nothing stands out in the messages.

@bkhouri or @plemarquand, any insight here?

[finagolfin]

I just tried this with the latest trunk snapshots and can no longer reproduce with the April 3 trunk snapshot and later, so I'm enabling building Numerics with these trunk toolchains again on my Android CI. Looking at the commits added before that tag, could be fixed by #80443?