mrbind's CMakeLists does find_package(Clang REQUIRED), which
transitively requires LLVMConfig.cmake from the llvm dev package.
That package is listed only as an *optional* dep of clang, so
pacman did not pull it in automatically — Build MRBind failed
with:

  Could not find a package configuration file provided by "LLVM"
  (requested version 22.1.4)

Add mingw-w64-clang-x86_64-llvm to the install list explicitly.

Two bugs combined to make a real failure look green in
https://github.com/MeshInspector/MeshLib/actions/runs/25392220595/job/74469566838:

1. The 'Generate and build Python bindings' step in
   build-test-windows.yml didn't carry the MSYS2_DIR=C:\msys64 env
   override that the other generate_win.bat / install_mrbind_windows_msys2.bat
   callers on this branch already have. So the script saw the
   default MSYS2_DIR=C:\msys64_meshlib_mrbind, which doesn't exist
   on the runner anymore.

2. generate_win.bat printed 'MSYS2 was NOT found' and then fell
   through to a normal exit, returning code 0. The step's `call`
   inherited that 0, GitHub Actions marked the step green, the
   .pyd never got built, and the failure only surfaced four steps
   later when 'Unit Tests' couldn't load mrmeshpy.pyd
   (LoadLibrary error 126).

Fix both:

* Add `MSYS2_DIR: C:\msys64` to the 'Generate and build Python
  bindings' step's env block, matching Build MRBind / Generate C
  bindings / Generate C# bindings.

* Replace generate_win.bat's silent fall-through with `exit /b 1`
  after the missing-MSYS2 message. Mirrors what
  install_mrbind_windows_msys2.bat already does on the same
  condition. Future workflow callers that forget MSYS2_DIR will
  fail at the right step instead of being papered over until
  something later trips on the missing artifacts.

Add a post-Unit-Tests step (always(), continue-on-error) that
captures state when MRTest.exe's embedded python smoke test
trips `ImportError: initialization failed` from `<string>(2):
<module>`. CPython's wrapper hides the real cause; this dumps:

* contents of source\x64\<config>\ (DLLs, .pyd, EXE) and
  source\x64\<config>\meshlib\
* dumpbin /exports of MR{Test,EmbeddedPython,Python}.{exe,dll}
  and each *.pyd, filtered to PyInit_* — confirms the module
  init function is exported
* dumpbin /dependents of the same, filtered to python*/MR*/CRT —
  shows which python.dll the bindings and the embedded
  interpreter resolve (catches ABI mismatches between vcpkg's
  Python 3.12 and any other python.dll on PATH)
* `py -0p` inventory of available pythons
* a standalone `py -3.12 -c "import meshlib.mrmeshpy"` with
  full traceback — gives the real Python exception instead of
  CPython's wrapped "initialization failed"
* python*.dll listings under C:\vcpkg\installed\...\bin and
  `where.exe` for python3.dll / python312.dll

Step is purely informational; it never fails the job.

