Fix incorrect implementation-only import for CMake build #553
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stmontgomery
added
bug
stmontgomery
requested review from
grynspan,
dennisweissmann,
briancroom,
SeanROlszewski and
suzannaratcliff
as code owners
|
@swift-ci please test |
briancroom
approved these changes
Jul 19, 2024
2 tasks
stmontgomery
added a commit
that referenced
this pull request
Jul 19, 2024
…KE' (#554) This removes the `SWT_BUILDING_WITH_CMAKE` compilation condition, and the `@_implementationOnly import _TestingInternals` declarations it guards. ### Motivation: When support for building via CMake was first added (in #387), many source files in the `Testing` target were modified to avoid using `private`- or `internal`-level imports of the `_TestingInternals` module and instead use the older `@_implementationOnly import` style when building via CMake. As a result, many files have: ```swift #if SWT_BUILDING_WITH_CMAKE @_implementationOnly import _TestingInternals #else private import _TestingInternals #endif ``` This has proven to be a maintenance problem for us, because as new files are added over time, it's not immediately obvious that they need to use this pattern for importing this module—leading to warnings when building with CMake such as the one fixed by #553. I wasn't aware of the reasoning behind the above change at the time, but I investigated it recently and here's what I concluded: Early on, the changes in #387 did _not_ enable Library Evolution (LE) for the `Testing` module, meaning it was still a non-resilient module. [SE-0409](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0409-access-level-on-imports.md) states that all dependencies of non-resilient modules must be loaded by clients, so it would make sense that under those conditions, the build of a client who imports `Testing` would fail because clients do not have visibility to the `_TestingInternals` module. However, in a later PR commit LE was enabled, but nobody realized that those `import` code changes were no longer necessary and could be reverted. I was able to reproduce this and confirm the theory: I added an example client target in the CMake build, then disabled LE in the `Testing` module, and attempted to build the client. It failed with the expected missing module error. Then, re-enabling LE and rebuilding everything, the error went away. Hopefully this is sufficient proof that reverting this is safe, but I'll check with the main contributor of that PR to check and see if there were any other issues before landing. But overall, the goal here is to simplify these imports to reduce maintenance burden and fully embrace SE-0409. ### 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This resolves a warning seen when building the project with CMake, since that style currently still requires
@_implementationOnly importinstead ofprivate importor other access levels.Checklist: