Unfortunately, this was not discovered earlier as swift-ide-test is not
invoking the SIL passes that produce this diagnostic. When creating
Swift spans from C++ spans we have no lifetime dependency information to
propagate as C++ spans are modeled as escapable types. Hence, this PR
introduces a helper function to bypass the lifetime checks triggered by
this discepancy. Hopefully, the new utility will go away as the lifetime
analysis matures on the Swift side and we get standardized way to deal
with unsafe lifetimes.
This fixes a build warning:
```
swift/stdlib/public/Cxx/CxxDictionary.swift:168:9: warning: variable 'iter' was never mutated; consider changing to 'let' constant
```
CxxSpan is trivial, but not immortal.
This initializer is diagnosed with an error after enabling trivial dependence
enforcement. Correct this with an _overrideLifetime call. This could be avoided
if we had a another way to tell the compiler that CxxSpan.__dataUnsafe()
produced a pointer with the same effective lifetime as the CxxSpan.
A first step towards creating safe overloads for C++ APIs using span
(rdar://139074571).
Note that we need to mark span as owned because it the libc++
implementation was mistakenly recognized as owned and might now rely on
span methods like `data` being renamed as `__dataUnsafe`. We will change
it under a new interop version. But for the time being, we want
consistent behavior across stdlib versions.
The PR https://github.com/swiftlang/swift/pull/77857 added windows-specific workaround for https://github.com/swiftlang/swift/issues/77856, that happened after https://github.com/swiftlang/swift/pull/77843. Unfortunately this caused a new issue on windows - https://github.com/swiftlang/swift/issues/78119. It looks like windows is suffering from a similar serialization issue as libstdc++, although its even more complex as the callAsFunction is not only a derived function from a base class, the base class although has a static call operator. In any case, the libstdc++ callAsFunction deserialization fix should align with the static operator () deserialization too, so for now make windows use the same workaround as other platforms to avoid the deserialization crash (77856).
This change was tested on i686 windows too, ensuring that IR verifier crash no longer happens
The iOS/watchOS/tvOS deployment targets for Cxx and CxxStdlib binaries got unintentionally bumped in b87b263.
This reverts the deployment targets to the older versions.
rdar://140823785 / resolves https://github.com/swiftlang/swift/issues/77909
If a Swift module built with library evolution enabled is an overlay of a C++ module, allow referring to the non-resilient C++ symbols from the Swift code.
Overlays are usually built and shipped along with the C/C++ modules, so library evolution is less of a concern there. A developer providing a Swift overlay for a C++ library would expect to be able to refer to the symbols from the C++ library within the overlay.
In certain versions of libstdc++, `std::hash<std::string>` defines `operator()` in a base class. It looks like Swift is not correctly deserializing an inherited `operator()` for inlinable functions. This change sidesteps the issue by moving the call to `callAsFunction`/`operator()` to the C++ shim layer.
rdar://140358388
The change in 269fc941 turned out not to be enough to solve linker errors when using the CxxStdlib overlay with a non-default C++ stdlib.
In addition to `@inlinable`, the Swift functions in the overlay need to be `@_alwaysEmitIntoClient` to prevent Swift from trying to link a program that uses libc++ on Linux against the CxxStdlib binary shipped in the toolchain.
rdar://138838506
This is a requirement for being able to use the CxxStdlib overlay with a C++ standard library which is not the platform default, specifically libc++ on Linux.
The module would get rebuilt from its textual interface (`CxxStdlib.swiftinterface`) by the compiler whenever a custom C++ stdlib is used. Since the mangled names of C++ stdlib symbols differ across implementations (libc++ vs libstdc++), a Swift program that uses these overlay functions would fail to link, unless the definitions of these functions are available.
rdar://138838506
It was already supposed to be enabled, but I forgot to update the CMake when I
renamed the feature from ExtensionImportVisibility to MemberImportVisibility.
However, leave it disabled on the CxxStdlib module since the C++ standard
library's modularization varies a lot by platform, making it difficult to add
the right conditional imports.
This fixes incremental builds of the overlay.
The CxxStdlib overlay re-exports the entire C++ standard library, which has headers that transitively include Clang builtin headers, bringing in the _Builtin_float module.
rdar://140036608
This adds a pair of Swift protocols that represents C++ iterator types conforming to `std::contiguous_iterator_tag` requirements. These are random access iterators that guarantee that the values are stored in consequent memory addresses.
This will be used to optimize usage of C++ containers such as `std::vector` from Swift, for instance, by providing an overload of `withContiguousStorageIfAvailable` for contiguous containers.
rdar://137877849
This adds an automatic conformance for `std::map` and `std::unordered_map` to Swift's `ExpressibleByDictionaryLiteral` protocol.
This makes it possible to pass a dictionary literal as an argument to a function that takes a `std::map` as parameter.
rdar://137126474
Swift's own `Set` conforms to `ExpressibleByArrayLiteral`. This change conforms instantiations of C++ `std::set` to `ExpressibleByArrayLiteral` as well.
This makes it possible to pass an array literal as an argument to a function that takes a `std::set` as parameter.
rdar://137126325
This is a follow-up after the change that enabled Cxx and CxxStdlib overlays on macCatalyst: https://github.com/swiftlang/swift/pull/74994.
The compiler relies on the presence of these shim libraries in the toolchain.
rdar://135275773
This conforms mutable C++ container types, such as `std::vector`, to `MutableCollection` via a new overlay protocol `CxxMutableRandomAccessCollection`.
rdar://134531554
The subscript function from CxxRandomAccessCollection did not perform any bounds-checks.
This means that C++ containers that don't provide the operator[] (or C++ containers used in generic contexts) didn't have bounds-checks.
Fixes rdar://126570011
Mostly this just means adding `Musl` as a module dependency of various
things and making sure that we build things for `swift_static` even
if `SWIFT_BUILD_STATIC_STDLIB` isn't enabled.
There's also a slight difference in the declaration of `memcmp()`;
musl's declaration is more like the one we have on Darwin.
rdar://123508245
Instead of appending characters one-by-one, which resizes the resulting string multiple times, let's reserve the required number of bytes beforehand.
rdar://127423949
