findZigLibDirFromSelfExe in infinite loop (Windows)

[BarabasGitHub]

Even invoking zig test empty.zig on an empty file takes forever while consuming 100% of 1 core.
When opening the process with the Visual Studio debugger it shows one main thread with a stack frame that just says [External Code] and the Disassembly view says: No disassembly available.

Zig version: 0.6.0+a31b70c4b
My msvc version according to CmakeOutput.log: Microsoft (R) C/C++ Optimizing Compiler Version 19.27.29112 for x64

It works fine when I build a 'debug'/non-optimized build, after applying this patch to make it compile (and with the release LLVM libs):

diff --git a/cmake/c_flag_overrides.cmake b/cmake/c_flag_overrides.cmake
index c3225d2c4..e0e92ceb3 100644
--- a/cmake/c_flag_overrides.cmake
+++ b/cmake/c_flag_overrides.cmake
@@ -1,6 +1,6 @@
 if(MSVC)
     set(CMAKE_C_FLAGS_DEBUG_INIT
-        "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
+        "/MT /Zi /Od /Ob0 /D NDEBUG")

     set(CMAKE_C_FLAGS_MINSIZEREL_INIT
         "/MT /O1 /Ob1 /D NDEBUG")
diff --git a/cmake/cxx_flag_overrides.cmake b/cmake/cxx_flag_overrides.cmake
index 2f5473df9..0852ef76d 100644
--- a/cmake/cxx_flag_overrides.cmake
+++ b/cmake/cxx_flag_overrides.cmake
@@ -1,6 +1,6 @@
 if(MSVC)
     set(CMAKE_CXX_FLAGS_DEBUG_INIT
-        "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
+        "/MT /Zi /Od /Ob0 /D NDEBUG")

     set(CMAKE_CXX_FLAGS_MINSIZEREL_INIT
         "/MT /O1 /Ob1 /D NDEBUG")

[BarabasGitHub]

Ok, I just by accident discovered this has nothing to do with the build.
I have zig symlinked like this C:\Users\me\bin\zig.exe -> E:\Libraries\Zig\build-release\bin\zig.exe
And since the release build supposedly didn't work I figured I'd symlink E:\Libraries\Zig\build-release\bin\zig.exe - >E:\Libraries\Zig\build-debug\bin\zig.exe
But guess what? Same problem.
However when I invoke E:\Libraries\Zig\build-release\bin\zig.exe or E:\Libraries\Zig\build-debug\bin\zig.exe it works fine.

Soo.... I guess zig tries to do something by looking at it's invocation and somehow it trips over following the symlink across disks?

[BarabasGitHub]

Ok, the problem is when passing "C:\" to dirnameWindows it returns "C:\" and the loop in findZigLibDirFromSelfExe never ends.

/// Both the directory handle and the path are newly allocated resources which the caller now owns.
pub fn findZigLibDirFromSelfExe(
    allocator: *mem.Allocator,
    self_exe_path: []const u8,
) error{ OutOfMemory, FileNotFound }!Compilation.Directory {
    const cwd = fs.cwd();
    var cur_path: []const u8 = self_exe_path;
    while (fs.path.dirname(cur_path)) |dirname| : (cur_path = dirname) {
        var base_dir = cwd.openDir(dirname, .{}) catch continue;
        defer base_dir.close();

        const sub_directory = testZigInstallPrefix(base_dir) orelse continue;
        return Compilation.Directory{
            .handle = sub_directory.handle,
            .path = try fs.path.join(allocator, &[_][]const u8{ dirname, sub_directory.path.? }),
        };
    }
    return error.FileNotFound;
}

[FireFox317]

Same as #6584

[BarabasGitHub]

Walking through the debugger I found another problem. I was a bit surprised that it goes into an infinite loop because the code tries to find the zig libs which for me are at C:\Users\me\lib\zig, so it should find them. But when it does try to open C:\Users\me\lib\zig in testZigInstallPrefix it fails with NOT_A_DIRECTORY. I made a new issue for that one #6642

[MatejKafka]

I believe there are actually 2 problems at play here:

1. Zig enters an infinite loop when resolving parent directory of C:\ and other drive roots on Windows.

2. When zig.exe is invoked through a symlink on Windows, std.fs.selfExePath returns the symlink path (retrieved from PEB.ProcessParameters.ImagePathName), not the real invoked binary path. findZigLibDirFromSelfExe then attempts to find the library path starting at the symlink parent directory, not the target parent directory. This obviously doesn't work when the symlink is not in the same directory as target, and zig recursively reaches the drive root, where it loops due to problem 1). On Linux, std.fs.selfExePath returns the real target path and everything works.