[Windows] Fix Int32(bitPattern:) call failure

[jmschonfeld]

The Windows toolchain build for x86 was failing with:

C:\Users\swift-ci\jenkins\workspace\swift-PR-build-toolchain-windows\swift-foundation\Sources\FoundationEssentials\ProcessInfo\ProcessInfo.swift:141:34: error: cannot convert value of type 'DWORD' (aka 'UInt') to expected argument type 'UInt32'
139 |     var processIdentifier: Int32 {
140 | #if os(Windows)
141 |         return Int32(bitPattern: GetProcessId(GetCurrentProcess()))
    |                                  `- error: cannot convert value of type 'DWORD' (aka 'UInt') to expected argument type 'UInt32'
142 | #else
143 |         return Int32(getpid())

In SCL-F we just call Int32(GetProcessId(GetCurrentProcess())) instead which works so this changes the swift-foundation implementation to do the same so that it is compatible across architectures.

[jmschonfeld]

@swift-ci please test

[jmschonfeld]

@swift-ci please test Windows platform

[compnerd]

I guess this is fine for now. The problem is that GetProcessId returns an unsigned value, so this can now trap right?

[jmschonfeld]

I guess this is fine for now. The problem is that GetProcessId returns an unsigned value, so this can now trap right?

Ah that's true, I was trying to remember why we did this and I think that's why. Perhaps instead I should use return Int32(bitPattern: UInt32(GetProcessId(GetCurrentProcess()))) so that it traps if the value is more than 32 bits wide but still converts to a negative number instead of trapping if it's just within Int32.max ..< UInt32.max. Do you think that'd be better?

[compnerd]

Yes, I think that described behaviour was what we were after and missed the need for the UInt32 initialiser.

[jmschonfeld]

@swift-ci please test

[jmschonfeld]

@swift-ci please test Windows platform

[jmschonfeld]

@swift-ci please test Windows platform

[jmschonfeld]

The windows toolchain build got a lot farther with this change, and the Windows test failure here is the known test_writeToSpecialFile test failure