This patch adds a new SymbolicExtendedExistentialTypeRef kind, and
wires it up in TypeDecoder, TypeRefBuilder, TypeLowering, and
ASTDemangler.
This is tested indirectly via the matching LLDB commit.
a550080 added a call to the new initializer, but that call
came from a function annotated with `StdlibDeploymentTarget 6.2`,
rather than `SwiftStdlib 6.2`, while the initializer was set to
`SwiftStdlib 6.2`. This will fail in some build configurations
(specifically where the target being built for is older than that
implied by `SwiftStdlib 6.2`).
rdar://157217460
Amend formatting of `Substring.utf8Span` example code.
Use DocC tables in `Unicode.UTF8.ValidationError` overview.
---------
Co-authored-by: Alex Martini <amartini@apple.com>
Where someone has told a target library to build for a _newer_ target
than the current deployment target, we need to respect that newer
target when setting StdlibDeploymentTarget for that target library.
This trips us up when testing against older systems.
rdar://155841439
Embedded WASI: fix some concurrency tests
The test was crashing due to `swift_unreachable("custom executors not supported in embedded Swift")` line in `swift_task_enqueueImpl`, as the corresponding non-embedded codepath was relying on an unspecialized generic function `_swift_task_enqueueOnExecutor` defined in `Executor.swift`. Unspecialized generics are unavailable in Embedded Swift, and such `@silgen_name` function can't be specialized when used from concurrency runtime code written in C/C++. We can redefine this function for Embedded Swift using a class-bound existential instead, and re-enable this codepath with a slightly different call that avoids the use of unavailable `swift_getObjectType` function from the non-embedded runtime.
rdar://156996468
Fixes a build problem when using a mainline compiler with a 6.2 Swift.swiftinterface file.
This was caused by mistakenly cherry-picking the `#if $AddressOfProperty` conditions in the stdlib into 6.2 without the required compiler change.
The test was crashing due to `swift_unreachable("custom executors not supported in embedded Swift")` line in `swift_task_enqueueImpl`, as the corresponding non-embedded codepath was relying on an unspecialized generic function `_swift_task_enqueueOnExecutor` defined in `Executor.swift`. Unspecialized generics are unavailable in Embedded Swift, and such `@silgen_name` function can't be specialized when used from concurrency runtime code written in C/C++. We can redefine this function for Embedded Swift as using a class-bound existential instead, and re-enable this codepath with a slightly different call that avoids the use of unavailable `swift_getObjectType` function from the non-embedded runtime.
Resolves the following warnings:
```
stdlib/public/SwiftShims/swift/shims/CoreFoundationShims.h:86:1: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
86 | const _swift_shims_NSUInteger
| ^~~~~
stdlib/public/stubs/FoundationHelpers.mm:110:1: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
110 | const _swift_shims_NSUInteger
| ^~~~~
```
This adds `xsmf_control.h` into the STL modulemap on Windows.
Fixes the following compiler error emitted by Clang when trying to use `std::variant` from Swift with C++ interop:
```
...\MSVC\14.42.34433\include\variant:923:25: error: missing '#include <xsmf_control.h>'; '_Non_trivial_move_assign' must be defined before it is used
```
When using the new custom default executors, sometimes we end up
taking a long time to do a task switch. This is happening because
the path the new code takes sometimes results in a concrete pointer
to the default global executor being in the executor tracking
information in `swift_task_switch()`, and if we try to switch to
a `nil` task executor (which _also_ means the default global executor),
we aren’t spotting that and we’re taking the slow path.
Essentially, we want to take the fast path in cases where we switch
from `nil` to the concrete default global executor and vice-versa.
rdar://156701386
It seems that the restriction preventing these from working was
lifted.
The behavioral difference is that in Swift 5 mode, we don't
actually open AnyObject like this, so the old operator could
not be used with class-bound existentials.
I added a trivial test case just to ensure that calls to ===
type check correctly in both language modes.
Fixes rdar://156095800.
Concurrency from the Core project is importing the Darwin platform
overlay, which in turn depends on SwiftCore from the Core project,
breaking the project layering.
Concurrency only needs the Clang module, but Swift does not have a
mechanism to only import a clang module. For now import the
functionality needed from Darwin by importing and wrapping the
associated functions from `<dlfcn.h>` within `CFExecutor.cpp`
Also remove Darwin import from `AsyncStreamBuffer.swift` because it is
not used
Enable `MainActor` in embedded concurrency, add `ExecutorImpl.cpp`
`ExecutorImpl.cpp` should be moved from `SWIFT_RUNTIME_CONCURRENCY_NONEMBEDDED_C_SOURCES` to `SWIFT_RUNTIME_CONCURRENCY_C_SOURCES`. This way we can also include `ExecutorImpl.swift` and use `PlatformExecutorCooperative.swift` in embedded concurrency for WASI.
