[stdlib] Fix return type of swift_{uint64,int64,float*}ToString

[zhuowei]

The return type of these functions are uint64_t in Stubs.cpp but UInt in the Swift code; this changes the Swift code to match the C++ return type.

Found when compiling the stdlib for WebAssembly, which requires that all return types match: UInt maps to i32 while uint64_t maps to i64, so functions calling these functions fail the validation.

[compnerd]

CC: @airspeedswift

[MaxDesiatov]

@airspeedswift would you be able to have a look please? Is there anyone else who could be pinged about reviewing this PR?

[stephentyrone]

@swift-ci please smoke test

[stephentyrone]

Thanks @zhuowei. Sorry that we didn't see this earlier. FWIW, your best bet is to tag me or @tbkka for this stuff.

[stephentyrone]

N.B. for anyone playing along at home: this was a "safe" return type mismatch because the actual implementation has a signature compatible with the signature used; the high 32b of the result were simply ignored by the caller on 32b targets (both i386 and armv7 return 64b results in register, with the low part in the register where a 32b result would go), but they are semantically guaranteed to be zero anyway.

[tbkka]

The return value here is the length of the formatted string, so a 32-bit value would be preferable to avoid overhead on 32-bit platforms. I believe this is all internal, so changing the type won't break the ABI.

Of course, that might mean touching more places to get the types to line up all the way down.

[MaxDesiatov]

Does it mean that this PR needs any more changes to pass the review and be merged? I'm a co-maintainer of @swiftwasm, and as far as I'm aware @zhuowei is not actively maintaining it currently, but I have access to the PR branch and I'm ready to push it forward and to apply any changes if needed.

[stephentyrone]

I agree with @tbkka that it would be better if these just returned int32. But, the cpp functions are marked SWIFT_RUNTIME_STDLIB_API, so we formally can't modify them (they are API), and the difference in efficiency is minimal.

@MaxDesiatov since we know that the result is always in-range, can you replace the Int inits (line 172 and similar) with Int(truncatingIfNeeded: ...)? This will eliminate the check so that the only overhead on 32b platforms is zeroing out a register, which is sufficiently cheap to not worry about.

[tbkka]

But, the cpp functions are marked SWIFT_RUNTIME_STDLIB_API, so we formally can't modify them...

Phooey. In that case, this is the right fix.

[stephentyrone]

Actually, I'll just merge this and make the other change myself as a follow on. Thanks all!