This PR provides a compile-time conditional, SWT_NO_LAZY_ATTACHMENTS, which when set causes Swift Testing's new experimental attachments feature to always eagerly encode/serialize/whatever attachments even if they're copyable and sendable.
We anticipate using this functionality in Embedded Swift in the future. Note that support for Embedded Swift is not (yet!) a planned feature.
"Why not make Attachment generic?"
I've got a separate branch that tries to do this. It has a significantly more complex implementation and is brittle because we need to type-erase the attachable value in order to pass it into the event-handling machinery (which entails having a bunch of special-casing since any Test.Attachable does not conform to Test.Attachable.) Attachment is already meant to represent a type-erased Attachable value.
Checklist:
[x] Code and documentation should follow the style of the Style Guide.
[x] If public symbols are renamed or modified, DocC references should be updated.
grynspan
commented
2 weeks ago
This PR provides a compile-time conditional,
SWT_NO_LAZY_ATTACHMENTS, which when set causes Swift Testing's new experimental attachments feature to always eagerly encode/serialize/whatever attachments even if they're copyable and sendable.We anticipate using this functionality in Embedded Swift in the future. Note that support for Embedded Swift is not (yet!) a planned feature.
"Why not make Attachment generic?"
I've got a separate branch that tries to do this. It has a significantly more complex implementation and is brittle because we need to type-erase the attachable value in order to pass it into the event-handling machinery (which entails having a bunch of special-casing since
any Test.Attachabledoes not conform toTest.Attachable.)Attachmentis already meant to represent a type-erasedAttachablevalue.Checklist: