This adds the swiftMSVCRT module which is similar in spirit to swiftGlibc and
swiftDarwin, exposing the Microsoft C Runtime library to swift. Furthermore,
disable pieces of the standard library which are not immediately trivially
portable to Windows. A lot of this functionality can still be implemented and
exposed to the user, however, this is the quickest means to a PoC for native
windows support.
As a temporary solution, add a -DCYGWIN flag to indicate that we are building
for the cygwin windows target. This allows us to continue supporting the cygwin
environment whilst making the windows port work natively against the windows
environment (msvc). Eventually, that will hopefully be replaced with an
environment check in swift.
pthreads is not available on non-POSIX platforms (i.e. Windows). Restrict the
target platforms that we build SwiftPrivatePthreadExtras and things which depend
on it.
Support building SwiftPrivateLibcExtras for a number of targets simultaneously.
This will enable cross-compiling the standard library for multiple foreign
targets.
This is part 1 of many to enable leaks tracking in the unit test suite.
To compile with leak tracking enabled run
swift/utils/build-script -- --swift-runtime-enable-leak-checker
Changes:
- Added bounds checks to Unsafe*BufferPointer's subscript getter and setter
- Added tests for Unsafe*BufferPointer's subscript getter for all four range types
Changes:
- Parameterized a number of tests in CheckCollectionType.swift.gyb expected to crash during one or more runthroughs
- Fixed an issue with the tests uncovered by this change
Changes:
- Moved only-used-once helper methods into call sites
- Parameterized tests that might expect a crash
- Fixed some comments and formatting; renamed some test helper APIs
On Linux it used to be possible to build only the stdlib, without the
SDK overlays, like so:
```
utils/build-script -- --build-swift-stdlib --build-swift-sdk-overlay=0
```
However this invocation now results in the following error:
```
+ /usr/bin/cmake --build /home/modocache/GitHub/apple/build/Ninja-ReleaseAssert/swift-linux-x86_64 -- -j8 all swift-stdlib-linux-x86_64
ninja: error: '/home/modocache/GitHub/apple/swift/stdlib/private/SwiftPrivatePthreadExtras/swiftGlibc-linux-x86_64', needed by 'stdlib/private/SwiftPrivatePthreadExtras/linux/x86_64/SwiftPrivatePthreadExtras.o', missing and no known rule to make it
utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
```
The problem is that SwiftPrivatePthreadExtras is always built, regardless
of whether the SDK overlay is built. I believe there's an explicit check
against this for Darwin platforms to prevent the same error.
The solution, implemented here, is to add the same check for Linux.
* [stdlib] Adding new tests for collection indices
Changes:
- Added tests for 'index(next:)'
- Added tests for all 'formIndex' API variants
- Modified existing tests to better test bidirectional collections
* Fixes reflecting review feedback
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
Due to a modeling error in the type checker's folding of type
references into type expressions, code such as "strideof(Int)" would
be accepted without the required ".self". Commit
4a60b6cbf4 fixes the modeling issue but
left the historical accepts-invalid; now, diagnose these cases with a
warning + Fix-It to ease the transition.
Fixes SR-899.
