Improve finding executable on Windows

[stevapple]

There're three main parts of the patch:

• Automatically add .exe suffix based on Windows' rule when finding executables;
• Add default Windows search paths: System32, System and Windows;
• Fix unexpected failure when dealing with empty path strings.

[stevapple]

Anyone to push forward this pull request?

[abertelrud]

Anyone to push forward this pull request?

@compnerd Would you be able to take a second look here? A lot of the swift-tools-support-core contributors don't have much Windows experience. Thanks!

[tomerd]

@swift-ci please test

[tomerd]

@compnerd could you review this one please

[compnerd]

The previously mentioned items are still a concern, I think that this was just rebased.

[stevapple]

I've changed the logic a little bit.

If you search for clang, it will now first look for exactly a clang in to search paths. If nothing was found, then search for clang.exe instead.

[stevapple]

ProcessTests are still failing either because they’re not tailored for Windows, or because supporting functions (like withCustomEnv) are broken. I’d like to address them in another PR.

[tomerd]

@stevapple @compnerd we now have swift-system integrated into the main branch of TSC and can start making use of it / reduce code to help support windows paths etc better

[stevapple]

@tomerd I believe this PR is totally independent of the System integration work, and provides the correct behavior on Windows.

It is only blocked by review:(

[tomerd]

@compnerd to review

@stevapple aren't there APIs in SwiftSystem that can help reduce boilerplate code here, for example the isPath computation should ideally be something that SystemSystem provides?

[stevapple]

@stevapple aren't there APIs in SwiftSystem that can help reduce boilerplate code here, for example the isPath computation should ideally be something that SystemSystem provides?

If we want to reimplement this check in FilePath, then it should look like this:

if let _ = FilePath.Component(value) {
  // additional logic
}

It's somewhat clearer, but shouldn't a blocking issue here. As I've mentioned many times before, this PR is a bug fix, while the FilePath integration is more of a kind of improvement. They should have different priorities, and actually have no dependency on each other.

[compnerd]

Could you please add more context on the motivation behind this change?

[tomerd]

@stevapple @compnerd one thing that is not clear to me about this PR is why we are not leaning more heavily on SwiftSystem and rolling our own path utilities. aware this PR started before the integration with SwiftSystem was put in place, but now that we have it why add additional debt?

cc @milseman

[stevapple]

I wish we could, but sadly no one has reviewed #219 so far.

It is ready now, I would expect someone to give me some feedback:)

[stevapple]

aware this PR started before the integration with SwiftSystem was put in place, but now that we have it why add additional debt?

This PR is more of some bug-fixes, and most of these points still need to be taken extra care of even with System integration at this time. So I would like to land this first, and then replace part of it along with the other System stuffs.

[stevapple]

I recently discovered a new bug where Swift Driver and SwiftPM fail to locate themselves. There’re a bunch of bugs related to unaligned executable searching logic with Windows system.

I really don’t understand why a bugfix cannot be merged, and should instead wait for unnecessary refactoring, only meant to replace a small part of its implementation detail? @tomerd @compnerd