fix(tests): read fixtures via contentsOfFile:, not String(contentsOf:)

String(contentsOf: url, encoding:) itself was the failure, independent
of how url was obtained -- a bare `for url in urls` with no sort at
all reproduces the same NSURL/URL error on this toolchain. This is a
documented swift-corelibs-foundation issue (SR-7620): String(contentsOf:)
has inconsistent NSURL/URL bridging on Linux.

contentsOfFile: takes a String path instead of a URL, so it has no
exposure to that bridging ambiguity at all.

Verified via a full clean macOS build and the specific test passing,
plus swiftformat/swiftlint --strict clean; the Linux relay confirms
or refutes the actual claim on the next push.
This commit is contained in:
Mihaela Mihaljevic 2026-07-18 23:54:27 +02:00
parent ecd1b34a18
commit 7fcfdea68c

View File

@ -31,7 +31,13 @@ struct TaggedNodeCorpusRoundTripTests {
let order = names.indices.sorted { names[$0] < names[$1] }
for index in order {
let url = urls[index]
let source = try String(contentsOf: url, encoding: .utf8)
// `String(contentsOf: url, encoding:)` itself hit the same NSURL/URL confusion on
// this toolchain regardless of how `url` was obtained (a bare `for url in urls` with
// no sort at all reproduces it too). `contentsOfFile:` takes a `String` path -- a
// type this toolchain's Foundation does not have two conflicting URL/NSURL overloads
// for -- sidestepping the ambiguity at its actual point of failure instead of
// upstream of it.
let source = try String(contentsOfFile: url.path, encoding: .utf8)
let parsed: PureYAML.Tagged.Node
do {
parsed = try PureYAML.parseTagged(source)