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.
LLVM ought to be able to do this transformation for us, but it currently fails to do so. We can code around it easily enough. https://github.com/swiftlang/swift/pull/83172 has a better long-term fix.
`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.
Most of linkers pull object files from static archives only if any
symbol from that object file is referenced, even if the object contains
a ctor code. `Setup.cpp` didn't have any symbols referenced from
other code, so it was not linked in when the concurrency runtime was
linked in statically. This commit moves the ctor code to `Task.cpp`
to ensure that it is always linked in.
