Explanationion: Function pointer types wee always considered fragile in C++ mode,
this manifested as a regression when interfacing with glibc.
Issues: rdar://159184118
Original PRs: #84040
Risk: Low, this only removes a spurious error for library evolution.
Testing: Added a compiler test.
Reviewers: @egorzhdan
This fixes sudden compiler errors that are emitted when trying to use CoreText.framework with C++ interop enabled.
When Swift is trying to rebuild a dependency module from its textual interface, it should not complain on usages of C enums in public Swift APIs.
This still leaves the resilience safety guardrail enabled for C++ scoped enums.
rdar://143215914
This is a follow-up to 8859b629.
This resolves compiler errors when trying to rebuild System.swiftmodule from its textual interface with Xcode 16.1.
rdar://140203932
rdar://141124318
When compiling with C++ interop enabled, we enable extra safety checks to prevent library authors from accidentally exposing ABI-fragile C++ symbols in resilient Swift interfaces.
The heuristic we use is overly strict, and it prevents the compiler from being able to typecheck various modules from their interfaces when C++ interop is enabled. Darwin and System are two of such modules.
The underlying challenge is that there isn't a good distinction between C structs and C++ structs: whenever parsing a header file in C++ language mode, Clang assumes that every struct is a C++ struct.
This relaxes the heuristic to allow exposing C-like structs in resilient interfaces.
rdar://140203932
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Changing the members of these structs are still API and ABI breaking
changes but they are not as fragile as C++ classes where adding/removing
virtual functions or doing other changes can also result in breaking the
ABI.
rdar://119319825
Currently, C++ types cannot appear in resilient interfaces. There are
some cases where this is overly restrictive. We plan to improve the
logic to detect what types should not appear on resilient moduel
boundaries. In the meantime, this PR introduces a flag to disable these
errors. Users relying on this flag are on their own, this should only be
a temporary workaround until we land further improvements to this
diagnostic.
rdar://137457118
