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
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.
