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
libc++ provides a 2-parameter constructor of `std::string`, so we can apply the logic under `#if os(Windows)` on Apple platforms too.
This avoids deserialization issues when building some complex projects that are still under investigation.
rdar://145939013
At the same time, drop that dependency in the new build system, so that
we don't add an additional linkage for Darwin platforms compared to what
we are doing in the current build system.
Addresses rdar://158314427
At the same time, drop that dependency in the new build system, so that
we don't add an additional linkage for Darwin platforms compared to what
we are doing in the current build system.
Addresses rdar://158313871
This adjusts the flag to be `clang-cl` compatible rather than `clang`
compatible on Windows. `-Isystem` would cause the include search path to
be ignored, whereas `-imsvc` allows us to honour the path. This is
important when using the external dispatch.
Since #64187 we are not importing automatically StringProcessing when
building the stdlib -- this is especially important for StdlibUnittest,
since it needs to run on older OSes.
Addresses rdar://157622116
Carefully overhaul our word breaking implementation to follow the recommendations of Unicode Annex #29. Start exposing the core primitives (as well as `String`-level interfaces), so that folks can prototype proper API for these concepts.
- Fix `_wordIndex(after:)` to always advance forward. It now requires its input index to be on a word boundary. Remove the `@_spi` attribute, exposing it as a (hidden, but) public entry point.
- The old SPIs `_wordIndex(before:)` and `_nearestWordIndex(atOrBelow:)` were irredemably broken; follow the Unicode recommendation for implementing random-access text segmentation and replace them both with a new public `_wordIndex(somewhereAtOrBefore:)` entry pont.
- Expose handcrafted low-level state machines for detecting word boundaries (_WordRecognizer`, `_RandomAccessWordRecognizer`), following the design of `_CharacterRecognizer`.
- Add tests to reliably validate that the two state machine flavors always produce consistent results.
rdar://155482680
This restores the `LLVM_NODISCARD` macro from the branch point
(retaining the header inclusion changes). This is required to build
SwiftRemoteMirror without injecting another LLVM build.
Previously, we skipped checking the return type of a function for safety
as we expected to warn at the use of the returned value:
let x = returnsUnsafe()
usesUnsafe(x) // warn here
Unfortunately, this resulted in missing some unsafe constructs that can
introduce memory safety issues when the use of the return value had a
different shape resulting in false negatives for cases like:
return returnsUnsafe()
or
usesUnsafe(returnsUnsafe())
This PR changes the analysis to always take return types of function
calls into account.
rdar://157237301
