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
We need the C++ interop support library to make the build work, as
the Runtime module uses C++ interop.
(Also, we should build it, because some user programs might want to
use C++ interop.)
rdar://147201087
This fixes a deserialization failure in the compiler that occurred while loading the CxxStdlib overlay module:
```
Cross-reference to module 'Swift'
... Optional
... some
... with type <τ_0_0 where τ_0_0 : ~Copyable, τ_0_0 : ~Escapable> (Optional<τ_0_0>.Type) -> (τ_0_0) -> Optional<τ_0_0>
```
This was happening because the overlays were built against a different version of the Swift stdlib than is being used. The compiler is able to rebuild the Cxx and CxxStdlib modules from their textual interfaces. Let's use that feature unconditionally in production toolchains to avoid this kind of binary incompatibilities.
rdar://150416863
We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
This adds conformances for C++ string types (`std::string`, `std::u16string`, `std::u32string`) to `Swift.ExpressibleByStringInterpolation`.
These conformances currently implicitly use `DefaultStringInterpolation`. In the future we can provide more performant interpolation mechanisms for C++ strings specifically that avoid the extra conversion between Swift String and C++ string types.
rdar://147249169
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
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.
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.
`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.
This adds an `std.apinotes` file that is installed into `lib/swift/apinotes` along with existing Darwin apinotes. This new file is installed on all platforms. It replaces a few special cases in the compiler for `cmath` and `cstring` functions.
This does not require the upcoming APINotes support for namespaces, however, this does require https://github.com/apple/llvm-project/pull/7309.
rdar://107572302
This adds a new Swift overload for `append` that takes another `std::string` as a parameter.
The original C++ overload for `append` is not exposed into Swift because it returns a mutable reference `string&`.
rdar://107018724
The CxxStdlib module now relies on the libcxxshim modulemap, so we
need to make sure that the modulemap is copied into the correct location before CxxStdlib is built.
rdar://108007693
This fixes a build failure that started occurring on CentOS after https://github.com/apple/swift/pull/65057:
```
error: cannot find 'strlen' in scope
```
rdar://107987115
Currently without an initializer for the unsafe char pointer type swiftc
hits an assert around not being able to handle conversions of unsafe
pointers with Any type. This patch adds the ability to convert to a
std::string.
This is to address issue https://github.com/apple/swift/issues/61218
Cxx & CxxStdlib modules are Swift-only, they do not require invoking clang directly.
When building with `SWIFT_INCLUDE_TOOLS=NO`, Clang is not available as a CMake target (see `swift_common_standalone_build_config`).
rdar://107780733
