fix: Extend ALTERNATIVE_LOCATIONS for ARM64 Windows

`gix-path` looks for and runs an installed `git` executable, when
present, to discover information about how Git is set up. This
is used in several functions in `gix_path::env()`, especially on
Windows, where if `git` is not found in a `PATH` search, then
common installation locations for Git for Windows are checked.

These locations on Windows are resolved based on information from
the current environment, since different systems have different
program files directories. This was implemented in GitoxideLabs#1456 (which
built on GitoxideLabs#1419). Although this was sufficient to find the most
common Git for Windows installation locations, it did not find
ARM64 builds of Git for Windows. Such builds place the non-shim
`git.exe` program in `(git root)\clangarm64\bin`, rather than in
`(git root)\mingw64\bin` or `(git root)\mingw32\bin`. At the time
of GitoxideLabs#1416 and GitoxideLabs#1419, no stable ARM64 builds of Git for Windows were
available. Since then, Git for Windows began releasing such builds.

This modifies the alternative locations examined if `git.exe` is
not found in a `PATH` search on Windows so that, where `(git root)`
is in a 64-bit program files directory, we check for a
`(git root)\clangarm64\bin` directory, in addition to checking for
a `(git root)\mingw64\bin` directory as was already done.

Although 64-bit and 32-bit program files directories are separate,
on ARM64 systems the 64-bit program files directory is used for
both ARM64 programs that the system can run directly and x86_64
programs that the system must run through emulation.

This checks both `clangarm64` and `mingw64`, where `mingw64` was
checked before. It does so in that order, because if both are
available, then we are probably on an ARM64 system, and the ARM64
build of Git for Windows should be preferred, both because it will
tend to perform better and because the user is likely to expect
that to be used. (An x86_64 build, especially if present directly
alongside an ARM64 build, may be left over from a previous version
of Git for Windows that didn't have ARM64 builds and that was only
incompletely uninstalled.)

This checks both, in that order, on all systems where we had
checked `mingw64` before, even on x86_64 systems. This is because,
to limit production dependencies and code complexity, we have been
examining only environment variables to ascertain which program
files directories exist and whether they are 64-bit or 32-bit
program files directories; and at least for now, this preserves
that general approach. But determining whether the system is ARM64
or x86_64 is less straightforward (than program files directory
locations) to ascertain from environment variables, if we are to
accommodate all reasonable edge cases.

The reason is that, if our parent process (or other ancestor)
passes down a sanitized environment while still attempting to allow
the program files directories to be found, then:

- That process should make available all of the `ProgramFiles`,
  `ProgramW6432`, and `ProgramFiles(x86)` variables that exist in
  its own environment.

  This is becauses, on 64-bit Windows, the child `ProgramFiles` is
  populated from the parent `ProgramW6432`, `ProgramFiles(x86)`, or
  `ProgramFiles(ARM)`, depending on the architectures of the parent
  and child, if the parent passes down the relevant variable.

- Even if the parent/ancestor is not designed with the WoW64 rules
  in mind, it will likely pass down at least `ProgramFiles`.

  This will then be used as the child `ProgramFiles`, if whichever
  of `ProgramFilesW6432`, `ProgramFiles(x86)`, or
  `ProgramFiles(ARM)` is relevant is not passed down by the parent.

- In contrast, the parent/ancestor may omit the variables
  `PROCESSOR_ARCHITECTURE` and `PROCESSOR_ARCHITEW6432`, which are
  not obviously needed for locating programs.

- Even if `PROCESSOR_ARCHITE*` variables are preserved, there are
  common cases where they are not sufficient, such as when we are
  an x86_64 build, but the system is ARM64 and Git for Windows is
  ARM64. `gix-path` is a library crate, and it is highly plausible
  that it may be used in an x86_64 program on such a system.

  Also, if it is used in an Arm64EC program, then even though its
  code may be ARM64, the program would still be treated as an
  x86_64 program in its interactions with the system and other
  programs, including in how its environment variables' values are
  populated and how their values are adjusted due to WoW64.

