feat(xcresult): resolve declarations from swift test --xunit-output

[dfrankland]

Stacked on #1179, which is stacked on #1178. Review those first; this is one commit on top.

Why

swift test --xunit-output writes no file path for any test, and on Linux there is no .xcresult to fall back to — so today a Swift test run there can never be attributed to a file. The declaration index needs nothing from Xcode, so it can answer this too.

That makes the addressable surface here arguably larger than the xcresult case: sourcekit-lsp ships with the Swift toolchain on Linux, while xcresulttool is Xcode-only.

The xunit XML carries more than it appears

classname is the target followed by the dot-qualified suite path, collapsing to the bare target only for a top-level @Test func:

classname="MyCLITests"                  name="helloworld()"
classname="MyCLITests.AlphaSuite"       name="shared()"
classname="MyCLITests.AlphaSuite.Inner" name="deep()"
classname="MyCLITests.BetaSuite"        name="shared()"
classname="MyCLITests.ParamSuite"       name="squares(n:)"

Note the two shared() cases are distinguishable, and a nested suite is fully qualified.

Why the existing machinery fits almost unchanged

needed	already there
innermost type from the path	from_node_identifier does this for Suite/Inner/case(); only the separator differs
top-level test with no suite	lookup already falls back to TestKey { suite: None, case }
strip (), keep argument labels	normalized_case, with an existing parameterized_keeps_its_labels case
break cross-module collisions	the first component is the target — the tie-break from #1178 carries over free

Parameterised tests need no special handling: swift-testing emits one entry per function, not per argument set, and that single entry is the declaration site we want.

Fixture

A real SwiftPM package plus the XML it actually produced. Its two suites both declare shared() in different files, so a regression that ignored the suite component would make one borrow the other's — reverting that component fails both tests rather than neither. tests/fixture-src/swift-test-xunit/README.md has the shape-by-shape table and the regeneration steps.

Scope

This is the resolver only. Nothing reads a JUnit file or writes a file attribute back yet, and no flag is wired up. Landing the plumbing is the next PR in the stack.

XCTest works too, and needs --parallel

A single swift test run writes two files, which is easy to miss:

file	holds
<name>-swift-testing.xml	swift-testing (@Test, @Suite)
<name>	XCTest (XCTestCase subclasses)

XCTest's form is the same Module.Type plus method, minus the ():

classname="MyCLITests.LegacyXCTests"  name="testOldStyle"

so the same parse resolves it with no special handling — an_xctest_case_resolves_to_the_class_that_declares_it proves it against the fixture package.

The catch: that second file is only written when --parallel is passed. Without it the XCTest cases still run — the console reports -[MyCLITests.LegacyXCTests testOldStyle] passed — but nothing is emitted for them, so a project omitting --parallel silently uploads only its swift-testing results. Both files it actually produced are checked in as fixtures.

Parity with the xcresult input

Both inputs feed one TestLocationIndex, and nothing checked they agree — they were tested against different fixture packages. Three layers now:

test	asserts
..._key_alike	the same test keys identically from either input
..._name_the_same_target	the collision tie-break reads the target from nodeIdentifierURL on one side and classname on the other, and only works if they agree
parity::both_inputs_resolve_every_test_to_the_same_file	one package captured both ways — swift test --xunit-output and xcodebuild into an .xcresult — with the full set of (test, file) pairs identical

It found an identity divergence

The two inputs disagree on how they name a Swift XCTest method:

xcodebuild                  testOldStyle()
swift test --xunit-output   testOldStyle

They resolve to the same file (keying normalises the parens away), but name feeds gen_info_id_base — so the same test arriving through the two inputs does not land on one identity. This is upstream of this crate and is not worked around here, only pinned by the_two_inputs_spell_an_xctest_method_differently so it cannot change unnoticed. Worth deciding on before any repository is told to switch input formats.

Also corrected while here: the real xcresult identifier for a Swift XCTest method is testOldStyle() with parens, where Objective-C reports none. Both shapes are covered now rather than the one I had assumed.

🤖 Generated with Claude Code