[15/N] [libcxx] Implement the canonical function for windows

[mstorsjo]

Rebased on top of updated patches.

[amccarth]

libcxx/src/filesystem/operations.cpp

863

This return value needs to be checked more carefully.

If the final path is longer than the buffer, then GetFinalPathNameByHandleW will return the actual length needed, which will convince this if statement that the call succeeded when it didn't, and then we'll process the uninitialized buffer.

How can the final path require a buffer longer than MAX_PATH? Two ways:

1. The function always returns the \\?\ prefix, so a path that (with it's terminating L'\0') is exactly MAX_PATH will require MAX_PATH+4 when the prefix is added.

2. MAX_PATH applies to most Windows APIs, but not to the actual filesystem. It's possible to have a final path that's longer than MAX_PATH (especially since it's using the \\?\ prefix). If we don't think it's worth handling those, fine, but we'd need to detect that case so that we can return an error. (A common way this happens is when the user uses subst to replace a long prefix with a fictitious drive letter. This is, in fact, how we get certain LLDB source paths under the MAX_PATH limit on some of the Windows build bots.)

[mstorsjo]

libcxx/src/filesystem/operations.cpp

863

Thanks, good catch. Will update with a stack buffer that should fit all practical cases (MAX_PATH+10) and fall back on dynamic allocation if that wasn't big enough.

[mstorsjo]

Check the return value of GetFinalPathNameFromHandleW if it overflowed the buffer size and handle it appropriately.

[amccarth]

LGTM.

[mstorsjo]

Made a new realpath posix-like helper for windows, change explicit char to path::value_type in calling code.

[mstorsjo]

Rebased, retriggering CI.

Compared to the older version that @amccarth approved, this is a little bit reworked to fit into the POSIX realpath() interface, which means it returns a malloc() allocated buffer, so the end of the function uses a bit of memmove/wcscpy to assemble paths, instead of the slightly simpler version before (when operating on the level of the __canonical function that returns a std::filesystem::path).

This touches the existing code a little bit to just change char into path::value_type, and add the detail:: prefix on the calls to realpath().

[amccarth]

The changes to provide realpath on Windows looks right. Since it's relying on a system call, it would be difficult to create tests for the \\?\ and UNC cases. I'm assuming the more mainstream cases will be tested by existing tests. So LGTM.

libcxx/src/filesystem/operations.cpp

path __canonical(path const& orig_p, error_code* ec) {
 
   path p = __do_absolute(orig_p, &cwd, ec);
 #if defined(_POSIX_VERSION) && _POSIX_VERSION >= 200112
   std::unique_ptr<char, decltype(&::free)>
     hold(::realpath(p.c_str(), nullptr), &::free);
   if (hold.get() == nullptr)
     return err.report(capture_errno());
   return {hold.get()};
+#elif defined(_LIBCPP_WIN32API)
+  wchar_t ret[MAX_PATH];
+  detail::WinHandle h(p.c_str(), FILE_READ_ATTRIBUTES, 0);
+  if (!h)
+    return err.report(detail::make_windows_error(GetLastError()));
+  if (!GetFinalPathNameByHandleW(h, ret, MAX_PATH,
+                                 FILE_NAME_NORMALIZED | VOLUME_NAME_DOS))
+    return err.report(detail::make_windows_error(GetLastError()));
+  if (!wcsncmp(ret, L"\\\\?\\", 4)) {
+    if (ret[5] == ':') // \\?\X: -> X:
+      return {&ret[4]};
+    if (!wcsncmp(&ret[4], L"UNC\\", 4)) // \\?\UNC\server -> \\server
+      return {std::wstring(L"\\\\") + &ret[8]};
+  }
+  return {ret};
 #else
   char buff[PATH_MAX + 1];
   char* ret;
   if ((ret = ::realpath(p.c_str(), buff)) == nullptr)
     return err.report(capture_errno());
   return {ret};
 #endif
 }