This applies more annotations in the `INTERNAL_CHECKS_ENABLED` disabled
paths, Windows, 32-bit, and non-ObjC paths. Interestingly enough, there
are a couple of compiler intrinsics which are also uncovered.
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
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.
This teaches ClangImporter to respect the `_Nonnull`/`_Nullable` arguments on templated function parameters.
Previously Swift would only import a non-annotated function overload. Using an overload that has either `_Nonnull` or `_Nullable` would result in a compiler error. The non-annotated overload would get imported with incorrect nullability: Swift would always assume non-null pointers, which was inconsistent with non-templated function parameters, which are mapped to implicitly unwrapped optionals.
With this change all three possible overloads are imported, and all of them get the correct nullability in Swift.
rdar://151939344
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
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
