Requests to sleep until a negative timestamp would result in sleeping
until `UINT64_MAX` nanoseconds from the start of the relevant clock,
which is about 585 years.
rdar://154346018
Reflection metadata lookup failures are notoriously difficult to debug
because there is no error handling in TypeLowering outside of
compile-time #ifdef'd fprintf(stderr) calls. The nicest thing to do
would be to adopt llvm::Expected<> but TypeLowering is also included
in the standard library, which only has access to a tiny subset of the
LLVM Support library. This patch adds a place to store a pointer to
the first encountered error, which can then be converted to an
llvm::Error at the API level.
(cherry picked from commit 868c9912aa)
This fixes a regression where projects that use the C++ stdlib overlay stop building because of a linker error:
```
ld: Shared cache eligible dylib cannot link to ineligible dylib '@rpath/libswiftCompatibilitySpan.dylib'.
```
Usages of `Span<T>` would generally cause a type metadata accessor to be emitted for `Swift.Span`. This becomes a problem with backdeployment, since Span is partially defined in a compatibility binary.
This change adds `@_alwaysEmitIntoClient` to generic usages of `Span` to prevent the type metadata accessor from being emitted into `libswiftCxx.a`.
rdar://152192080
- **Explanation**:
This is an implementation for the feature
https://github.com/swiftlang/swift-evolution/pull/2726
- **Scope**:
This is targeted specifically to the Observation module, no language or
runtime changes
- **Issues**:
- **Original PRs**:
https://github.com/swiftlang/swift/pull/79817
- **Risk**:
Low
- **Testing**:
This was tested in external forms (which need to be merged in)
- **Reviewers**:
---------
Co-authored-by: Stephen Canon <scanon@apple.com>
In task-to-thread concurrency mode, `_getMainExecutorAsSerialExecutor`
returns `SerialExecutorRef::generic()`, which is, give or take, NULL.
Unfortunately we'd declared it as returning `any SerialExecutor`,
rather than `(any SerialExecutor)?`, and then the `getMainExecutor()`
function was calling `asUnownedSerialExecutor()` on it, which then
crashes.
rdar://153152063
Adds support for printing a C++ foreign reference in Swift.
Also skips metadata of private fields in C++ records imported as Swift classes, following up on #81035
(cherry-picked from 848fad0021)
Without this, llvm would sometimes wrongly assume there's no indirect
accesses and the optimizations can lead to a runtime crash, by
optimizing away initializing options properly.
Resolves rdar://152548190
The _Builtin_float and Synchronization modules are getting the SDK_NAME encoded in their embedded modules, preventing them from being used outside of macOS in embedded mode.
rdar://152665402
Update availability for CxxSpan<->Span, fix lifetimebound on parameters
with reference type
Because swift-ide-test doesn't care about typechecking,
std-span-interface.swift passed despite containing 2 separate errors.
This updates the test file to properly exercise the entire compilation
pipeline for the macro expansions, by running swift-frontend
-emit-module and calling each macro expansion.
The first issue was that CxxSpan initializers taking [Mutable]Span still
had their availability set to Swift 6.2+, even after back-deploying
caused [Mutable]Span to have availability back to Swift 5.0. Since
_SwiftifyImport expansions copy the availbility of Span, this resulted
in the macro expansions calling unavailable initializers. Interestingly
enough, this manifested itself in the form of a tripped assert in SIL
verification, because although we do now typecheck the expansions from
_SwiftifyImport, the compilation can still keep going after
`shouldEmitFunctionBody` returns false: the macro expansion declaration
is still there, but is now missing its definition, despite not being
external.
The second issue was when parameters with C++ reference types were
annotated with `[[clang::lifetimebound]]`. For parameters with a type
that is `Escapable`, this is normally done using `@lifetime(borrow
foo)`. However C++ reference parameters are imported as `inout`, which
requires the `@lifetime(&foo)` syntax.
rdar://151493400
rdar://151678415
(cherry picked from commit 262a53f599)
statusCompletePendingReadyWaiting(), offer(), and poll() did a one-off compare_exchange_strong which could fail if the group was concurrently cancelled. Put these into loops so that they are retried when needed.
DiscardingTaskGroup creation passed the group result type as the task result type. waitAll() would then use the group result type when collecting task results. Since the task result type is always Void in this case, this would overflow the result buffer if the group result type was larger. This often works as it writes into the free space of the task allocator, but can crash if it happens to be at the end of a page or the group result type is particularly large.
rdar://151663730
(cherry picked from commit 5be22fa7cc)
