-
Notifications
You must be signed in to change notification settings - Fork 125
Add a type
argument to the ABI accessor function signature.
#939
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
Conversation
We access the test content record section directly instead of using some (non-existent) type-safe Swift API. On some platforms (Darwin in particular), it is possible for two copies of the testing library to be loaded at runtime, and for them to have incompatible definitions of types like `Test`. That means one library's `@Test` macro could produce a test content record that is then read by the other library's discovery logic, resulting in a stack smash or worse. We can resolve this issue by adding a `type` argument to the accessor function we define for test content records; the body of the accessor can then compare the value of this argument against the expected Swift type of its result and, if they don't match, bail early. The new argument is defined as a pointer _to_ a Swift type rather than as a Swift type directly because `@convention(c)` functions cannot directly reference Swift types. The value of the new argument can be safely ignored if the type of the test content record's value is and always has been `@frozen`.
78d9fee
to
d87c257
Compare
value at `type` does not match the test content record's expected type, the | ||
accessor function must return `false` and must not modify `outValue`. | ||
|
||
<!-- TODO: discuss this argument's value in Embedded Swift (no metatypes) --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Embedded Swift, we can just say "the value of this argument is unspecified."
@swift-ci test |
@swift-ci test |
@swift-ci test Windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Is it important that the mechanism to distinguish records be the type of outValue
, in particular? Or could it be something else? Just curious what led to that choice
The implementation actually does use a different type for If/when we make the |
We access the test content record section directly instead of using some (non-existent) type-safe Swift API. On some platforms (Darwin in particular), it is possible for two copies of the testing library to be loaded at runtime, and for them to have incompatible definitions of types like
Test
. That means one library's@Test
macro could produce a test content record that is then read by the other library's discovery logic, resulting in a stack smash or worse.We can resolve this issue by adding a
type
argument to the accessor function we define for test content records; the body of the accessor can then compare the value of this argument against the expected Swift type of its result and, if they don't match, bail early.The new argument is defined as a pointer to a Swift type rather than as a Swift type directly because
@convention(c)
functions cannot directly reference Swift types. The value of the new argument can be safely ignored if the type of the test content record's value is and always has been@frozen
.Checklist: