[Pitch] Add a filePath property to SourceLocation in Swift Testing

Evolution Pitches
,
1

Swift Testing has a SourceLocation structure that we use to represent the file ID, line, and column of a recorded issue and various other bits and pieces in a test target. We didn't initially include the file path as we thought it would be redundant next to the file ID, but our thinking has changed. I propose adding a filePath property thereto!

Read the full proposal here.

Trying it out

To try this feature out, add a dependency to the main branch of swift-testing to your project:

...
dependencies: [
  ...
  .package(url: "https://github.com/swiftlang/swift-testing.git", branch: "main"),
]

Then, add a target dependency to your test target:

.testTarget(
  ...
  dependencies: [
    ...
    .product(name: "Testing", package: "swift-testing"),
  ]
)

Finally, import Swift Testing using @_spi(Experimental) import Testing.

7 Likes
2

I like this change.

Out of curiosity, would the Swift Testing console output contain a path (instead just the filename) when emitting events?

1 Like
3

No, this change does not affect console output.

4

From looking over the implementation, filePath in the recorded issue is the same as what #filePath would evaluate to at the usage site, correct?

I just want to make sure there's no additional processing done to it (i.e., nothing that would force it to be an absolute path), so that it's always deterministic/independent of build workspace in the JSON ABI as long as the paths are passed as relative paths to the compiler in the first place. (#filePath returns the path verbatim as it's passed to the frontend, IIRC.)

Assuming that's not an issue, +1 to the proposal, I would indeed use this.

5

Correct, filePath here is just #filePath (when we generate it, anyway—you're free to pass other strings to SourceLocation.init().)

1 Like
6

This is helpful for the interop work in [Pitch] Targeted Interoperability between Swift Testing and XCTest. When corelibs XCTest reports an issue, it includes the source file path in the message using #file. To accurately translate Swift Testing issues to XCTest, we'd need this filePath too.

2 Likes
7

No, this change does not affect console output.

I am curious if changing console output is not planned at all or outside of the scope of this particular proposal? As correctly noted in the evolution proposal, tools are much better equipped to handle file paths than Swift file IDs. And tools do consume console outputs. For that reason, I believe the same motivation applies to console output as well.

For the context: the better integration that I am personally looking for is with Vim. Vim’s quickfix lists feature allows jumping between locations that look like paths in the console output (matched by regex).

Thanks,

8

Swift Testing's console output is outside the scope of this proposal.

The direct console output (to stderr) produced by Swift Testing is not machine-readable. Tools should not try to parse it. Instead, they can consume the JSON-based event stream which includes all the same human-readable text as stderr in a machine-readable form.

I don't anticipate us including complete file paths in the default output to stderr, but I could see us doing it when e.g. --verbose is passed to swift test.

1 Like
9

Is there a good guide / reference you know handy about doing this part of the process?

10

I assume you're referring to handling the event stream from Swift Testing? I'd be happy to help you with that but it's beyond the scope of this pitch. I would suggest starting a new thread under the "Swift Testing" forum category and we can discuss there. Thanks!