Either disable tests via -DLLVM_INCLUDE_TESTS=OFF or install clang-tools-extra:

$ pacman -Qo /clang64/lib/libclangApplyReplacements.a
/clang64/lib/libclangApplyReplacements.a is owned by mingw-w64-clang-x86_64-clang-tools-extra 18.1.8-1

Since there is no check() there is no point in building test utils, so the first option is better.

Looks like openmp requires python to build since llvm/llvm-project@88dae3d

Looks like openmp requires python to build since llvm/llvm-project@88dae3d

Thank you.

I removed flang from this PR because it depends on the new mlir version. Now CLANG64 fails because of mingw-w64-llvm-openmp. Maybe I should move it to another PR with flang.

  -- The Fortran compiler identification is unknown
  -- Detecting Fortran compiler ABI info
  CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
  Missing variable is:
  CMAKE_Fortran_PREPROCESS_SOURCE
  CMake Error at D:/M/msys64/clang64/share/cmake/Modules/CMakeDetermineCompilerABI.cmake:74 (try_compile):
    Failed to generate test project build system.
  Call Stack (most recent call first):
    D:/M/msys64/clang64/share/cmake/Modules/CMakeTestFortranCompiler.cmake:20 (CMAKE_DETERMINE_COMPILER_ABI)
    runtime/CMakeLists.txt:267 (enable_language)

This is looking good so far. But the CLANG64 runner timed out.
What you potentially could do is dropping mlir from this PR. Afaict, it is currently only required to build flang. Since you already dropped flang from here, you could drop mlir, too.

If that succeeds, you'd need to check if the build artifacts from here can be used to build the remaining LLVM packages. (You might need to check that locally.)

If you checked that all of them build correctly, you'd need to go ahead and check if the reverse dependencies already caught up to LLVM 19. That is probably especially the packages that depend on llvm-libs:
https://packages.msys2.org/packages/mingw-w64-clang-x86_64-llvm-libs
I.e., most likely arrow, spirv, and zig.
If they build (or you found which patches would need to be cherry-picked to allow them to build with LLVM 19), we could start with merging this PR and follow up from there.

As long as we don't know that the update won't break at one of the steps described above, we probably shouldn't start merging this.

For arrow, you might need to cherry-pick apache/arrow#44233.
For zig, maybe ziglang/zig#21444. Edit: Maybe more complete: ziglang/zig@c6ad452
For SPIR-V, maybe update to version 19.1.0: https://github.com/KhronosGroup/SPIRV-LLVM-Translator/releases/tag/v19.1.0

I could update arrow and spirv-llvm-translator but not zig. The patches do not apply. I don't know what to do with zig. Update to git HEAD?

I don't know what to do with zig

you don't have to rush with llvm update

Oof. The list of packages that are affected by API/ABI changes in some shape or form is longer than I expected:

mingw-w64-zig
mingw-w64-qt-creator
mingw-w64-qt6-tools
mingw-w64-spirv-llvm-translator
mingw-w64-cvise
mingw-w64-flang
mingw-w64-mlir
mingw-w64-include-what-you-use
mingw-w64-arrow
mingw-w64-castxml
mingw-w64-qt6-static
mingw-w64-creduce
mingw-w64-mesa
mingw-w64-openshadinglanguage

Some of them are packages from the LLVM monorepo. So, the plan is to update them anyway. For most of the remaining packages, a simple rebuild might be enough. (Probably worth testing though.)

I could update arrow and spirv-llvm-translator but not zig. The patches do not apply. I don't know what to do with zig. Update to git HEAD?

If I'm reading the commit history for the zig package correctly, it was broken for several years and was only fixed in July. Maybe, @raedrizqie has an idea how to proceed with that package. (Maybe, break it again?)

Maybe just dont rebuild zig after this update, and try rebuild zig on its next version update?