Skip to content

Translate Discovery.cpp to Swift #764

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
grynspan opened this issue Oct 15, 2024 · 0 comments · Fixed by #902
Closed

Translate Discovery.cpp to Swift #764

grynspan opened this issue Oct 15, 2024 · 0 comments · Fixed by #902
Assignees
Labels
enhancement New feature or request

Comments

@grynspan
Copy link
Contributor

We should try to translate as much of Discovery.cpp to Swift as we can once we have proper test metadata emission (per #745.) We can't do it now because we're directly touching the type metadata machinery and end up deadlocking on Darwin (and probably other platforms, I haven't checked recently.)

@grynspan grynspan added the enhancement New feature or request label Oct 15, 2024
@grynspan grynspan self-assigned this Oct 15, 2024
grynspan added a commit that referenced this issue Mar 11, 2025
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++.

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_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](https://github.com/swiftlang/swift-testing/blob/main/Documentation/ABI/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:

- [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
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant