To implement swift_errorBridgingInfo, the Foundation overlay needs to import private runtime headers. Now that we cannot statically link the Foundation overlay, there is no point to keeping this workaround in the overlay any more.
This effectively reverts https://github.com/apple/swift/pull/16677.
rdar://problem/57809306
Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
In Errors.cpp, PRIxPTR is used in a format string:
constexpr const char *format = "%-4u %-34s 0x%0.16" PRIxPTR " %s + %td\n";
This fails to build because of upstream changes in STLExtras:
049043b598 (diff-43fc25e3af55e1ae97f17ef051d68aa4)
This patch merely adds the include for the needed PRIxPTR define.
(cherry picked from commit 0529fbedca)
This makes Array.first much small and more efficient.
Without this, Array.first compiled down to RandomAccessCollection.first, which ended up in pretty unefficient code.
rdar://problem/46291397
Use _CocoaArrayWrapper.endIndex which returns the NSArray.count.
In the old version, "count" translated to RandomAccessCollection.count, which ended up in multiple calls to endIndex.
Separate out the host build of SwiftRemoteMirror from the "target" build
(the host for the standard library may be different from the host for
the compiler). Restructure the build to ensure that we use the correct
compiler for building the SwiftRemoteMirror for the host. This fixes a
build issue when building for Linux AArch64.
The return type of getNumRuntimeFunctionCounters is defined as uint64_t in RuntimeInvocationsTracking.cpp, but it has return type Int in RuntimeFunctionCounters.swift.
Found when compiling the stdlib for WebAssembly, as WebAssembly validates return types. uint64_t corresponds to i64, but Int is i32, so the program fails validation.
The swift_floatNToString, swift_int64ToString, and swift_uint64ToString functions all return a uint64_t from c++. This is a historical accident, but these are SWIFT_RUNTIME_STDLIB_API, which means that we can't trivially change the return type. The result should naturally be size_t or int (it's always small enough to fit into *any* c integer type). However, we can elide the check in the caller at the point that the result is converted to Int, because we know that the check will always pass. This makes it so that the only overhead the wrong type introduces on 32b platforms is zeroing a register, which is free or nearly-free.
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.
We would build two copies of swiftReflection, one for the host and one
for the target. However, the compiler configuration cannot be swapped
out in the middle as we were attempting to do. This would result in a
failure to build sometimes due to the missing dependency on the wanted
compiler. More importantly, it would also use the wrong compiler when
building the library. Although this duplicates the source paths,
correctness is preserved.
