Store test content in a custom metadata section. #880
Conversation
This file contains 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
stmontgomery,
dennisweissmann,
briancroom,
SeanROlszewski 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 |
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
from
4e01f8b to
d07e477
Compare
|
@swift-ci test |
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
2 times, most recently
from
fc30eeb to
7cb5985
Compare
|
@swift-ci test |
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
3 times, most recently
from
1024c92 to
f72f629
Compare
|
@swift-ci test |
2 tasks
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
from
f72f629 to
cfa505c
Compare
|
@swift-ci test |
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
from
cfa505c to
db83b1d
Compare
|
@swift-ci test |
|
There needs to be a warning on that Close with comment button. |
grynspan
added
the
less-c++
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
4 times, most recently
from
d7ffa67 to
a44121e
Compare
|
@swift-ci test |
grynspan
force-pushed
the
jgrynspan/custom-metadata-section
branch
from
8852595 to
55338a7
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
55338a7 to
725a40f
Compare
|
@swift-ci test |
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. 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.)Resolves #764.
See Also
#735
swiftlang/swift#76698
swiftlang/swift#78411
Checklist: