[CI] Windows: drop test-stage devcontainer + use static CRT - #127

PR NVIDIA#81 introduced devcontainer-based execution for both the build and
test stages of Windows CI. The build stage needs the devcontainer for
MSVC, but the test stage doesn't: the wheel is already built, GPU
access works through the host driver, and pip install + the wheel's
bundled DLL-search patch handle runtime DLL discovery. The
devcontainer adds ~6-8 min per matrix entry to pull the
rapidsai/devcontainers image, repeated across all entries.

This change removes the devcontainer from test-wheel-windows.yml in
favor of host execution, mirroring cuda-python's pattern and the
existing Linux job:

- Drop the `Resolve devcontainer image`, `Pull devcontainer image`,
  and `Run numba-cuda-mlir tests in devcontainer` steps.
- Add a single `Run numba-cuda-mlir tests` step that exports
  NUMBA_CUDA_MLIR*_TEST_WHEEL_ONLY when LOCAL_CTK=0 (matching the
  Linux job) and invokes the test script directly under the
  workflow's default bash shell.
- Delete ci/windows-run-tests-container.ps1 (no longer used).

Also re-enable the TCC driver-mode combinations in ci/test-matrix.yml
that PR NVIDIA#81 commented out as "untested." With host-side execution
they should work, and the entries match cuda-python's Windows TCC
coverage (py3.12 @ 13.0.2/13.2.1, py3.13 @ 12.9.1, py3.14 @ 12.9.1,
py3.14t @ 12.9.1).

ci/windows-common.ps1 and ci/windows-devcontainer.env are left in
place; the build stage still uses them.

The cuSIMT wheel bundles libMLIRPythonCAPI.so / libMLIRToLLVM70.so /
libMLIRPythonSupport-numba_cuda_mlir.so / libLLVM-7.so under
numba_cuda_mlir/_mlir/_mlir_libs and numba_cuda_mlir/lib (via setup.py's
manual staging plus auditwheel-exclude on Linux). The LLVM install dirs
that the test jobs were restoring contain the same libs that the wheel
already ships.

Python tests don't invoke any external LLVM CLI tools either: PR NVIDIA#81
moved FileCheck-style assertions to an in-process parser/matcher, and
there are no subprocess calls to mlir-opt / mlir-translate / llc /
FileCheck / llvm-dis anywhere under tests/ or src/.

If the wheel's RPATH (or DLL-search patch on Windows) is set up
correctly, the restore + LD_LIBRARY_PATH steps are dead weight. Drop
them from:

- test-wheel-linux.yml
- test-expensive-linux.yml
- test-wheel-windows.yml

test-numbast-mlir-linux.yml is left alone: it builds numbast-mlir C++
against the LLVM install dirs inside a conda env, so it may genuinely
need them. Treat separately if confirmed unnecessary.

If CI fails after this change with import/load errors, the fix is to
correct the wheel's RPATH / DLL-search setup in setup.py rather than
to restore these workflow steps.

The first round of CI on PR NVIDIA#127 showed all Windows test entries failing
with:

    ImportError: DLL load failed while importing _mlir:
    A dynamic link library (DLL) initialization routine failed.

Investigation of the wheel showed:

- All bundled DLLs are present (MLIRPythonCAPI, MLIRPythonSupport,
  MLIRModernToNVVM, MLIRToLLVM70, nanobind, LLVM-C, and the
  _mlir.*.pyd).
- The DLL-search patch in _mlir_libs/__init__.py is correctly applied.
- _mlir.pyd's static imports are all resolvable (next-to-pyd DLLs,
  python311.dll, and Windows system DLLs).
- The "LLVM install dir on PATH" trick the devcontainer used wasn't
  actually providing missing user-mode DLLs — only MLIR DLLs that the
  wheel already bundles.

So the failure is a DllMain / static-initializer error in one of the
bundled DLLs, not a missing-file issue. Two changes to make progress:

1. Add CIBW_REPAIR_WHEEL_COMMAND_WINDOWS using delvewheel, matching
   what auditwheel does on Linux. cibuildwheel's Windows default is
   no-op (unlike Linux/macOS), so the wheel had only setup.py's manual
   staging — no transitive dep walk, no DLL search-path init shim from
   delvewheel, no MSVC redist consideration. --add-path points
   delvewheel at the LLVM install bins so it can find anything that
   may live outside the wheel during the dependency walk.

2. Add a continue-on-error "Diagnose DLL loading" step to the Windows
   test job that, before the test run, ctypes.WinDLL-loads each
   bundled DLL in dependency order and reports which one fails first
   with the Windows error code. The bare ImportError doesn't say which
   DLL initialization actually failed; this pins it down.

If delvewheel repair fixes the import on its own, great. If not, the
diagnostic step tells us which specific DLL's init routine is failing,
and we can target the fix there.

Setting CIBW_REPAIR_WHEEL_COMMAND_WINDOWS breaks the build because
cibuildwheel only auto-installs delvewheel when the *default* repair
runs; when you override the command, delvewheel isn't on PATH and the
build fails with "'delvewheel' is not recognized".

cibuildwheel v3.4.1's default Windows repair is already
`delvewheel repair -w {dest_dir} -v {wheel}` with delvewheel
auto-installed — that's what was running on PR NVIDIA#81's wheels. The
diagnostic step on the test side stays, since that's what'll tell us
which specific DLL init is failing.

This also matches cuda-python and numba-cuda, which both leave the
Windows repair command unset and rely on cibuildwheel's default.

First delvewheel attempt failed with
"FileNotFoundError: Unable to find library: nanobind-numba_cuda_mlir.dll".

Per delvewheel docs, it only inspects .pyd import tables and resolves
each dependency against PATH or --add-path; it does NOT look at DLLs
already bundled inside the wheel. setup.py manually stages the MLIR /
nanobind / LLVM7 DLLs into _mlir_libs/ and lib/, but delvewheel needs
the on-disk source path to find them during dependency walking.

Add --add-path entries for the LLVM modern install's MLIR Python libs
dir (which has MLIRPythonCAPI.dll, nanobind-numba_cuda_mlir.dll,
MLIRPythonSupport-numba_cuda_mlir.dll, MLIRModernToNVVM.dll), the LLVM
modern install's bin dir, and the LLVM 7 install's bin dir (LLVM-C.dll).

cibuildwheel invokes repair-wheel-command via Git Bash on Windows (the
earlier failure log shows `+ delvewheel ...` -- bash's set -x prefix),
so $LLVM_MODERN_INSTALL_DIR / $LLVM7_INSTALL_DIR expansion works.

…and \$VAR)

The previous attempt used bash-style \$LLVM_MODERN_INSTALL_DIR in the
delvewheel command, but cibuildwheel runs repair-wheel-command via
cmd.exe on Windows, which doesn't expand \$VAR. The variable appeared
literally in the command and delvewheel still failed to find
nanobind-numba_cuda_mlir.dll.

Switch to repo-relative paths: cibuildwheel runs the command from the
package directory (repo root), and llvm-modern-install/ and
llvm7-install/ are restored there earlier in the workflow. No shell
variable expansion needed.

REPO_DIR=\$(pwd) returns MSYS-style paths under Git Bash on Windows
(e.g. /d/a/.../llvm-modern-install). Downstream tools that run as
Windows-native processes -- cibuildwheel, delvewheel, the wheel's
Python imports -- can't resolve these paths.

The most recent build failure shows delvewheel receiving the MSYS path
verbatim and raising FileNotFoundError on
nanobind-numba_cuda_mlir.dll, even though the .dll exists at the
equivalent Windows path.

Match cuda-python's pattern: on Windows, run REPO_DIR (and the derived
TOOLS_PATH) through cygpath -w so the value is D:\\a\\... rather than
/d/a/... . LLVM_MODERN_INSTALL_DIR and LLVM7_INSTALL_DIR (set later in
this script as REPO_DIR/...) inherit the Windows-native style
automatically, so the delvewheel command's --add-path entries finally
point at paths Windows can resolve.

Commit e6c987f converted REPO_DIR to Windows-native (D:\a\...) in
env-vars on Windows. That broke the build because LLVM_MODERN_INSTALL_DIR
(derived from REPO_DIR) ended up containing backslashes, and the
existing CIBW_ENVIRONMENT_WINDOWS uses cygpath -w on the value as an
unquoted argument. Bash strips backslashes from unquoted args (\a -> a,
\n -> n, etc.), corrupting the path to nonsense before cygpath sees
it. cygpath then produces a garbage Windows path, MLIR_DIR points
nowhere real, and CMake find_package(MLIR) fails.

cuda-python sidesteps this by double-escaping backslashes via a
normpath() helper, but only on CUDA_PATH (which IS used in
CIBW_ENVIRONMENT_WINDOWS); their REPO_DIR isn't piped back through
unquoted bash. cuSIMT's LLVM_*_INSTALL_DIR is derived from REPO_DIR
and *is* used in CIBW_ENVIRONMENT_WINDOWS, so the bash backslash-eating
applies.

