You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Avoid runtime collisions when multiple copies of the testing library are loaded (#1471)
This PR avoids runtime collisions when multiple copies of the testing
library are loaded into a given process by introducing the ability to
customize the module ABI name of each copy.
### Motivation:
In some usage scenarios there can be two or more copies of the testing
library loaded into a runner process. When this happens on platforms
such as Darwin which use the Objective-C runtime, this can cause
duplicate class definition warnings to be logged to the console because
(non-generic) class and actor types are implemented in the Objective-C
runtime as classes. For a recent example where this occurred and was
worked around, see #1444. Although we have not seen practical reports of
this, a similar problem could arise at build/link time on some platforms
due to exported symbols from the testing library having multiple
definitions.
Resolves rdar://148912491
### Modifications:
This PR specifies a unique module ABI name for each public library
module by passing `-module-abi-name <name>` to the Swift compiler. It
does this differently depending on the build context:
- When building as a Swift package, this PR appends a hardcoded suffix
(`_package`) to the name of each module to form its ABI name. It does
this by default for package builds because package copies of the testing
library are virtually always loaded by runner processes which also load
a prebuilt copy of the testing library, meaning that a package copy is
most often considered a "secondary" copy which needs to avoid runtime
conflicts with a primary copy.
- When building via CMake, this PR adds the _ability_ to define a custom
ABI name suffix, and this allows the client performing the build to
control the ABI name. In particular, this allows a build intended for
inclusion in an official Swift toolchain to specify a suffix, but allows
custom CMake builds to remain unsuffixed.
### Checklist:
- [x] Code and documentation should follow the style of the [Style
Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md).
- [x] If public symbols are renamed or modified, DocC references should
be updated.
0 commit comments