Diagnostic on the previous run (PR #6021) revealed that MRBind's
bindings regress when generated with the current MSYS2 mirror's
clang (22.1.4): the `std_vector_const_Mesh` registration is
missing from the generated `mrmeshpy.pyd`, so module init fails
with `AttributeError: module 'meshlib.mrmeshpy' has no attribute
'std_vector_const_Mesh'` — wrapped by CPython as the opaque
`ImportError: initialization failed` MRTest's embedded-python
smoke test surfaces. The historical msys64_meshlib_mrbind.zip
bundle pinned clang 18.1.8-2 specifically because mrbind is
sensitive to libclang's AST shape.

Reproduce that pin without depending on the S3 bundle:

* `Install MRBind toolchain` step now downloads the 9 clang-stack
  .pkg.tar.zst files from `repo.msys2.org/mingw/clang64/` (those
  versioned packages are still served): clang, clang-libs,
  clang-tools-extra, llvm, llvm-libs, libc++, compiler-rt, lld,
  libunwind — all 18.1.8-2-any.
* `pacman -Sy` to refresh DBs, `pacman -S` cmake/ninja/make from
  the current mirror (build tools don't influence binding output
  and don't depend on clang), then `pacman -U` (no --needed) of
  the staged 18.1.8-2 archives so any newer libc++/etc. pulled in
  as cmake/ninja deps gets downgraded to match the pinned clang.
* Same change applied to `pip-build.yml`'s `windows-pip-build`
  job.

Trades the original `vcpkg-export.s3` dependency for
`repo.msys2.org` and locks clang at 18.1.8-2 indefinitely
(unless MSYS2 GCs the historical packages, in which case the
URLs need updating to a still-served version or to a private
mirror).

Previous run downgraded libc++ from 22 to 18 successfully (with
--assume-installed cc-libs), but cmake.exe and ninja.exe — built
against libc++ 22 ABI — couldn't load against libc++ 18 and exited
127 inside the -clang64 shell, taking down Build MRBind:

  Found MSYS2 at `C:\msys64`.
  The system cannot find the file specified.
  ##[error]Process completed with exit code 127.

libc++'s ABI is forward-loose (older binaries against newer libc++
work) but not backward (newer binaries depend on symbols/layout
not in old libc++). So drop libc++ and libunwind from the pinned
list and only keep the clang frontend / llvm / lld / compiler-rt
packages at 18.1.8-2:

* clang/clang-libs/clang-tools-extra
* llvm/llvm-libs
* compiler-rt
* lld

That keeps mrbind running through the clang 18 frontend (which is
what changed binding output and caused the std_vector_const_Mesh
loss) while leaving the runtime fresh enough that cmake/ninja keep
working. Also drop the --assume-installed cc-libs trick — no longer
needed since we no longer downgrade the libc++ that provides cc-libs.
Use `pacman -U --needed` so any future already-installed package
isn't downgrade-attempted.

Pinning only clang/llvm/lld at 18.1.8-2 wasn't enough — clang's
cc.exe failed to start with STATUS_DLL_NOT_FOUND (exit 127) when
the rest of the runtime (libwinpthread-git, crt-git, headers-git,
libc++) was at current versions. clang 18 binaries were built
against a specific late-2024 ABI snapshot that includes those
matching git revisions, and that snapshot is internally consistent
in a way "clang 18 + everything else current" isn't.

Pin the WHOLE mingw/clang64 toolchain to the era of clang 18.1.8-2
— the same 47-package set the historical msys64_meshlib_mrbind.zip
bundle shipped with (matching libwinpthread-git/crt-git/headers-git
12.0.0.r406, libc++ 18.1.8-2, libunwind 18.1.8-2, cmake 3.31.1-1,
ninja 1.12.1-1, etc.). All 47 URLs are still served on
mirror.msys2.org.

* New file: scripts/mrbind/msys2_package_urls_clang18.txt — the
  pinned URL list, extracted from the msys2_package_urls.txt
  snapshot at commit f0fe83c (filtered to mingw/clang64 only).
* Workflow steps: download all 47, then a single
  `pacman -U --noconfirm --needed --overwrite '*'` so dep
  resolution sees a self-consistent set with no version skews and
  no cc-libs marker confusion. --overwrite '*' tolerates files
  already on disk from the runner image's preinstalled MSYS2.

The two mrbind bumps on this branch (1f98820 'Update mrbind.' and
8070543 'Hopefully fix ambiguous Python names.') brought in newer
mrbind that's coupled to clang 22 — the clang frontend changes the
maintainer also reflected in the lockfile bump. Pinning clang back to
18.1.8-2 in CI but keeping the newer mrbind led to incompatibilities
(`AttributeError: module 'meshlib.mrmeshpy' has no attribute
'std_vector_const_Mesh'` resurfacing as a clang-version-specific PCH
macro-mismatch error from `MB_PB11_ADJUST_NAMES`).

Reset thirdparty/mrbind back to commit 2978653c3 (master's tip
before this PR) so the binding generation sees the same mrbind it
was working with under the original bundle's clang 18.1.8-2.

Last run failed with `bash: scripts/mrbind/msys2_download_packages.sh:
No such file or directory` — by default `msys2_shell.cmd -c` starts
the shell in the user's MSYS2 home (~ → /home/runneradmin), not the
workflow's checkout dir. Add `-here` to keep the checkout dir as the
shell's cwd so the relative `scripts/mrbind/...` paths the workflow
passes resolve.

Same `-here` flag the existing install_mrbind_windows_msys2.bat
already uses for the same reason.

The lockfile is stored as LF in git but Windows runners' default
autocrlf checks it out as CRLF. sha256sum -c then fails to open all
47 listed files because each filename has a trailing carriage return.
Strip CRs as we read the lockfile so it's robust to either checkout
encoding.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…f -D

Defining MB_PB11_ADJUST_NAMES as a -D flag with backslashes inside
nested shell quotes ('"s/\bMR:://g"') is fragile under MSYS2: different
bash/make versions strip a different number of backslashes between the
PCH-build recipe and the per-fragment-build recipe. Clang then refuses
to reuse the PCH because the macro definitions don't match textually:

    error: definition of macro 'MB_PB11_ADJUST_NAMES' differs between
    the precompiled header ('"s/\bMR:://g"') and the command line
    ('"s/\bMR:://g"')

Move the define into a force-included header, so the value travels
through C source — which has its own well-defined string-literal
quoting — instead of through bash. -include takes a bare filename
(no shell-quoting concerns), and scripts/mrbind/ is already on the
include path via -I$(makefile_dir) in generate.mk.

Other -D macros in compiler_only_flags.txt are unaffected because
their values contain no backslashes.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… -include

The previous attempt routed the macro via `-include mrbind_pb11_defines.h`
in compiler_only_flags.txt, but clang requires the PCH-import `-include`
to be the FIRST `-include` on the command line. Adding any other
`-include` ahead of it silently disables the PCH:

    warning: precompiled header '<module>.combined_pch.hpp.gch' was
    ignored because '-include <module>.combined_pch.hpp' is not first
    '-include'
    fatal error: '<module>.combined_pch.hpp' file not found

Inject `#include <mrbind_pb11_defines.h>` into the generated
`<module>.combined.hpp` instead. That file is the PCH source, so the
macro is baked into the PCH itself and every fragment that imports the
PCH inherits the definition — no `-include` needed, no flag-order
conflict, and the macro value still travels via C source rather than
through the bash-quoting layer where backslashes get unevenly stripped.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The mrbind parser is invoked over <module>.combined.hpp using
$(COMPILER_FLAGS), which doesn't have -I$(makefile_dir) — only
$(COMPILER) does. The unguarded `#include <mrbind_pb11_defines.h>` I
added to .combined.hpp therefore broke parsing:

    fatal error: 'mrbind_pb11_defines.h' file not found

The parser doesn't need MB_PB11_ADJUST_NAMES (it parses the C++ AST,
not the regex-walking code path inside mrbind's pybind11/core.h).
Wrap the include in `#ifndef MR_PARSING_FOR_PB11_BINDINGS`, mirroring
the existing guard around `<pybind11/pybind11.h>` two lines down. PCH
build (`MR_COMPILING_PB11_BINDINGS`, no parser flag) still pulls it in
and bakes the macro into the PCH; fragments inherit via PCH-import.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ckfile

Master kept two MSYS2 lockfiles in lockstep: msys2_package_urls.txt
(URL per line, fed to wget -i) and msys2_package_hashes.txt (sha256 +
*msys2_packages/<filename>, fed to sha256sum -c). The URL is derivable
from the filename — `msys2_remember_current_packages.sh` already
encodes the package-type → URL prefix mapping when generating the
URLs file.

Move that same mapping into msys2_download_packages.sh: parse the
hash file's filenames, compute URL = `https://mirror.msys2.org/<prefix>/<filename>`,
write to a temp URL list, and feed that to wget. With this, the
suffixed `msys2_package_urls_clang18.txt` is redundant — drop it.

The unsuffixed `msys2_package_urls.txt` still exists on master (for
historical reasons / the regenerator's output) but is no longer
read by the download script. Cleaning that up is out of scope here.

Cache key (hashFiles(msys2_package_hashes_clang18.txt)) is unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…bc++

`--assume-installed mingw-w64-clang-x86_64-libc++=18.1.8-2` didn't
help — pacman still pulled in libc++ 22.1.4-1 because gettext-tools
1.0's dep is `libc++>=22`, and our --assume-installed at 18.1.8-2
doesn't satisfy that constraint.

`--ignore PKG` is the right knob: it tells pacman not to upgrade
the named package even if a dep requests a newer version. gettext-
tools and gettext-libtextstyle still install; libc++ stays at the
pinned 18.1.8-2.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…-pin-clang18

…omment

The "newer clang (>=22) loses the std_vector_const_Mesh registration"
attribution wasn't quite right — that symptom showed up during the
mrbind experiments that motivated this work, not as an inherent
regression in clang 22 itself. Replace with a neutral note that we
pin to the same clang version master ships and that pinning only
clang/llvm causes STATUS_DLL_NOT_FOUND.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…s lockfile

Since msys2_download_packages.sh derives URLs from each filename's
package-type prefix, no script reads msys2_package_urls.txt anymore.
The only remaining consumer was msys2_remember_current_packages.sh
(which writes it). Drop the file and trim the regenerator's URL
echoes to leave just hash-file output.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…file

The URLs lockfile was kept in lockstep with the hashes lockfile, but
each URL is fully determined by the package's filename — the
package-type prefix (`mingw-w64-clang-x86_64-…` → `mingw/clang64/`,
etc.) maps directly to the mirror path. The mapping was already
encoded in `msys2_remember_current_packages.sh` on the writer side.

Move the same mapping into `msys2_download_packages.sh`: parse each
`<sha256> *msys2_packages/<filename>` line of the hashes file,
compute `https://mirror.msys2.org/<prefix>/<filename>`, write to a
temp URL list, and feed that to `wget -i`. Drop the now-unused URL
echoes from the regenerator and delete the 139-line URLs lockfile.

No behavior change for the developer-bootstrap flow
(`install_deps_windows_msys2.bat` calls these scripts and downloads
the same set of packages).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… uses

Both scripts now match PR #6060's versions byte-for-byte:

  * msys2_download_packages.sh accepts an optional SUFFIX positional
    arg, reading `msys2_package_hashes<SUFFIX>.txt` (default suffix
    `''`). Switches `wget -c` → `wget -nc` so a cache hit skips
    files already on disk without HEAD-request round-trips; the
    install script's sha256 verify is the safety net for partials.

  * msys2_install_packages.sh accepts the same optional SUFFIX arg
    in addition to the CR-strip already added in this PR.

Master's CI doesn't pass a suffix (the `install_deps_windows_msys2.bat`
local-developer flow stays unchanged, suffix `''`). PR #6060 calls
`msys2_download_packages.sh _clang18` to read its alternate
`msys2_package_hashes_clang18.txt` lockfile. Landing this in master
means PR #6060's diff for these two scripts drops to zero on rebase.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…-msys2-pin-clang18

build-test-windows.yml and pip-build.yml had identical two-step blocks
(`Cache pinned MSYS2 packages` + `Install MSYS2 for MRBind`). Move them
into `.github/actions/install-msys2-mrbind/action.yml` as a composite
action and have both workflows reference it via `uses:`.

  * build-test-windows.yml: keeps its `if:` guard on the outer step,
    so the composite runs only when mrbind/c-bindings/c-sharp is
    actually needed.
  * pip-build.yml: always invokes the composite (mrbind is always on
    in pip-build).

Same cache key + path as before, so the two workflows continue to
share cache entries. Net: -29 lines in workflows, +24 lines in the
new action.

(The action's path was master's previous composite-action name,
deleted earlier on this branch when the install moved inline. Now
that we have a reusable abstraction again, the path is reused.)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>