Make sure the parts you vend compose

[dabrahams]

Description

With XCTest it’s possible to write new, more elaborate kinds of “assertions” using the primitive ones supplied by the framework. I worry that the focus on macros may make it hard to do the same thing well with this framework; in particular to get the issue reported on the right line. I suggest you take a look at https://github.com/loftware/StandardLibraryProtocolChecks and, as though you were an end user, build the same facility as a test case to show that your framework composes easily. Pay attention to the user experience when things fail to make sure you’re implementing the same thing.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

swift-testing version/commit hash

No response

Swift & OS version (output of swift --version && uname -a)

No response

[grynspan]

Thanks for filing! The #expect() and #require() macros allow you to pass an instance of SourceLocation that represents the file and line information for any resulting issue, so it should be straightforward enough to compose higher-order expectation functions that correctly attribute failures. For example:

func expectPositive(_ n: Int, comment: @autoclosure () -> Comment? = nil, fileID: String = #fileID, line: Int = #line, column: Int = #column) {
  #expect(n > 0, comment(), sourceLocation: SourceLocation(fileID: fileID, line: line, column: column))
}

(Note I've omitted #filePath for brevity in the example above because it's a temporary affordance used by XCTestScaffold and we don't plan to keep it around forever. It is straightforward to include it if needed.)

If I've misinterpreted the issue you're reporting here, please feel free to reopen with additional information to clarify.