Currently we create an absolute one -- this prevents to use the partial
toolchain before the installation phase (namely for configurations that
run Swift tests on a different device than the builder).
Addresses rdar://160277259
We used to try to use `process_vm_readv()` if `CAP_SYS_PTRACE` is
enabled. This avoided using signal handlers to catch crashes when
we try to read through an invalid pointer, but it complicates the
code and it turns out not to work on some Linux kernels where
the `process_vm_readv()` syscall is unavailable.
rdar://159930644
`swift_coroFrameAlloc` is needed by `_read`/`_modify` accessors
`swift_deallocUninitializedObject` which I believe is needed for failable class initializers
Resolves rdar://157028375
Resolves rdar://157276375
We need the `init?(JobPriority)` constructor to be
`StdlibDeploymentTarget 5.9`
so the compiler will not complain when we reference it
from `ExecutorJob.createTrampoline` when building the standard library
without strict availability.
Addresses rdar://159397287
This fixes modularization errors that arise when importing a C++ header that contains `#include <guiddef.h>`, which might hijack this header from the WinSDK module where it belongs.
This adds CxxStdlib overlay features to `std::wstring` similarly to `std::string`, `std::u16string`, etc.
This lets clients e.g. convert between Swift String and C++ wide string simply by calling an initializer.
rdar://159272493
The interior wrapping in Result<T, U> is a little unfortunate, but is
currently necessary because we end up with extra stack allocations
along the error-handling path in a do..catch that aren't there when
using untyped throws. We can simplify the implementation if we can
eliminate the extraneous stack allocation.
Fixes rdar://134973620.
We were terminating after the first set of jobs; if one of them scheduled
another job, and there were no timers running, we would terminate,
which was wrong.
If a job enqueues another job on the executor, we might never leave
the inner `while` loop in the `run()` method. Fix this by taking
the contents of the run queue and only running those jobs in the
queue at the time we enter the inner loop.
I don't think we actually need this. If you have a non-canonical
(i.e. derived) clock, you can just implement `enqueue` and/or `run`
and call those methods on the clock you're wrapping.
We no longer attempt to convert timestamps from the passed-in `Clock`
in order to allow any clock to work with any executor. Instead,
executors that do not recognise a clock should call the `enqueue`
function on that `Clock`, which lets the `Clock` itself decide how
to proceed.
Additionally, rename `SchedulableExecutor` to `SchedulingExecutor`.
This reverts commit 4a95275bde.
I remove the dependency looking at the modules that StdlibUnittest
directly imports -- but it turns out we import StringProcessing
indirectly as a result of importing Foundation from e.g. the underlying
Apple SDKs.
Addresses rdar://158797152
The body seems to only reinterpret pointer types (`withMemoryRebound`).
Inlining it should not lead to code size gains and has shown to reduce code size.
WASILibc wasn't built for the embedded stdlib in `stdlib/public/Platform/CMakeLists.txt`. New `copy_wasilibc_modulemap_embedded_resource` and `embedded-stdlib-platform-${triple}` targets are added, the latter for `wasm32-unknown-wasip1` only for now. Also added a `wasilibc_functions.swift` test to verify the result.
Resolves https://github.com/swiftlang/swift/issues/83513
rdar://157467412
