We need to only generate references to `_swift_exceptionPersonality`
if we're building for a new enough runtime. The previous code was
good on Darwin, but would have resulted in build problems on Linux.
rdar://120952971
The other new runtime functions appear to have a leading underscore.
It makes sense in this case because we don't expect anything to call
this directly (other than the unwinder).
rdar://120952971
The exception handling tests should check for the new personality, and
the ABI check needs to know about the new entry point in the runtime.
rdar://120952971
Now that we keep many more functions on unoptimized builds, many tests
need to be changed to either:
- Account for function that wasn't being emitted before to being emitted
now.
- Account for functions that previously were being emitted lazily to
being emitted eagerly now.
Windows logic for determining address-only type layout for a C++ type is now unified with other platforms.
However, this means that on Windows, a C++ type with a custom destructor, but a default copy constructor
is now loadable, even though it's non-trivial. Since Swift does not support such type operations at the
moment (it can't be yet destroyed), mark such type as unavailable in Swift instead, when building for
the Windows target.
This fixes the Windows miscompilation related to such types when they were passed indirectly to C++
functions even though they're actually passed directly.