Smallest fix: revert env-vars to the MSYS-style REPO_DIR that worked
before, and add an inline cygpath -w in CIBW_REPAIR_WHEEL_COMMAND_WINDOWS
specifically for delvewheel's --add-path entries (delvewheel is the
only consumer that needs Windows-native paths; everything else either
already does its own cygpath conversion or is happy with MSYS form).
cibuildwheel runs the repair command via Git Bash on Windows, so
\$(cygpath -w ...) works inline.

The previous delvewheel-repaired wheel ended up with two physical
copies of each project DLL:
  - numba_cuda_mlir/_mlir/_mlir_libs/MLIRPythonCAPI.dll
    (un-mangled, from setup.py staging)
  - numba_cuda_mlir.libs/MLIRPythonCAPI-<hash>.dll
    (mangled, from delvewheel)

delvewheel patched _mlir.pyd's import table to the mangled name, but
MLIRToLLVM70.dll (loaded later via ctypes.CDLL, not visited by
delvewheel) still imports the un-mangled name and resolves to the
copy in _mlir_libs/. The process winds up with two distinct
MLIRPythonCAPI images, each with its own static state / LLVM
registries. When MLIRToLLVM70 calls into MLIR state that _mlir.pyd
set up via the OTHER copy, the registries are missing -> access
violation in the test job.

setup.py already manages staging of MLIRPythonCAPI / MLIRPythonSupport
/ nanobind into the wheel for uniform Linux/Windows treatment. Tell
delvewheel via --exclude not to bundle a second mangled copy of these.
delvewheel still gets to bundle the real missing pieces (msvcp140
etc.) that setup.py doesn't stage.

Mirrors how cuda_core/pyproject.toml does --exclude for torch DLLs.

…test

Stepping back from the delvewheel-repair rabbit hole. The whole reason
delvewheel was wired in was to bundle a matching msvcp140.dll for our
Windows DLLs, because they were built with the default MSVC CRT linkage
(/MD, dynamic). On the build devcontainer the right redist version was
on PATH; on the bare runner the system msvcp140 didn't match and
init routines failed.

Building with the static CRT (/MT) links the C++ runtime *into* each
DLL, removing the msvcp140 / vcruntime140 import dependency entirely.
The wheel is then genuinely self-contained -- nothing for delvewheel
to bundle. This also dissolves the "two competing bundling
mechanisms" problem (setup.py's manual staging + delvewheel's
repair-with-mangling) we kept tripping over.

Changes:
- ci/build-windows.sh: add `-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded`
  and `-DLLVM_USE_CRT_RELEASE=MT` to the LLVM7, modern LLVM/MLIR, and
  MLIRModernToNVVM bridge cmake invocations.
- ci/build-windows.sh: change the llvm-c-stub.c manual `cl` compile
  from `-MD` to `-MT` so it matches the static LLVM static libs it
  links against (mixing /MT and /MD within the same DLL is a link
  error).
- setup.py: pass `-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded` to the
  cmake invocation for our _cext / _helperlib / _typeconv / _mviewbuf
  and MLIRToLLVM70 builds on Windows.
- .github/workflows/build-wheel.yml: drop CIBW_BEFORE_BUILD_WINDOWS
  (the `pip install delvewheel` line) and CIBW_REPAIR_WHEEL_COMMAND_WINDOWS.
  cibuildwheel's Windows default is no-op, which is what we want now.

The ci/llvm-cache-key.sh hash already includes ci/build-windows.sh, so
editing this file automatically invalidates the existing LLVM cache
keys and triggers a clean rebuild.

Trade-offs of /MT:
- Larger DLLs (each carries its own CRT). MLIRPythonCAPI is already
  ~100 MB; an extra 1-2 MB of CRT code is in the noise.
- C++ stdlib types are unsafe to pass across DLL boundaries (different
  heaps per CRT instance). Our boundary is MLIRPythonCAPI's C API
  plus nanobind/Python-object handoffs through the .pyd files -- no
  C++ stdlib types cross the wire.
- LLVM/MLIR officially supports /MT builds via LLVM_USE_CRT_RELEASE=MT.

The "Install numba-cuda-mlir for diagnostics" + "Diagnose DLL loading"
steps were added in 3b889a5 to pinpoint which bundled DLL was failing
to initialize. Now that /MT static CRT (commit 99d354c) eliminates the
underlying msvcp140 mismatch and Windows tests pass, the diagnostic
step has no purpose -- it's pure debug code that prepends 30+ seconds
to every test job and re-installs the wheel.