In Xcode 16 SDKs there seem to be two `errno` visible for some files,
one in the `Darwin` module, and one in the `_errno` module (which seems
new for this Xcode version).
Disambiguate the references by prepending `Darwin`, which should be the
one that was being used before Xcode 16 SDKs.
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Based on its argument names and messages, `expectEqual` and friends expects the expected value of the calculation being tested to be provided as its first argument, and the actual value as the second:
```
expectEqual(4, 2 + 2)
```
This does not always match actual use -- folks like myself find the opposite ordering far more natural:
```
expectEqual(2 + 2, 4)
```
`expectEqual` currently uses the `expected`/`actual` terminology in its failure messages, causing confusion and needless suffering.
Change `expectEqual`'s declaration and error messages to use a naming scheme that does not assume specific roles for the two arguments. (Namely, use `first`/`second` instead of `expected`/`actual`.)
An alternative way to solve this would be to use argument labels, as in `expectEqual(expected: 4, actual: 2 + 2)`, or to introduce some sort of expression builder scheme such as `expect(2 + 2).toEqual(2)`. These seem needlessly fussy and overly clever, respectively.
The concurrency runtime now deploys back to macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0, which corresponds to the 5.1 release of the stdlib.
Adjust macro usages accordingly.
StdlibUnittest is built with `-disable-implicit-concurrency-module-import`
and it uses concurrency feature. Therefore, without explicit import,
StdlibUnittest.swiftmodule doesn't have `IMPORTED_MODULE` entry of
`_Concurrency`. And it results link-failure when static linking because
swift_Concurrency is not linked.
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
The support for running concurrency tests individually with filters
invoked the non-concurrent supporting `runOneTest` accidentally. Fix
this to us the `runOneTestAsync` allowing the single async test to be
run in process again. This is needed for ease of debugging (and in the
case of Windows, the only option for debugging).
For various reasons, it can be useful/interesting to create builds of
Swift that minimize dependencies. Let's try to keep that working as long
as we can.
This patch plumbs through the ability to run async code in the standard
library unittests. The async start-point is `runAllTestsAsync` and must
be called from an async context. For now, that means calling through
async-main.
This replaces swiftMSVCRT with swiftCRT. The big difference here is
that the `visualc` module is no longer imported nor exported. The
`visualc` module remains in use for a singular test wrt availability,
but this should effectively remove the need for the `visualc` module.
The difference between the MSVCRT and ucrt module was not well
understood by most. MSVCRT provided ucrt AND visualc, combining pieces
of the old MSVCRT and the newer ucrt. The ucrt module is what you
really wanted most of the time, however, would need to use MSVCRT for
the convenience aliases for type-generic math and the deprecated math
constants.
Unfortunately, we cannot shadow the `ucrt` module and create a Swift SDK
overlay for ucrt as that seems to result in circular dependencies when
processing the `_Concurrency` module.
Although this makes using the C library easier for most people, it has a
more important subtle change: it cleaves the dependency on visualc.
This means that this enables use of Swift without Visual Studio for the
singular purpose of providing 3 header files. Additionally, it removes
the need for the installation of 2 of the 4 support files. This greatly
simplifies the deployment process on Windows.
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.
Previously, metadata prespecialization for classes only occurred when
all of a specialized generic class's ancestors were themselves generic.
Here, that requirement is lifted so that generic classes with concrete
ancestors are also eligible for prespecialization.
These should hopefully all be uncontroversial, minimal changes to deal
with progressing the build to completion on OpenBSD or addressing minor
portability issues. This is not the full set of changes to get a
successful build; other portability issues will be addressed in future
commits.
Most of this is just adding the relevant clauses to the ifdefs, but of
note in this commit:
* StdlibUnittest.swift: the default conditional in _getOSVersion assumes
an Apple platform, therefore the explicit conditional and the relevant
enums need filling out. The default conditional should be #error, but
we'll fix this in a different commit.
* tgmath.swift.gyb: inexplicably, OpenBSD is missing just lgammal_r.
Tests are updated correspondingly.
* ThreadLocalStorage.h: we use the pthread implementation, so it
seems we should typedef __swift_thread_key_t as pthread_key_t.
However, that's also a tweak for another commit.
This was already being done for the stderr, but not for stdout. Doing
this means that we no longer get spurious carriage returns on the stdout
output stream on Windows. This is needed for supporting the
validation test suite on Windows.
The comment in the function said:
// This function is implemented in Objective-C because Swift does not support
// failing initializers.
which hasn't been true since swift 1.1.
StdlibUnittest uses an AtomicBool to track whether a failure has ocurred
in a test. Before this, expectFailure could have a false-positive
failure due to a race condition on the _anyExpectFailed.
The following interleaving would trigger the issue:
A: loads false
A: stores false
B: loads false
A: stores true
B: stores false
A: loads false (after body)
This causes A to see a false-positive failure.
When testing runtime lookup changes, we want to make sure each test runs in isolation. Add a new modifier, `.requireOwnProcess()`, to enable tests to guarantee they’re run in isolation.
Windows uses carriage returns and newlines. The string matching is
sensitive to this. Simply erase carriage returns from the standard
error stream to compensate.
Windows uses DOS line endings which appear through the PIPE endpoints.
We currently split on line feeds only, leaving the carriage return in
place. Without this, the messages on the communication pipe would not
be interpreted correctly.
This is in preparation to make the code here more target agnostic for
porting to the Windows threading primitives. This is used pretty
extensively in the tests, so disabling tests would lose a chunk of
coverage.
