Within Process, the launchPath here is equivalent to executableURL.path. Just before launching the process, we call .withCString(encodedAs: UTF16.self) to convert the invocation to UTF-16. However, now that URL is re-cored on swift-foundation's URL, Windows paths are represented following RFC8089 which contains a leading / before a drive letter. The various file system representation functions remove this preceding slash before calling to an SDK API, however Process did not do this resulting in a path such as /C:/Users/jmschonfeld/foo.exe being passed to CreateProcessW which failed to find the file. This standardizes the path to its file system representation before it is combined with the various arguments and converted to UTF-16 later.
This fixes a failure that occurred during a windows toolchain build where SwiftPM (using the new Foundation) was unable to invoke swiftc.exe due to this issue.
Within
Process, thelaunchPathhere is equivalent toexecutableURL.path. Just before launching the process, we call.withCString(encodedAs: UTF16.self)to convert the invocation to UTF-16. However, now thatURLis re-cored on swift-foundation'sURL, Windows paths are represented following RFC8089 which contains a leading/before a drive letter. The various file system representation functions remove this preceding slash before calling to an SDK API, howeverProcessdid not do this resulting in a path such as/C:/Users/jmschonfeld/foo.exebeing passed toCreateProcessWwhich failed to find the file. This standardizes the path to its file system representation before it is combined with the various arguments and converted to UTF-16 later.This fixes a failure that occurred during a windows toolchain build where SwiftPM (using the new Foundation) was unable to invoke
swiftc.exedue to this issue.