When built with output enabled, sometimes a few lines would be
interchanged, depending on the order in which parallel tasks
complete. Simplify the dispatcher logic a bit to ensure we get
the same output ordering every time.
This does not impact the running time of the benchmark.
This changes the implementation for `Collection.difference(from:)` to
use a linear-space complexity variation of the same Myers algorithm. The
new version is similar in execution time to the existing one, but should
alleviate memory pressure when diffing collections where the number of
differences approaches the size of the collection. While the new
algorithm returns a set of changes that is the same size as the previous
version, the specific changes are not guaranteed to be the same.
rdar://155829876
Enabling both of these despite the long runtime so that I can get an
accurate measure of the change with the new diffing implementation.
After #83212 is merged I will disable these large benchmarks again.
Fix warning in benchmark: generic parameter 'C' shadows generic parameter from outer scope with the same name; this is an error in the Swift 6 language mode
The SDK overlays have been provided in the Apple SDKs for many years, and the interface and implementation has diverged in more recent years such that trying to build the Swift version no longer works. Remove all of the dead code.
rdar://151889154
This is needed to unblock nightly toolchains, which are currently failing to build with an assertion:
```
swift-frontend: /home/build-user/build/buildbot_linux/llvm-linux-x86_64/tools/clang/include/clang/AST/TypeNodes.inc:79: TypeInfo clang::ASTContext::getTypeInfoImpl(const Type *) const: Assertion `!T->isDependentType() && "should not see dependent types here"' failed.
```
rdar://150067288
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
