The _StringProcessing module provides a generic, collection-based
`contains` method that performs poorly for ranges and closed ranges.
This addresses the primary issue by providing concrete overloads
for Range and ClosedRange which match the expected performance for
these operations.
This change also fixes an issue with the existing range overlap tests.
The generated `(Closed)Range.overlap` tests are ignoring the "other"
range type when generating ranges for testing, so all overlap tests
are only being run against ranges of the same type. This fixes things
so that heterogeneous testing is included.
Since https://github.com/swiftlang/swift/pull/75608, the performance of `std::string` <=> `Swift.String` conversions improved significantly. To make sure the workload is significant enough for the benchmark results to be noise-free, this bumps the size of Swift strings that are being tested.
`import CxxStdlib` should not be required, since `CxxStdlibPerformance` transitively imports the C++ stdlib, but having the explicit import works around a modularization issue (rdar://128520766).
rdar://136330247
To build benchmarks that use C++ `std::span`, we need to use C++20 standard.
SwiftPM supports `.interoperabilityMode(.Cxx)` build setting starting from version 5.9. In more recent versions, SwiftPM is also able to correctly propagate the C++ standard version (e.g. `-Xcc -std=c++20`) to the Swift compiler invocation, when C++ interop is enabled. The C++ standard version is only propagated if the modern build setting is used. This has caused Linux CI failures in the past.
This change switches the package manifest to use the modern build setting to enable C++ interop.
While the swift compiler in Xcode links against tbd files in the sdk
that contain an armv7k slice, the open source swift toolchain links
against the stdlib dylb that is in the toolchain itself. This means that
we cannot drop support for armv7k support in the stdlib dylib without
losing support for building armv7k when back deploying to older watch
targets. For now, roll back the recent deployment target bump from 9.0
to 6.0 so that we keep armv7k and i386 simulator.
rdar://135560598
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
rdar://115192929
The Apple SDKs have been providing the Darwin overlay since macOS 10.14.4, iOS 12.2, et al. More recently the SDK version has diverged from the Swift version making them incompatible. Stop building the overlay from Swift. Once the SDK overlays aren't being built, the clang overlays need to be built in testing.
%target-swift-emit-pcm doesn't use the sdk, but %target-swift-frontend does, which will cause them to have a mismatch with "builtin headers belong to system modules, and _Builtin_ modules are ignored for cstdlib headers" aka LANGOPT(BuiltinHeadersInSystemModules) aka -fbuiltin-headers-in-system-modules.
rdar://115192929
When the benchmarks are built with SwiftPM, the -std=c++20 flag is passed if the -cxx-interoperability-mode is present. This patch switches from -Xfrontend -enable-experimental-cxx-interop to the required interoperability flag.
Bump the deployment target from macOS 10.13-aligned versions to macOS
13.0-aligned versions. This allows us to stop linking CoreFoundation
in the swift runtime, which was previously required for availability
checking. It also lets us align the deployment target on x86_64 with
arm64, which was 11.0. Finally, it is a prerequisite to being able to
build swift using the macOS 15 beta SDKs.
The C++ interop benchmarks were only running when building with CMake, not with SwiftPM, because of a bug that was only triggering with SwiftPM. That bug seems to be fixed now.
This adds an `import CxxStdlib` statement which fixes compilation. It should be redundant, but it works around a bug that got exposed by an change in explicit modules (rdar://128520766).
This will bring back the performance numbers while the underlying issue is being investigated.
The two benchmarks don't currently build in some configurations. Also
disabled building ReadAccessor whose running had previously been
disabled because it doesn't build anymore.
rdar://128520766
* Revert "Revert count(where:)"
This reverts commit 779ea19a6a.
Now that SE-0220 has been re-accepted, this adds the `count(where:)`
Sequence method to the standard library.
