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
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
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
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
This moves `libcxxshim.modulemap`, `libcxxshim.h` and `libcxxstdlibshim.h` from `*.xctoolchain/usr/lib/swift/macosx/arm64e` to `*.xctoolchain/usr/lib/swift/macosx` to simplify distribution.
rdar://110788977
This fixes the `no such module 'CxxStdlibShim'` error when building CxxStdlib for armv7k.
For watchOS, armv7k is included in `${SWIFT_SDK_${sdk}_MODULE_ARCHITECTURES}` but not in `${SWIFT_SDK_${sdk}_ARCHITECTURES}`.
rdar://108206099
The modulemap and header files target was added to `ALL`, which works
when invoking the build thru the `build-script`, but make some test fail
when doing a manual configuration and later doing
`check-swift-validation` or similar, because the modulemap/header were
not copied into the build directory.
Follow a pattern similar to the one in GlibC (which this file seemed to
be prepared for, since the `libcxxshim_modulemap_target_list` variable
was already there), create a global target for all the modulemap/headers
of each SDK and add that global target as a dependency of sdk-overlay
(which is a dependency of check-swift-validation and others).
