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