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
