Store test content in a custom metadata section. #880
Merged
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
grynspan
added
enhancement
grynspan
requested review from
SeanROlszewski,
briancroom,
dennisweissmann,
stmontgomery and
suzannaratcliff
as code owners
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
from
e98f3bc to
bb2526a
Compare
compnerd
reviewed
Jan 3, 2025
|
@swift-ci test |
compnerd
reviewed
Jan 6, 2025
|
@swift-ci test |
|
@swift-ci test Linux |
|
@swift-ci test Windows |
1 similar comment
|
@swift-ci test Windows |
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
2 times, most recently
from
fe3dbab to
713b032
Compare
|
@swift-ci test |
|
@swift-ci test macOS |
|
@swift-ci test |
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
2 times, most recently
from
950c904 to
54a7db9
Compare
This PR uses the experimental symbol linkage margers feature in the Swift compiler to emit metadata about tests (and exit tests) into a dedicated section of the test executable being built. At runtime, we discover that section and read out the tests from it. This has several benefits over our current model, which involves walking Swift's type metadata table looking for types that conform to a protocol: 1. We don't need to define that protocol as public API in Swift Testing, 1. We don't need to emit type metadata (much larger than what we really need) for every test function, 1. We don't need to duplicate a large chunk of the Swift ABI sources in order to walk the type metadata table correctly, and 1. Almost all the new code is written in Swift, whereas the code it is intended to replace could not be fully represented in Swift and needed to be written in C++. The change also opens up the possibility of supporting generic types in the future because we can emit metadata without needing to emit a nested type (which is not always valid in a generic context.) That's a "future direction" and not covered by this PR specifically. I've defined a layout for entries in the new `swift5_tests` section that should be flexible enough for us in the short-to-medium term and which lets us define additional arbitrary test content record types. The layout of this section is covered in depth in the new [TestContent.md](Documentation/ABI/TestContent.md) article. This functionality is only available if a test target enables the experimental `"SymbolLinkageMarkers"` feature. We continue to emit protocol-conforming types for now—that code will be removed if and when the experimental feature is properly supported (modulo us adopting relevant changes to the feature's API.) #735 swiftlang/swift#76698 swiftlang/swift#78411
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
from
54a7db9 to
abc1825
Compare
|
@swift-ci test |
grynspan
commented
Mar 11, 2025
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test |
|
@swift-ci test macOS |
…ivate" This reverts commit 003f09f.
|
@swift-ci test |
|
@swift-ci test Linux |
|
@swift-ci test macOS |
|
@swift-ci test Windows |
|
@swift-ci test macOS |
stmontgomery
approved these changes
Mar 11, 2025
2 tasks
grynspan
added a commit
that referenced
this pull request
Mar 12, 2025
…ction. (#1015) Looks like #880 and/or #1010 caused a regression: the compiler appears to be dead-code-stripping the classes we emit to contain test content records. This PR changes the design back to using a protocol so that the members we need are always covered by `@_alwaysEmitConformanceMetadata`. This makes `_TestDiscovery` a little harder to use with legacy lookup, but it's all experimental and eventually going to be removed anyway. Resolves rdar://146809312. ### 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.
2 tasks
stmontgomery
added a commit
that referenced
this pull request
Mar 25, 2025
…ame and enhance a related unit test (#1038) A small enhancement to the `@Test` and `@Suite` macro expansion changes made in #880: qualify the `@__testing(warning:)` usage with the module name. I also took the opportunity to enhance a unit test related to `@__testing(semantics:)`. It already correctly checks the attribute module name if present, and this test simply validates that. ### 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 PR uses the experimental symbol linkage margers feature in the Swift compiler to emit metadata about tests (and exit tests) into a dedicated section of the test executable being built. At runtime, we discover that section and read out the tests from it.
This has several benefits over our current model, which involves walking Swift's type metadata table looking for types that conform to a protocol:
This change will be necessary to support Embedded Swift because there is no type metadata section emitted for embedded targets.
The change also opens up the possibility of supporting generic types in the future because we can emit metadata without needing to emit a nested type (which is not always valid in a generic context.) That's a "future direction" and not covered by this PR specifically.
I've defined a layout for entries in the new
swift5_testssection that should be flexible enough for us in the short-to-medium term and which lets us define additional arbitrary test content record types. The layout of this section is covered in depth in the new TestContent.md article.This functionality is only available if a test target enables the experimental
"SymbolLinkageMarkers"feature and only if Swift Testing is used as a package (not as a toolchain component.) We continue to emit protocol-conforming types for now—that code will be removed if and when the experimental feature is properly supported (modulo us adopting relevant changes to the feature's API.)See Also
#735
#764
swiftlang/swift#76698
swiftlang/swift#78411
Checklist: