This is for the 'freestanding' build to stop assuming the platform has argc/argv.
- Introduce a new sub-library, libswiftCommandLineSupport.a
- Move stubs/CommandLine.cpp into this library
- Conditionally embed it into libswiftCore
- Conditionally embed it into libswiftPrivateLibcExtras if not in libswiftCore to support testing
- Add SWIFT_STDLIB_HAS_COMMANDLINE CMake (and build-script) flag
Certain traps can't be supported on WASI, such as expectations for crashes, `setjmp` use, dynamic linking, multi-threading etc. These tests are marked as `UNSUPPORTED` when targeting Wasm/WASI.
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
Platform defines sem_open in Swift that calls through to the underlying
platform functions because sem_open is variadic. However, the
definitions here assume sem_t is non-nullable, but this assumption only
holds when the platform has nullability annotations on the semaphore
type, or the semaphore type on the platform is not an opaque pointer.
On OpenBSD specifically, the semaphore type is an opaque pointer without
any nullability annotations. This means that the type gets inferred as
UnsafeMutablePointer<sem_t?>? instead of UnsafeMutablePointer<sem_t>?.
To make sure the pointer values returned and their types match, we
introduce a conditional typealias.
The other option is to coerce everything to UnsafeMutablePointer<sem_t>?
but this would be a rather blunt instrument. While sem_open is public in
stdlib, it is not so much codified stdlib API, so this is a slightly
nicer approach.
Different tests used different os checks for importing Darwin, Glibc and
MSVCRT. This commit use the same pattern for importing those libraries,
in order to avoid the #else branches of the incorrect patterns to be
applied to the wrong platform. This was very normal for Android, which
normally should follow the Linux branches, but sometimes was trying to
import Darwin or not importing anything.
The standarized pattern imports Darwin for macOS, iOS, tvOS and watchOS.
It imports Glibc for Linux, FreeBSD, PS4, Android, Cygwin and Haiku; and
imports MSVCRT for Windows. If a new platform is introduced, the else
branch will report an error, so the new platform can be added to one of
the branches (or maybe add a new specific branch).
In some cases the standard pattern was modified because some test required
it (importing extra modules, or extra type aliases), and in some other
cases some branches were removed because the test will not have used
them (but it is not exhaustive, so there might be some unnecessary
branches).
This should, at least, fix three tests for Android (the three
dynamic_replacement*.swift ones).
This adjusts the standard library test suite to mostly pass on Windows.
The remaining failures are due to various cases:
- memory corruption (`_swift_stdlib_free` in swiftDemangle)
- heap corruption (canGrowUsingRealloc)
- withVAList failure (unresolved)
- unicode handling on the command line
Android differs in subtle ways from Linux. For example sem_open is
completely unimplemented, and always returns ENOSYS. None of the
test using sem_open were going to work.
Additionally the l_len field of the flock struct is typed as
__kernel_off_t, which doesn't have the same size as off_t.
Finally, the current working directory is always /, so creating
relative files will fail. We have to find the executable directory
and create the file there.
