Package plugins don't work on Windows if the PATH environment variable isn't accessed with the right case

[jakepetroules]

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?

• Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps with either of command-line SwiftPM commands, swift build, swift test, swift package etc.

Description

Builds of packages using package plugins may fail on Windows with the following error:

error: plugin process ended by an uncaught signal: 309 <command: C:\foo\.build\plugins\cache\myplugin.exe>, <output:
>

309 translates to 0x135, which maps to 0xc0000135 aka STATUS_DLL_NOT_FOUND.

I haven't tested, but looking at the code the cause seems obvious:

#if os(Windows)
        let pluginLibraryPath = self.toolchain.swiftPMLibrariesLocation.pluginLibraryPath.pathString
        var env = ProcessInfo.processInfo.environment
        if let Path = env["Path"] {
            env["Path"] = "\(pluginLibraryPath);\(Path)"
        } else {
            env["Path"] = pluginLibraryPath
        }
        process.environment = env
#endif

Environment variable names are case-insensitive. On a real Windows host, it tends to be spelled "Path". In a Windows Container (Docker), it tends to be spelled "PATH".

Our code will end up clearing out the other paths from the PATH environment variable in the else case because Path != PATH.

We need to access the path here in a case-insensitive manner -- there is an existing Environment abstraction which can be used for this.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

Swift Package Manager version/commit hash

No response

Swift & OS version (output of swift --version ; uname -a)

No response