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
This change introduces a new compilation target platform to the Swift compiler - visionOS.
- Changes to the compiler build infrastrucuture to support building compiler-adjacent artifacts and test suites for the new target.
- Addition of the new platform kind definition.
- Support for the new platform in language constructs such as compile-time availability annotations or runtime OS version queries.
- Utilities to read out Darwin platform SDK info containing platform mapping data.
- Utilities to support re-mapping availability annotations from iOS to visionOS (e.g. 'updateIntroducedPlatformForFallback', 'updateDeprecatedPlatformForFallback', 'updateObsoletedPlatformForFallback').
- Additional tests exercising platform-specific availability handling and availability re-mapping fallback code-path.
- Changes to existing test suite to accomodate the new platform.
Keep the `@_borrowed` attributes on UnsafeCxx[Mutable]Iterator — it appears to be required with the new pointer types. (That’ll need some separate investigation.)
rdar://125146418
[stdlib] Pull back @_aeic on pointer → integer conversions
[stdlib] UnsafeMutablePointer.allocate: Fix thinko
[stdlib] Disable support for noncopyable pointees on some pointer operations
We have to temporarily pull back support for noncopyable pointees for UnsafeMutablePointer.initialize(to:), .moveInitialize, .moveUpdate, as the builtins they’re calling are no longer accepting such types.
These will return following a builtin audit.
[stdlib] Remove workarounds for certain builtins not supporting noncopyable use
https://github.com/apple/swift/pull/71733 fixed this!
[stdlib] Update FIXME
[stdlib] UnsafePointer: Update Swift version numbers
[stdlib] UnsafePointer: Actually hide legacy ABI
[stdlib] Remove workaround for U[M]BP.withMemoryRebound
This removes a special case in the compiler for these types, and applies the `import_owned` attribute to all instantiations of `vector` and `basic_string` via API Notes.
C++ `operator bool()` is currently imported into Swift as `__convertToBool()`, which shouldn't be used by clients directly.
This adds a new protocol into the C++ stdlib overlay: `CxxConvertibleToBool`, along with an intitializer for `Swift.Bool` taking an instance of `CxxConvertibleToBool`.
rdar://115074954
`COMMAND` for `add_custom_target` are "always considered out of date"
and executed everytime. Because of that, targets depends on that were
alway marked "dirty". Use `add_custom_command_target` instead.
