Skip to content

Conversation

@denialhaag
Copy link
Member

@denialhaag denialhaag commented Dec 4, 2025

Description

Fixes #1132

Checklist:

  • The pull request only contains commits that are focused and relevant to this change.
  • I have added appropriate tests that cover the new/changed functionality.
  • I have updated the documentation to reflect these changes.
  • I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
  • I have added migration instructions to the upgrade guide (if needed).
  • The changes follow the project's style guidelines and introduce no new warnings.
  • The changes are fully tested and pass the CI checks.
  • I have reviewed my own code changes.

@denialhaag denialhaag self-assigned this Dec 4, 2025
@denialhaag denialhaag added minor Minor version update packaging Anything related to Python packaging labels Dec 4, 2025
@codecov
Copy link

codecov bot commented Dec 4, 2025

@denialhaag denialhaag added extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. and removed extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. labels Dec 4, 2025
@denialhaag denialhaag linked an issue Dec 4, 2025 that may be closed by this pull request
@denialhaag denialhaag removed the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Dec 5, 2025
@burgholzer burgholzer added the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Dec 6, 2025
burgholzer added a commit to munich-quantum-software/setup-mlir that referenced this pull request Dec 6, 2025
Testing in
[`mqt-core`](munich-quantum-toolkit/core#1356)
has revealed that using LTO leads to problems when compiling with
different compilers than the ones being used to compile the static
libraries.

This PR disables the LTO option for macOS arm64, which was the only
setting where it was enabled.

This also directly prepares a release, which should allow us to test the
actions capabilities of picking the latest released version of a
particular LLVM tag.
@denialhaag denialhaag removed the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Dec 22, 2025
burgholzer added a commit that referenced this pull request Dec 31, 2025
## Description

This PR copies over some changes from
#1356 so that the
latter becomes a bit leaner and more focused on relevant changes.

## Checklist:

- [x] The pull request only contains commits that are focused and
relevant to this change.
- [x] ~I have added appropriate tests that cover the new/changed
functionality.~
- [x] ~I have updated the documentation to reflect these changes.~
- [x] ~I have added entries to the changelog for any noteworthy
additions, changes, fixes, or removals.~
- [x] ~I have added migration instructions to the upgrade guide (if
needed).~
- [x] The changes follow the project's style guidelines and introduce no
new warnings.
- [x] The changes are fully tested and pass the CI checks.
- [x] I have reviewed my own code changes.

---------

Signed-off-by: burgholzer <burgholzer@me.com>
Co-authored-by: burgholzer <burgholzer@me.com>
@burgholzer burgholzer added the extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. label Jan 1, 2026
@burgholzer
Copy link
Member

Okay, short summary of the latest findings here:

  • Compiling with gcc under macOS seems impossible with the current setup as there is an inherent incompatibility between the LLVM build that used AppleClang and the gcc build (they do use different C++ stdlib implementations by default, so I suppose this makes sense). Either we remove gcc builds entirely on macOS and add this to the documentation somewhere, or we try to provide additional LLVM builds on macOS compiled with gcc. I'd have a slight tendency to simply remove them.
  • the macOS-14 clang failures are apparently due to the clang version on macos-14 runners being too old to properly support C++20, in particular lambdas with structured bindings. We could work around this by rewriting the respective parts of the code or we could remove the runners from the matrix and declare the compiler version as not supported. The reason the MLIR tests worked here was simply that the MLIR tests where running on macos-15 with a newer version of AppleClang.
  • the Windows release builds fail in the QIR runner tests. This seems fixable and is probably due to some path logic.
  • the Windows debug builds all fail because of the mixture of LLVM libraries compiled in release mode and the project being compiled in debug mode. This triggers several errors because the respective C++ runtimes are not ABI compatible. For these builds to succeed, we need debug builds of LLVM, which I am trying to add in ✨🚸 Add Debug builds of the LLVM toolchain for Windows and optimize distributionΒ munich-quantum-software/portable-mlir-toolchain#4

The rest seems to work just fine already πŸ™ŒπŸΌ

@burgholzer burgholzer force-pushed the enable-mlir branch 5 times, most recently from f08ff04 to 3ecf0db Compare January 4, 2026 20:40
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

Fix all issues with AI Agents πŸ€–
In @mlir/lib/Dialect/QIR/Utils/CMakeLists.txt:
- Around line 20-21: Replace the explicit header listing with a recursive glob
and use that variable in the target_sources call: add a file(GLOB_RECURSE
QIR_UTILS_HEADERS_SOURCE
${MQT_MLIR_SOURCE_INCLUDE_DIR}/mlir/Dialect/QIR/Utils/*.h) and then change the
target_sources(MLIRQIRUtils PUBLIC FILE_SET HEADERS BASE_DIRS
${MQT_MLIR_SOURCE_INCLUDE_DIR} FILES ${MQIR_UTILS_HEADERS_SOURCE}) invocation to
reference the new QIR_UTILS_HEADERS_SOURCE variable so the module follows the
same file(GLOB_RECURSE ...) pattern used across other MLIR modules.

In @mlir/unittests/translation/CMakeLists.txt:
- Around line 29-33: The CMake snippet uses WIN32 to add the MSVC-specific flag
(/EHsc) which breaks non-MSVC Windows toolchains; change the condition to use
MSVC instead of WIN32 so target_compile_options(${testname} PRIVATE /EHsc) only
runs for MSVC, or better yet remove the manual flags and call
enable_project_options(${testname}) (from cmake/CompilerOptions.cmake) to reuse
the centralized exception-handling flags; update the conditional around
target_compile_options or replace it with the enable_project_options invocation
and ensure ${testname} remains the target name referenced.
πŸ“œ Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

πŸ“₯ Commits

Reviewing files that changed from the base of the PR and between 2c47a24 and 7edbeb9.

πŸ“’ Files selected for processing (20)
  • CHANGELOG.md
  • UPGRADING.md
  • cmake/SetupMLIR.cmake
  • cmake/StandardProjectSettings.cmake
  • include/mqt-core/qir/runtime/QIR.h
  • mlir/lib/Dialect/MQTOpt/Transforms/CMakeLists.txt
  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • mlir/lib/Dialect/QIR/Utils/CMakeLists.txt
  • mlir/test/lit.cfg.py
  • mlir/tools/mqt-cc/CMakeLists.txt
  • mlir/tools/quantum-opt/CMakeLists.txt
  • mlir/unittests/translation/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
  • src/qir/runner/Runner.cpp
  • src/qir/runtime/QIR.cpp
  • test/qir/runner/CMakeLists.txt
πŸ’€ Files with no reviewable changes (2)
  • mlir/tools/quantum-opt/CMakeLists.txt
  • mlir/tools/mqt-cc/CMakeLists.txt
🧰 Additional context used
🧠 Learnings (34)
πŸ““ Common learnings
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1356
File: cmake/SetupMLIR.cmake:32-33
Timestamp: 2026-01-04T21:41:30.252Z
Learning: In the munich-quantum-toolkit/core repository, the project provides its own pre-built LLVM/MLIR distributions that are compiled with LLVM_ENABLE_RTTI=ON and LLVM_ENABLE_EH=ON. Users are directed to these distributions via the upgrade guide and installation instructions to avoid ABI compatibility issues. The mid-term goal is to eliminate RTTI and exception handling dependencies entirely.
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1360
File: .github/workflows/reusable-mlir-tests.yml:40-43
Timestamp: 2025-12-05T17:45:37.602Z
Learning: In the munich-quantum-toolkit/core repository, patch releases of LLVM dependencies don't require documentation updates, changelog entries, or additional tests beyond what's validated by passing CI checks.
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/LayeredUnit.cpp:83-86
Timestamp: 2025-12-17T11:32:53.683Z
Learning: In the mlir directory of the munich-quantum-toolkit/core repository, the clang-tidy configuration (mlir/.clang-tidy) prefers marking free functions as `static` over placing them in anonymous namespaces. The configuration enables `llvm-prefer-static-over-anonymous-namespace` and disables `misc-use-anonymous-namespace`. Types/classes should still use anonymous namespaces, but free functions should use explicit `static` linkage.
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1356
File: mlir/CMakeLists.txt:13-15
Timestamp: 2026-01-04T23:01:47.734Z
Learning: In the munich-quantum-toolkit/core repository's MLIR directory (mlir/CMakeLists.txt), the MSVC compile definition `_SILENCE_NONFLOATING_COMPLEX_DEPRECATION_WARNING` is necessary to suppress warnings triggered by MLIR/LLVM internal headers, not because the project code uses non-floating complex types. This suppression is needed to avoid warnings from third-party MLIR/LLVM header includes.
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core-plugins-catalyst PR: 23
File: .readthedocs.yaml:13-18
Timestamp: 2025-12-14T16:51:52.504Z
Learning: In the munich-quantum-toolkit/core-plugins-catalyst repository, LLVM and MLIR toolchains are required for the documentation build because `uv run` includes a full build of the package, which compiles C++/MLIR extensions using scikit-build-core.
πŸ“š Learning: 2026-01-04T22:30:02.780Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1356
File: test/qir/runner/test_qir_runner.cpp:34-34
Timestamp: 2026-01-04T22:30:02.780Z
Learning: In test/qir/runner/test_qir_runner.cpp, when constructing commands for std::system with std::filesystem::path objects, the paths should not be manually quoted. The std::filesystem::path streaming operator already provides appropriate quoting by default, and adding extra quotes around the executable path causes std::system to handle the command incorrectly on Windows.

Applied to files:

  • test/qir/runner/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2025-12-05T15:57:39.701Z
Learnt from: flowerthrower
Repo: munich-quantum-toolkit/core-plugins-catalyst PR: 3
File: lib/Conversion/CatalystQuantumToMQTOpt/CMakeLists.txt:22-25
Timestamp: 2025-12-05T15:57:39.701Z
Learning: The munich-quantum-toolkit projects (core and core-plugins-catalyst) use `file(GLOB_RECURSE ...)` patterns in CMakeLists.txt files to collect header files, following an established convention in the parent repository for consistency across the codebase.

Applied to files:

  • test/qir/runner/CMakeLists.txt
  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • mlir/lib/Dialect/MQTOpt/Transforms/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
πŸ“š Learning: 2025-11-03T23:09:26.881Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1287
File: test/qdmi/dd/CMakeLists.txt:9-21
Timestamp: 2025-11-03T23:09:26.881Z
Learning: The CMake functions `generate_device_defs_executable` and `generate_prefixed_qdmi_headers` used in QDMI device test CMakeLists.txt files are provided by the external QDMI library (fetched via FetchContent from https://github.com/Munich-Quantum-Software-Stack/qdmi.git), specifically in the cmake/PrefixHandling.cmake module of the QDMI repository.

Applied to files:

  • test/qir/runner/CMakeLists.txt
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
πŸ“š Learning: 2025-10-09T13:20:11.483Z
Learnt from: DRovara
Repo: munich-quantum-toolkit/core PR: 1108
File: mlir/test/Dialect/MQTOpt/Transforms/lift-measurements.mlir:269-288
Timestamp: 2025-10-09T13:20:11.483Z
Learning: In the MQT MLIR dialect, the `rz` gate should not be included in the `DIAGONAL_GATES` set for the `ReplaceBasisStateControlsWithIfPattern` because its operator matrix does not have the required shape | 1 0 | / | 0 x | for the targets-as-controls optimization. It is only included in `LiftMeasurementsAboveGatesPatterns` where the matrix structure requirement differs.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-08T12:44:05.883Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Modifiers/CtrlOp.cpp:60-70
Timestamp: 2025-12-08T12:44:05.883Z
Learning: In the Quartz dialect (mlir/lib/Dialect/Quartz/IR/Modifiers/CtrlOp.cpp), negative controls are not supported at the current stage. The RemoveTrivialCtrl pattern correctly only checks getNumPosControls() when determining if a CtrlOp should be removed.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-04T06:59:40.314Z
Learnt from: MatthiasReumann
Repo: munich-quantum-toolkit/core PR: 1301
File: mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/LayeredUnit.cpp:84-85
Timestamp: 2025-12-04T06:59:40.314Z
Learning: In the MQTOpt MLIR routing passes (NaiveRoutingPassSC, AStarRoutingPassSC), the input IR is guaranteed to contain only 1-qubit and 2-qubit gates. All 3+-qubit gates must be decomposed before routing; otherwise the input IR is invalid. This invariant allows skipTwoQubitBlock in LayeredUnit.cpp to safely assert wires.size() == 2.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-02T07:37:46.860Z
Learnt from: MatthiasReumann
Repo: munich-quantum-toolkit/core PR: 1301
File: mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/sc/NaiveRoutingPass.cpp:144-151
Timestamp: 2025-12-02T07:37:46.860Z
Learning: In MLIR transformation code (mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/sc/NaiveRoutingPass.cpp and similar), when inserting operations before a target operation, prefer `rewriter.setInsertionPoint(op)` over `rewriter.setInsertionPointAfter(op->getPrevNode())`. The former is cleaner, avoids null pointer edge cases (when op is first in block), and is semantically clearer.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-10-09T13:25:36.887Z
Learnt from: DRovara
Repo: munich-quantum-toolkit/core PR: 1108
File: mlir/lib/Dialect/MQTOpt/Transforms/ReuseQubitsPattern.cpp:98-100
Timestamp: 2025-10-09T13:25:36.887Z
Learning: In MLIR code, when traversing parent operations to find a common block between two operations where one uses the result of another, explicit bounds checking is not necessary. MLIR's SSA properties and scope locality guarantees ensure that operations using results must be in compatible scopes and will always share a common ancestor in the operation hierarchy.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-08T23:16:20.680Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Flux/IR/Modifiers/CtrlOp.cpp:78-101
Timestamp: 2025-12-08T23:16:20.680Z
Learning: In the Flux dialect (mlir/lib/Dialect/Flux/IR/Modifiers/CtrlOp.cpp), negative controls are not supported at the current stage. The CtrlInlineGPhase canonicalization pattern correctly only checks getNumPosControls() and processes only positive controls when inlining a GPhaseOp.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-17T17:44:31.349Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/include/mlir/Dialect/QCO/IR/QCOOps.td:259-259
Timestamp: 2025-12-17T17:44:31.349Z
Learning: In the QCO dialect (mlir/include/mlir/Dialect/QCO/IR/QCOOps.td), GPhaseOp intentionally uses `MemoryEffects<[MemWrite]>` instead of `Pure` to prevent the remove-dead-values pass from eliminating it. Since GPhaseOp is a zero-target operation with no result values, it would otherwise be removed by DCE, even though it has a meaningful effect on the global quantum state.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-08T23:44:39.930Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/Quartz/IR/Operations/StandardGates/PhaseOp.cpp:0-0
Timestamp: 2025-12-08T23:44:39.930Z
Learning: In MLIR code under any mlir/ directory, avoid using const qualifiers on core MLIR types in function parameters/signatures (e.g., Value, Type, Attribute, Operation*, Block*, Region*, etc.). This aligns with MLIR's design rationale and should be applied to C++ source files (e.g., .cpp) within mlir/; see https://mlir.llvm.org/docs/Rationale/UsageOfConst/ for details.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-17T11:32:45.843Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/LayeredUnit.cpp:83-86
Timestamp: 2025-12-17T11:32:45.843Z
Learning: In the mlir portion of munich-quantum-toolkit/core, prefer marking free functions as static (static linkage) over placing them in anonymous namespaces, per the clang-tidy rule llvm-prefer-static-over-anonymous-namespace. Do not apply this to type/class definitions; they may continue to use anonymous namespaces. This guideline should be checked across C++ source files under mlir/ (e.g., any free function in LayeredUnit.cpp) to ensure free functions have static linkage, while types/classes can remain in anonymous namespaces.

Applied to files:

  • mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp
πŸ“š Learning: 2025-12-05T17:45:37.602Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1360
File: .github/workflows/reusable-mlir-tests.yml:40-43
Timestamp: 2025-12-05T17:45:37.602Z
Learning: In the munich-quantum-toolkit/core repository, patch releases of LLVM dependencies don't require documentation updates, changelog entries, or additional tests beyond what's validated by passing CI checks.

Applied to files:

  • UPGRADING.md
  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • src/qir/runtime/QIR.cpp
  • cmake/SetupMLIR.cmake
  • cmake/StandardProjectSettings.cmake
  • mlir/test/lit.cfg.py
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2026-01-04T21:41:30.252Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1356
File: cmake/SetupMLIR.cmake:32-33
Timestamp: 2026-01-04T21:41:30.252Z
Learning: In the munich-quantum-toolkit/core repository, the project provides its own pre-built LLVM/MLIR distributions that are compiled with LLVM_ENABLE_RTTI=ON and LLVM_ENABLE_EH=ON. Users are directed to these distributions via the upgrade guide and installation instructions to avoid ABI compatibility issues. The mid-term goal is to eliminate RTTI and exception handling dependencies entirely.

Applied to files:

  • UPGRADING.md
  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • src/qir/runtime/QIR.cpp
  • cmake/SetupMLIR.cmake
  • mlir/lib/Dialect/QIR/Utils/CMakeLists.txt
  • cmake/StandardProjectSettings.cmake
  • mlir/test/lit.cfg.py
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • mlir/lib/Dialect/MQTOpt/Transforms/CMakeLists.txt
  • src/qir/runner/Runner.cpp
  • src/qdmi/na/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2025-12-14T16:51:52.504Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core-plugins-catalyst PR: 23
File: .readthedocs.yaml:13-18
Timestamp: 2025-12-14T16:51:52.504Z
Learning: In the munich-quantum-toolkit/core-plugins-catalyst repository, LLVM and MLIR toolchains are required for the documentation build because `uv run` includes a full build of the package, which compiles C++/MLIR extensions using scikit-build-core.

Applied to files:

  • UPGRADING.md
  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • cmake/SetupMLIR.cmake
  • mlir/test/lit.cfg.py
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
  • CHANGELOG.md
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2025-12-01T11:00:40.342Z
Learnt from: flowerthrower
Repo: munich-quantum-toolkit/core-plugins-catalyst PR: 1
File: CHANGELOG.md:18-18
Timestamp: 2025-12-01T11:00:40.342Z
Learning: In the munich-quantum-toolkit/core-plugins-catalyst repository, the CHANGELOG.md intentionally references the parent MQT Core repository's release notes (https://github.com/munich-quantum-toolkit/core/releases) because the plugin repository is based on work performed in the parent repository.

Applied to files:

  • UPGRADING.md
πŸ“š Learning: 2026-01-04T23:01:47.734Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1356
File: mlir/CMakeLists.txt:13-15
Timestamp: 2026-01-04T23:01:47.734Z
Learning: In the munich-quantum-toolkit/core repository's MLIR directory (mlir/CMakeLists.txt), the MSVC compile definition `_SILENCE_NONFLOATING_COMPLEX_DEPRECATION_WARNING` is necessary to suppress warnings triggered by MLIR/LLVM internal headers, not because the project code uses non-floating complex types. This suppression is needed to avoid warnings from third-party MLIR/LLVM header includes.

Applied to files:

  • UPGRADING.md
  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • cmake/SetupMLIR.cmake
  • mlir/lib/Dialect/QIR/Utils/CMakeLists.txt
  • cmake/StandardProjectSettings.cmake
  • mlir/unittests/translation/CMakeLists.txt
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • mlir/lib/Dialect/MQTOpt/Transforms/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2026-01-04T23:54:33.540Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1356
File: src/qdmi/na/CMakeLists.txt:179-184
Timestamp: 2026-01-04T23:54:33.540Z
Learning: In the munich-quantum-toolkit/core repository, MSVC link-time code generation (LTCG) must be disabled for the NA device dynamic library target (mqt-core-qdmi-na-device-dyn) on Windows to avoid link errors and missing symbols. This issue affects both release-only builds and debug/release mixed builds, not just debug/release mixing scenarios.

Applied to files:

  • UPGRADING.md
  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • cmake/SetupMLIR.cmake
  • cmake/StandardProjectSettings.cmake
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2025-10-09T13:14:10.178Z
Learnt from: DRovara
Repo: munich-quantum-toolkit/core PR: 1108
File: mlir/lib/Dialect/MQTOpt/Transforms/ReplaceBasisStateControlsWithIfPattern.cpp:219-221
Timestamp: 2025-10-09T13:14:10.178Z
Learning: The MQT Core project (munich-quantum-toolkit/core repository) uses the C++20 standard, not C++17. C++20 features such as abbreviated function templates (e.g., `const auto&` parameters) are supported and valid in this codebase.

Applied to files:

  • UPGRADING.md
πŸ“š Learning: 2025-11-04T14:28:32.371Z
Learnt from: marcelwa
Repo: munich-quantum-toolkit/core PR: 1243
File: test/python/qdmi/qiskit/test_qdmi_qiskit_backend.py:0-0
Timestamp: 2025-11-04T14:28:32.371Z
Learning: In the munich-quantum-toolkit/core repository, at least one FoMaC device is always available during testing, so skip logic for missing devices in QDMI Qiskit backend tests is not necessary.

Applied to files:

  • UPGRADING.md
πŸ“š Learning: 2025-10-10T08:09:54.528Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1246
File: bindings/CMakeLists.txt:0-0
Timestamp: 2025-10-10T08:09:54.528Z
Learning: In the Munich Quantum Toolkit (MQT) Core project, scikit-build-core is configured with `wheel.install-dir = "mqt/core"` in pyproject.toml, which automatically prefixes all CMake `DESTINATION` paths with `mqt/core/` during wheel installation. Therefore, CMake install destinations are relative to the `mqt/core` package namespace, not `site-packages`.

Applied to files:

  • UPGRADING.md
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2025-12-05T15:54:56.385Z
Learnt from: flowerthrower
Repo: munich-quantum-toolkit/core-plugins-catalyst PR: 3
File: lib/Conversion/CatalystQuantumToMQTOpt/CMakeLists.txt:19-20
Timestamp: 2025-12-05T15:54:56.385Z
Learning: The munich-quantum-toolkit/core-plugins-catalyst project does not support Windows builds, so MSVC-specific compiler options or cross-platform compatibility with MSVC is not required.

Applied to files:

  • UPGRADING.md
  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
πŸ“š Learning: 2025-12-17T11:32:53.683Z
Learnt from: denialhaag
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/MQTOpt/Transforms/Transpilation/LayeredUnit.cpp:83-86
Timestamp: 2025-12-17T11:32:53.683Z
Learning: In the mlir directory of the munich-quantum-toolkit/core repository, the clang-tidy configuration (mlir/.clang-tidy) prefers marking free functions as `static` over placing them in anonymous namespaces. The configuration enables `llvm-prefer-static-over-anonymous-namespace` and disables `misc-use-anonymous-namespace`. Types/classes should still use anonymous namespaces, but free functions should use explicit `static` linkage.

Applied to files:

  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • cmake/SetupMLIR.cmake
  • mlir/lib/Dialect/QIR/Utils/CMakeLists.txt
  • mlir/test/lit.cfg.py
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • mlir/lib/Dialect/MQTOpt/Transforms/CMakeLists.txt
  • src/qir/runner/Runner.cpp
  • src/qdmi/na/CMakeLists.txt
  • CHANGELOG.md
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2025-12-28T17:14:53.890Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1403
File: src/qdmi/na/CMakeLists.txt:31-38
Timestamp: 2025-12-28T17:14:53.890Z
Learning: In the munich-quantum-toolkit/core repository, the NA device generator target (mqt-core-qdmi-na-device-gen) is intentionally propagated to MQT_CORE_TARGETS via list(APPEND) because it's publicly linked to the NA device library (the NA device uses a public function from the generator). The SC device generator is not propagated because it has no such dependency with the SC device library.

Applied to files:

  • mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt
  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
  • src/qir/runner/CMakeLists.txt
πŸ“š Learning: 2025-11-01T15:57:31.153Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1283
File: src/qir/runtime/QIR.cpp:196-201
Timestamp: 2025-11-01T15:57:31.153Z
Learning: In the QIR runtime (src/qir/runtime/QIR.cpp), the PRX gate (__quantum__qis__prx__body) is an alias for the R gate (Phased X-Rotation) and should call runtime.apply<qc::R>(theta, phi, qubit), not runtime.apply<qc::RX>() which is a single-parameter rotation gate.

Applied to files:

  • src/qir/runtime/QIR.cpp
πŸ“š Learning: 2025-12-08T23:41:55.972Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1264
File: mlir/lib/Dialect/QIR/Builder/QIRProgramBuilder.cpp:96-117
Timestamp: 2025-12-08T23:41:55.972Z
Learning: In the QIR (Quantum Intermediate Representation) Builder (mlir/lib/Dialect/QIR/Builder/QIRProgramBuilder.cpp), the `ptrCache` is intentionally shared between qubit and result pointer creation (in `staticQubit()` and `measure()` methods) because QIR uses opaque pointers and `inttoptr` conversions for both qubits and results. For any given index N, the LLVM IR pointer representation is identical whether it represents a qubit or a result, so the pointer only needs to be created once and can be safely reused across both contexts.

Applied to files:

  • src/qir/runtime/QIR.cpp
πŸ“š Learning: 2025-11-24T10:19:41.147Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1326
File: python/mqt/core/__init__.py:22-22
Timestamp: 2025-11-24T10:19:41.147Z
Learning: In the munich-quantum-toolkit/core repository, Ruff is configured with 'ALL' rules enabled by default, and only specific rules are selectively disabled. When reviewing changes that enable previously-disabled rules (like PLC0415), noqa directives for those rules become necessary and should be retained.

Applied to files:

  • cmake/SetupMLIR.cmake
  • cmake/StandardProjectSettings.cmake
  • src/qdmi/na/CMakeLists.txt
πŸ“š Learning: 2025-12-14T15:23:54.712Z
Learnt from: flowerthrower
Repo: munich-quantum-toolkit/core-plugins-catalyst PR: 23
File: docs/conf.py:110-130
Timestamp: 2025-12-14T15:23:54.712Z
Learning: In the munich-quantum-toolkit/core-plugins-catalyst repository, the Ruff configuration has 'ALL' rules enabled with only specific rules disabled. PLR6301 (no-self-use) is active, so `# noqa: PLR6301` directives are necessary for methods that don't use self, even if Ruff reports RUF100 warnings suggesting the directive is unused.

Applied to files:

  • cmake/SetupMLIR.cmake
πŸ“š Learning: 2025-10-10T08:10:16.394Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1246
File: test/python/na/test_na_fomac.py:35-0
Timestamp: 2025-10-10T08:10:16.394Z
Learning: In the munich-quantum-toolkit/core repository, scikit-build-core is configured with `wheel.install-dir = "mqt/core"` in pyproject.toml, which means CMake `install()` commands with `DESTINATION <path>` install files relative to `mqt/core/` in the wheel, making them accessible via `files("mqt.core").joinpath("<path>")`.

Applied to files:

  • mlir/test/lit.cfg.py
πŸ“š Learning: 2025-12-28T17:05:10.588Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1403
File: test/qir/runner/test_qir_runner.cpp:35-35
Timestamp: 2025-12-28T17:05:10.588Z
Learning: In the munich-quantum-toolkit/core repository, Windows Unicode support (via _wsystem) is not needed for test utilities like test/qir/runner/test_qir_runner.cpp. Using std::system is acceptable for system calls in tests.

Applied to files:

  • mlir/unittests/translation/CMakeLists.txt
πŸ“š Learning: 2025-12-07T09:10:31.836Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1355
File: src/qdmi/sc/Device.cpp:97-102
Timestamp: 2025-12-07T09:10:31.836Z
Learning: In the munich-quantum-toolkit/core repository, duplication of QDMI-related macros (such as IS_INVALID_ARGUMENT) across device implementations (e.g., in src/qdmi/sc/Device.cpp and src/qdmi/dd/Device.cpp) is acceptable as a temporary measure. The preferred long-term solution is to upstream these macros to the QDMI repository rather than creating local shared headers, so they can be reused across all dependent projects.

Applied to files:

  • mlir/lib/Dialect/QC/Translation/CMakeLists.txt
  • src/qdmi/sc/CMakeLists.txt
  • src/qir/runner/Runner.cpp
  • src/qdmi/na/CMakeLists.txt
πŸ“š Learning: 2025-12-28T17:13:36.900Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1403
File: pyproject.toml:98-102
Timestamp: 2025-12-28T17:13:36.900Z
Learning: In the munich-quantum-toolkit/core project, scikit-build-core is intelligent enough to skip build targets listed in pyproject.toml that don't exist for a given platform, so platform-specific targets (like `-dyn` targets conditioned on `NOT WIN32`) can be unconditionally listed in `build.targets` without causing Windows build failures.

Applied to files:

  • src/qdmi/sc/CMakeLists.txt
  • src/qdmi/na/CMakeLists.txt
πŸ“š Learning: 2026-01-04T22:25:13.956Z
Learnt from: burgholzer
Repo: munich-quantum-toolkit/core PR: 1356
File: src/qir/runner/Runner.cpp:70-76
Timestamp: 2026-01-04T22:25:13.956Z
Learning: In src/qir/runner/Runner.cpp, the REGISTER_SYMBOL macro intentionally performs dual registration (both llvm::sys::DynamicLibrary::AddSymbol and adding to manualSymbols vector) to ensure symbol resolution works correctly when compiling with shared libraries enabled, even though it may appear redundant.

Applied to files:

  • src/qir/runner/Runner.cpp
  • src/qir/runner/CMakeLists.txt
🧬 Code graph analysis (1)
src/qir/runner/Runner.cpp (1)
src/qir/runtime/QIR.cpp (30)
  • __quantum__rt__result_get_zero (24-27)
  • __quantum__rt__result_get_zero (24-24)
  • __quantum__rt__result_get_one (29-32)
  • __quantum__rt__result_get_one (29-29)
  • __quantum__rt__result_equal (34-37)
  • __quantum__rt__result_equal (34-34)
  • __quantum__rt__result_update_reference_count (39-53)
  • __quantum__rt__result_update_reference_count (39-40)
  • __quantum__rt__array_create_1d (56-65)
  • __quantum__rt__array_create_1d (56-56)
  • __quantum__rt__array_get_size_1d (67-69)
  • __quantum__rt__array_get_size_1d (67-67)
  • __quantum__rt__array_get_element_ptr_1d (71-77)
  • __quantum__rt__array_get_element_ptr_1d (71-71)
  • __quantum__rt__array_update_reference_count (79-88)
  • __quantum__rt__array_update_reference_count (79-80)
  • __quantum__rt__qubit_allocate (91-94)
  • __quantum__rt__qubit_allocate (91-91)
  • __quantum__rt__qubit_allocate_array (96-104)
  • __quantum__rt__qubit_allocate_array (96-96)
  • __quantum__rt__qubit_release (106-109)
  • __quantum__rt__qubit_release (106-106)
  • __quantum__rt__qubit_release_array (111-121)
  • __quantum__rt__qubit_release_array (111-111)
  • __quantum__qis__x__body (124-127)
  • __quantum__qis__x__body (124-124)
  • __quantum__qis__y__body (129-132)
  • __quantum__qis__y__body (129-129)
  • __quantum__qis__cx__body (281-284)
  • __quantum__qis__cx__body (281-281)
πŸͺ› Cppcheck (2.19.0)
mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp

[information] 18-18: Include file

(missingIncludeSystem)

src/qir/runner/Runner.cpp

[information] 20-20: Include file

(missingIncludeSystem)


[information] 21-21: Include file

(missingIncludeSystem)


[information] 22-22: Include file

(missingIncludeSystem)


[information] 51-51: Include file

(missingIncludeSystem)

πŸ”‡ Additional comments (24)
cmake/StandardProjectSettings.cmake (1)

40-41: LGTM! MSVC colored diagnostics addition is correct.

The MSVC branch correctly adds colored diagnostic output, consistent with the existing Clang and GNU branches. The /diagnostics:color flag is functional in MSVC 17+ (though undocumented), and the cosmetic nature of this feature makes it a safe addition.

cmake/SetupMLIR.cmake (1)

32-33: LGTM! RTTI and exception handling enablement is correct.

The explicit enabling of RTTI and exception handling is necessary for the codebase (dynamic_cast in QC translation/MQTRef dialect, throw in MQTOpt transforms). ABI compatibility is ensured through project-provided pre-built LLVM/MLIR distributions that users are directed to via installation instructions.

Based on learnings, the project provides properly compiled distributions and plans to eliminate these dependencies mid-term.

test/qir/runner/CMakeLists.txt (2)

17-17: Good fix for path robustness.

Resolving QIR_FILES_DIR to an absolute canonical path ensures consistent path resolution across platforms and likely addresses the Windows path-handling issues mentioned in the PR objectives.


19-19: Good catch on the comment correction.

The updated comment now correctly references QIR_FILES instead of the incorrect QIR_EXECUTABLES.

mlir/lib/Dialect/MQTOpt/Transforms/CMakeLists.txt (1)

14-21: LGTM! Improved formatting and appropriate DISABLE_INSTALL flag.

The multi-line formatting enhances readability, and the DISABLE_INSTALL flag correctly marks this transforms library as internal-only (not part of the public install target), which aligns with the project's MLIR packaging strategy.

mlir/lib/Dialect/MQTOpt/Transforms/MergeRotationGatesPattern.cpp (2)

18-18: LGTM!

The include is necessary for llvm_unreachable and correctly added.


172-172: LGTM!

The use of llvm_unreachable correctly marks this path as unreachable and follows LLVM/MLIR conventions. This change addresses the feedback from the previous review.

mlir/lib/Dialect/MQTRef/Translation/CMakeLists.txt (1)

18-19: No action required. The DISABLE_INSTALL flag is appropriate for this internal library.

The verification shows that MLIRMQTRefTranslation is only referenced within unit tests and internal build targets. There are no external consumers (other CMake projects or public API users) that depend on this library. While public headers are exposed during the build, the library itself is internal infrastructure for quantum computation translation and should not be installed as a standalone artifact.

mlir/lib/Dialect/QC/Translation/CMakeLists.txt (1)

17-19: LGTM!

The addition of MLIRQCProgramBuilder as a dependency is appropriate for translation functionality, and the dependency ordering (dialects β†’ program builder β†’ MQT::CoreIR) is logical. The DISABLE_INSTALL flag correctly marks this as an internal library, which is standard practice for translation utilities that are typically used at build-time rather than as part of the public API.

src/qir/runtime/QIR.cpp (1)

71-77: LGTM! Null check properly addresses defensive programming suggestion.

The addition of array == nullptr check prevents dereferencing a null pointer in the call to __quantum__rt__array_get_size_1d, addressing the defensive programming suggestion from the previous review. The combined check elegantly handles all invalid cases (null array, negative index, out-of-bounds) by returning nullptr.

CHANGELOG.md (1)

28-28: LGTM! Changelog entry accurately documents the major change.

The entry correctly describes enabling MLIR by default for C++ library builds, is appropriately categorized under "Changed", and follows the project's changelog format conventions.

include/mqt-core/qir/runtime/QIR.h (1)

72-74: LGTM! Documentation accurately reflects the nullptr return behavior.

The updated documentation correctly describes that nullptr is returned for invalid indices. While the implementation also handles null arrays, the concise wording "out of bounds" is appropriate for user-facing API documentation.

UPGRADING.md (1)

7-26: LGTM! Comprehensive documentation of MLIR enablement and limitations.

The upgrade guide clearly documents:

  • MLIR is now a required build dependency for C++ builds
  • Pre-built distributions and installation instructions
  • Opt-out mechanism via -DBUILD_MQT_CORE_MLIR=OFF
  • Python package status (not yet enabled)
  • Known platform-specific limitations

All previously suggested improvements have been addressed, including proper markdown link formatting and documentation of known compiler/platform constraints.

Based on learnings, the project provides pre-built LLVM/MLIR distributions compiled with RTTI and exception handling enabled, which users are directed to via these instructions.

mlir/test/lit.cfg.py (1)

18-18: LGTM! Robust tool discovery implementation.

The changes implement a clean, platform-aware tool discovery mechanism with proper error handling:

  1. Import placement: The sys import is correctly placed and necessary for platform detection (line 49).

  2. LLVM tools validation: The initial check for required LLVM tools (lines 42-46) properly validates all three tools and provides a clear error message.

  3. Tool discovery logic: The quantum-opt discovery (lines 48-69) correctly:

    • Handles platform-specific naming (Windows .exe extension)
    • Searches candidate directories in a logical order
    • Prevents duplicate directory checks
    • Uses the found flag appropriately
    • Provides descriptive error messages if the tool is missing

Previous review concerns have been properly addressed.

Also applies to: 42-69

src/qdmi/na/CMakeLists.txt (2)

54-55: LGTM: Consistent application of project options and warnings.

Adding MQT::ProjectOptions and MQT::ProjectWarnings to the generator executable target aligns with the existing pattern used for the dynamic library target (line 169) and ensures consistent compiler settings across build artifacts.


179-184: LGTM: Necessary MSVC workaround.

The MSVC-specific workaround to disable link-time code generation for the dynamic library target is necessary to avoid link errors and missing symbols on Windows builds, as confirmed in past review discussions.

Based on learnings, this issue affects both release-only builds and debug/release mixed builds.

src/qdmi/sc/CMakeLists.txt (2)

51-52: LGTM: Consistent application of project options and warnings.

Adding MQT::ProjectOptions and MQT::ProjectWarnings to the generator executable target aligns with the existing pattern used for the dynamic library target (line 166) and ensures consistent compiler settings across build artifacts.


176-181: LGTM: Necessary MSVC workaround.

The MSVC-specific workaround to disable link-time code generation for the dynamic library target is necessary to avoid link errors and missing symbols on Windows builds, consistent with the identical workaround applied to the NA device dynamic library.

Based on learnings, this issue affects both release-only builds and debug/release mixed builds.

src/qir/runner/Runner.cpp (3)

20-22: LGTM! Necessary includes for the symbol registration mechanism.

The new includes support the manual symbol registration pattern: CoreContainers.h provides SymbolMap, ExecutionUtils.h provides ExecutorAddr utilities, and vector supports the manualSymbols container.


181-191: LGTM! Correct LLVM ORC JIT host symbol export pattern.

The implementation properly exports host symbols to the JIT by:

  1. Creating absolute symbols from the manualSymbols registry
  2. Defining them in the main JIT dylib
  3. Adding a DynamicLibrarySearchGenerator for fallback process-wide symbol resolution

This complements the REGISTER_SYMBOL macro (lines 70-76), which was confirmed in a previous review to intentionally perform dual registration to support shared library builds. Based on learnings from previous review.


258-318: LGTM! Systematic registration of QIR runtime and quantum instruction symbols.

The REGISTER_SYMBOL macro is correctly applied to register all quantum runtime (quantum__rt) and quantum instruction set (quantum__qis) symbols. All registrations occur in main() during single-threaded initialization, eliminating race condition concerns on the global manualSymbols vector.

src/qir/runner/CMakeLists.txt (2)

12-12: LGTM! Aligns with enabling MLIR by default.

The unconditional add_llvm_tool call (removing the previous MLIR_VERSION guard) correctly implements the PR's objective to enable MLIR by default for C++ builds. The EXPORT_SYMBOLS flag ensures proper symbol visibility for dynamic linking scenarios.


24-29: LGTM! Explicit output directories improve build organization.

Setting explicit output directory properties using standard CMAKE_INSTALL_LIBDIR and CMAKE_INSTALL_BINDIR variables is good practice and ensures cross-platform compatibility while centralizing build artifacts in predictable locations.

mlir/lib/Dialect/QIR/Utils/CMakeLists.txt (1)

11-18: No action needed. The DISABLE_INSTALL flag follows the established project pattern and is present across 21+ other MLIR library definitions (Dialects, Conversions, Transforms, etc.). Since this file is newly created, it is not a breaking change; it establishes MLIRQIRUtils as an internal utility library used by other MLIR modules within the project.

denialhaag and others added 19 commits January 7, 2026 17:26
Remove dedicated MLIR tests workflow and update workflows

Signed-off-by: burgholzer <burgholzer@me.com>
…tions

Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
…ndows

Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
…tions)`

Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
Signed-off-by: Lukas Burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
Signed-off-by: burgholzer <burgholzer@me.com>
@burgholzer
Copy link
Member

Okay, given how we already merged the dialect redesign PR, which should not be part of v3.4, I am also going to merge this PR as soon as the CI is green in order to not have it sit around for too long and become stale again.
I'll try to get the stable v3.x branch set up afterwards as soon as possible.

@burgholzer burgholzer merged commit e1bd396 into main Jan 8, 2026
307 of 331 checks passed
@burgholzer burgholzer deleted the enable-mlir branch January 8, 2026 10:59
burgholzer added a commit that referenced this pull request Jan 8, 2026
## Description

This PR copies over some changes from
#1356 so that the
latter becomes a bit leaner and more focused on relevant changes.

## Checklist:

- [x] The pull request only contains commits that are focused and
relevant to this change.
- [x] ~I have added appropriate tests that cover the new/changed
functionality.~
- [x] ~I have updated the documentation to reflect these changes.~
- [x] ~I have added entries to the changelog for any noteworthy
additions, changes, fixes, or removals.~
- [x] ~I have added migration instructions to the upgrade guide (if
needed).~
- [x] The changes follow the project's style guidelines and introduce no
new warnings.
- [x] The changes are fully tested and pass the CI checks.
- [x] I have reviewed my own code changes.

---------

Signed-off-by: burgholzer <burgholzer@me.com>
Co-authored-by: burgholzer <burgholzer@me.com>
(cherry picked from commit 70b9d1f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

extensive-cpp-ci Adding this label indicates that extensive C++ CI runs should be started for this PR. major Major version update packaging Anything related to Python packaging

Projects

None yet

Development

Successfully merging this pull request may close these issues.

πŸ“¦ MLIR - Enable by default and package MLIR/LLVM in Releases

3 participants