- Although the `PROCESSOR_IDENTIFIER` variable is more reliable if
  present (see actions/partner-runner-images#117 for an example of
  where this is more reliable than `PROCESSOR_ARCHITECTURE`), it
  is more complex to parse. More importantly it may be omitted even
  if a parent/ancestor lets `PROCESSOR_ARCHITE*` through.

- It would sometimes work to look for `ProgramFiles(ARM)`; if set,
  then the Windows system could be treated as ARM64. However, this
  may be omitted even if other program files related environment
  variables including `ProgramFiles(x86)` are passed down. This
  could happen because the `ProgramFiles(ARM)` environment variable
  is less well known. It could also happen if the parent process is
  only passing down variables needed to find Git for Windows, for
  which one should not need to know the 32-bit ARM program files
  directory location, since Git for Windows has never had 32-bit
  ARM builds.

  Relatedly, augmenting the search by checking the filesystem for a
  sibling directory named `Program Files (ARM)` should not be done,
  because this directory has no special meaning outside of ARM64
  Windows. It may therefore be left over from a previous
  installation or migration, or even created by a local user as in
  the CVE-2024-40644 scenario patched in GitoxideLabs#1456.

(Complexities related to deciding whether and in what order to
search `bin` subdirectories of `clangarm64`, `mingw64`, and
`mingw32` would go away if we looked for the shim rather than the
non-shim executable. This is because the path from `(git root)` to
the shim does not contain a directory component named after a build
target. That simplification would carry its own tradeoffs, and it
is unclear if it ought to be done; it is not done here.)

Author: EliahKagan

gix-path/src/env/git/mod.rs

@@ -38,38 +38,42 @@ where
     // known. So the situation where a process only passes down `ProgramFiles` sometimes happens.
     let varname_current = "ProgramFiles";
 
-    // 64-bit relative bin dir. So far, this is always `mingw64`, not `ucrt64`, `clang64`, or `clangarm64`.
-    let suffix_64 = Path::new(r"Git\mingw64\bin");
+    // 64-bit relative bin dirs. So far, this is always `mingw64` or `clangarm64`, not `urct64` or
+    // `clang64`. We check `clangarm64` before `mingw64`, because in the strage case that both are
+    // available, we don't want to skip over a native ARM64 executable for an emulated x86_64 one.
+    let suffixes_64 = [r"Git\clangarm64\bin", r"Git\mingw64\bin"].as_slice();
 
-    // 32-bit relative bin dir. So far, this is always `mingw32`, not `clang32`.
-    let suffix_32 = Path::new(r"Git\mingw32\bin");
+    // 32-bit relative bin dirs. So far, this is only ever `mingw32`, not `clang32`.
+    let suffixes_32 = [r"Git\mingw32\bin"].as_slice();
 
     // Whichever of the 64-bit or 32-bit relative bin better matches this process's architecture.
     // Unlike the system architecture, the process architecture is always known at compile time.
     #[cfg(target_pointer_width = "64")]
-    let suffix_current = suffix_64;
+    let suffixes_current = suffixes_64;
     #[cfg(target_pointer_width = "32")]
-    let suffix_current = suffix_32;
+    let suffixes_current = suffixes_32;
 
     let rules = [
-        (varname_64bit, suffix_64),
-        (varname_x86, suffix_32),
-        (varname_current, suffix_current),
+        (varname_64bit, suffixes_64),
+        (varname_x86, suffixes_32),
+        (varname_current, suffixes_current),
     ];
 
     let mut locations = vec![];
 
-    for (name, suffix) in rules {
+    for (name, suffixes) in rules {
         let Some(pf) = var_os_func(name) else { continue };
         let pf = Path::new(&pf);
         if pf.is_relative() {
             // This shouldn't happen, but if it does then don't use the path. This is mainly in
             // case we are accidentally invoked with the environment variable set but empty.
             continue;
         }
-        let location = pf.join(suffix);
-        if !locations.contains(&location) {
-            locations.push(location);
+        for suffix in suffixes {
+            let location = pf.join(suffix);
+            if !locations.contains(&location) {
+                locations.push(location);
+            }
         }
     }