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.