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:
parent
ecd1b34a18
commit
7fcfdea68c
@ -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)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user