[Windows] Don't try to wildcard expand paths starting with \\?\

[mstorsjo]

Summary

Paths that start with \\?\ are absolute paths, and aren't expected
to be used with wildcard expressions.

Previously, the ? at the start of the path triggered the condition
for a potential wildcard, which caused the path to be split and
reassembled. In builds with LLVM_WINDOWS_PREFER_FORWARD_SLASH=ON,
this caused a path like e.g. \\?\D:\tmp\hello.cpp to be reassembled
into \\?\D:\tmp/hello.cpp which isn't a valid path (as such
absolute paths must use backslashes consistently).

This fixes https://github.com/mstorsjo/llvm-mingw/issues/280.

I'm not sure if there's any straightforward way to add a test
for this case, unfortunately.

[mati865]

Confirmed today it solves the problem.

[hans]

lgtm

llvm/lib/Support/Windows/Process.inc

162

Adding "Paths that start with \\?\ are absolute paths, and aren't expected to be used with wildcard expressions." to the comment would be good.

llvm/lib/Support/Windows/Process.inc

 /// have wildcards or doesn't match any files.
 static std::error_code WildcardExpand(StringRef Arg,
                                       SmallVectorImpl<const char *> &Args,
                                       StringSaver &Saver) {
   std::error_code EC;
 
   // Don't expand Arg if it does not contain any wildcard characters. This is
   // the common case. Also don't wildcard expand /?. Always treat it as an
-  // option.
+  // option. Paths that start with \\?\ are absolute paths, and aren't
+  // expected to be used with wildcard expressions.
   if (Arg.find_first_of("*?") == StringRef::npos || Arg == "/?" ||
-      Arg == "-?") {
+      Arg == "-?" || Arg.startswith("\\\\?\\")) {
     Args.push_back(Arg.data());
     return EC;
   }
 
   // Convert back to UTF-16 so we can call FindFirstFileW.
   SmallVector<wchar_t, MAX_PATH> ArgW;
   EC = windows::UTF8ToUTF16(Arg, ArgW);
   if (EC)