Merge remote-tracking branch 'upstream/main'

Author: M-J-Hochreiter

.clang-tidy

@@ -1,13 +1,11 @@
 FormatStyle: file
 
 Checks: |
-  clang-diagnostic-*,
-  clang-analyzer-*,
-  -clang-analyzer-core.NullDereference,
-  boost-*,
   bugprone-*,
   -bugprone-easily-swappable-parameters,
   clang-analyzer-*,
+  -clang-analyzer-core.NullDereference,
+  clang-diagnostic-*,
   cppcoreguidelines-*,
   -cppcoreguidelines-non-private-member-variables-in-classes,
   -cppcoreguidelines-special-member-functions,

.cmake-format.yaml

@@ -2,3 +2,6 @@ format:
   line_width: 100
   keyword_case: "upper"
   autosort: true
+
+markup:
+  first_comment_is_literal: true

.editorconfig

@@ -0,0 +1,18 @@
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.{py,pyi}]
+indent_size = 4
+
+[*.md]
+trim_trailing_whitespace = false
+
+[{*.{cmake,cmake.in},CMakeLists.txt}]
+max_line_length = 100

.git_archival.txt

@@ -1,4 +1,3 @@
 node: $Format:%H$
 node-date: $Format:%cI$
 describe-name: $Format:%(describe:tags=true,match=*[0-9]*)$
-ref-names: $Format:%D$

.github/codecov.yml

@@ -25,11 +25,9 @@ flag_management:
       paths:
         - "include"
         - "src"
-      after_n_builds: 1
     - name: python
       paths:
         - "src/mqt/**/*.py"
-      after_n_builds: 3
       statuses:
         - type: project
           threshold: 0.5%

.github/contributing.md

@@ -39,28 +39,34 @@ Nevertheless, please try to follow the guidelines below as well as you can to he
 ## Core Guidelines
 
 - ["Commit early and push often"](https://www.worklytics.co/blog/commit-early-push-often).
-- Write meaningful commit messages (preferably using [gitmoji](https://gitmoji.dev) to give additional context to your commits).
-- Focus on a single feature/bug at a time and only touch relevant files. Split multiple features into multiple contributions.
-- If you added a new feature, you should add tests that ensure it works as intended. Furthermore, the new feature should be documented appropriately.
-- If you fixed a bug, you should add tests that demonstrate that the bug has been fixed.
-- Document your code thoroughly and write readable code.
-- Keep your code clean. Remove any debug statements, left-over comments, or code unrelated to your contribution.
-- Run `pre-commit run -a` to check your code for style and linting errors before committing.
+- Write meaningful commit messages, preferably using [gitmoji](https://gitmoji.dev) for additional context.
+- Focus on a single feature or bug at a time and only touch relevant files. Split multiple features into separate contributions.
+- Add tests for new features to ensure they work as intended. Document new features appropriately.
+- Add tests for bug fixes to demonstrate that the bug has been resolved.
+- Document your code thoroughly and ensure it is readable.
+- Keep your code clean by removing debug statements, leftover comments, and unrelated code.
+- Check your code for style and linting errors before committing.
+- Follow the project's coding standards and conventions.
+- Be open to feedback and willing to make necessary changes based on code reviews.
 
 ## Pull Request Workflow
 
 - Create PRs early. It is ok to create work-in-progress PRs. You may mark these as draft PRs on GitHub.
-- Describe your PR. Start with a descriptive title, reference any related issues by including the issue number in the PR description, and add a comprehensive description of the changes. We provide a PR template that you can (and should) follow to create a PR. Do not delete any sections from the template.
-- Whenever a PR is created or updated, several workflows on all supported platforms and versions of Python are executed. These workflows ensure that the project still builds, that all tests pass, and that the code is properly formatted and introduces no new linting errors. Your PR is expected to pass all these continuous integration (CI) checks before it can be merged. Here are some tips for finding the cause of certain failures:
-  - If any of the `CI / 🇨‌ Test` checks fail, this most likely indicates build errors or test failures in the C++ part of the code base. Look through the respective logs on GitHub for any error or failure messages.
-  - If any of the `CI / 🐍 Test` checks fail, this most likely indicates build errors or test failures in the Python part of the code base. Look through the respective logs on GitHub for any error or failure messages.
-  - If any of the `codecov/\*` checks fail, this means that your changes are not appropriately covered by tests or that the overall project coverage decreased too much. Ensure that you include tests for all your changes in the PR.
-  - If `cpp-linter` comments on your PR with a list of warnings, these have been raised by `clang-tidy` when checking the C++ part of your changes for warnings or style guideline violations. The individual messages frequently provide helpful suggestions on how to fix the warnings. If you don't see any messages, but the `🇨‌ Lint / 🚨 Lint` check is red, click on the `Details` link to see the full log of the check and a step summary.
-  - If the `pre-commit.ci` check fails, some of the `pre-commit` checks failed and could not be fixed automatically by the _pre-commit.ci_ bot. Such failures are most likely related to the Python part of the code base. The individual log messages frequently provide helpful suggestions on how to fix the warnings.
-  - If the `docs/readthedocs.org:mqt-core` check fails, the documentation could not be built properly. Inspect the corresponding log file for any errors.
-- Once your PR is ready, change it from a draft PR to a regular PR and request a review from one of the project maintainers. Please make sure to only request a review once you are done with your changes and the PR is ready to be merged. If you are unsure whether your PR is ready for review, please ask in the PR comments.
-- If your PR gets a "Changes requested" review, you will need to address the feedback and update your PR by pushing to the same branch. You don't need to close the PR and open a new one. Respond to review comments on the PR (e.g., with "done 👍" or "done in @\<commit\>") to let the reviewer know that you have addressed the feedback. Note that reviewers do not get a notification if you just react to the review comment with an emoji. You need to write a comment to notify the reviewer.
-- Be sure to re-request review once you have made changes after a code review so that maintainers know that the requests have been addressed.
+- Describe your PR with a descriptive title, reference any related issues by including the issue number in the PR description, and add a comprehensive description of the changes. Follow the provided PR template and do not delete any sections, except for the issue reference if your PR is not related to an issue.
+- Whenever a PR is created or updated, several workflows on all supported platforms and versions of Python are executed. These workflows ensure that the project still builds, all tests pass, the code is properly formatted, and no new linting errors are introduced. Your PR must pass all these continuous integration (CI) checks before it can be merged.
+- Once your PR is ready, change it from a draft PR to a regular PR and request a review from one of the project maintainers. Only request a review once you are done with your changes and the PR is ready to be reviewed. If you are unsure whether your PR is ready, ask in the PR comments. If you are a first-time contributor, request a review from one of the maintainers by mentioning them in a comment on the PR.
+- If your PR gets a "Changes requested" review, address the feedback and update your PR by pushing to the same branch. Do not close the PR and open a new one. Respond to review comments on the PR (e.g., with "done 👍" or "done in @<commit>") to let the reviewer know that you have addressed the feedback. Note that reviewers do not get a notification if you just react to the review comment with an emoji. Write a comment to notify the reviewer. Do not resolve the review comments yourself. The reviewer will mark the comments as resolved once they are satisfied with the changes.
+- Be sure to re-request a review once you have made changes after a code review so that maintainers know that the requests have been addressed.
+- No need to squash commits before merging; we usually squash them to keep the history clean. We only merge without squashing if the commit history is clean and meaningful. Avoid rebasing or force-pushing your PR branch before merging, as it complicates reviews. You can rebase or clean up commits after addressing all review comments if desired.
+
+Here are some tips for finding the cause of certain failures:
+
+- If any of the `CI / 🇨‌ Test` checks fail, this indicates build errors or test failures in the C++ part of the code base. Look through the respective logs on GitHub for any error or failure messages.
+- If any of the `CI / 🐍 Test` checks fail, this indicates build errors or test failures in the Python part of the code base. Look through the respective logs on GitHub for any error or failure messages.
+- If any of the `codecov/\*` checks fail, this means that your changes are not appropriately covered by tests or that the overall project coverage decreased too much. Ensure that you include tests for all your changes in the PR.
+- If `cpp-linter` comments on your PR with a list of warnings, these have been raised by `clang-tidy` when checking the C++ part of your changes for warnings or style guideline violations. The individual messages frequently provide helpful suggestions on how to fix the warnings. If you don't see any messages, but the `🇨‌ Lint / 🚨 Lint` check is red, click on the `Details` link to see the full log of the check and a step summary.
+- If the `pre-commit.ci` check fails, some of the `pre-commit` checks failed and could not be fixed automatically by the _pre-commit.ci_ bot. Such failures are most likely related to the Python part of the code base. The individual log messages frequently provide helpful suggestions on how to fix the warnings.
+- If the `docs/readthedocs.org:\*` check fails, the documentation could not be built properly. Inspect the corresponding log file for any errors.
 
 ---
 

.github/dependabot.yml

@@ -15,28 +15,30 @@ categories:
       - "feature"
       - "enhancement"
       - "usability"
+      - "refactor"
   - title: "🐛 Bug Fixes"
     labels:
       - "bug"
       - "fix"
   - title: "📄 Documentation"
     labels:
       - "documentation"
-  - title: "🤖 CI"
-    labels:
-      - "continuous integration"
   - title: "📦 Packaging"
     labels:
       - "packaging"
   - title: "🧹 Code Quality"
     labels:
       - "code quality"
+  - title: "🤖 CI"
+    labels:
+      - "continuous integration"
   - title: "⬆️ Dependencies"
     collapse-after: 5
     labels:
       - "dependencies"
       - "submodules"
       - "github_actions"
+      - "pre-commit"
 change-template: "- $TITLE @$AUTHOR (#$NUMBER)"
 change-title-escapes: '\<*_&'
 version-resolver:
@@ -50,10 +52,6 @@ version-resolver:
     labels:
       - "patch"
   default: patch
-autolabeler:
-  - label: "dependencies"
-    title:
-      - "/update pre-commit hooks/i"
 
 template: |
   ## 👀 What Changed

.github/release-drafter.yml

@@ -0,0 +1,38 @@
+{
+  $schema: "https://docs.renovatebot.com/renovate-schema.json",
+  extends: ["config:recommended", ":gitSignOff"],
+  prHourlyLimit: 10,
+  enabledManagers: ["github-actions", "pre-commit", "pep621"],
+  "pre-commit": {
+    enabled: true
+  },
+  lockFileMaintenance: {
+    "enabled": true,
+    // "automerge": true, disabled due to endless update loops caused by setuptools_scm
+  },
+  configMigration: true,
+  labels: ["dependencies"],
+  schedule: ["every weekend"],
+  packageRules: [
+    {
+      matchManagers: ["github-actions"],
+      addLabels: ["github-actions"],
+      commitMessagePrefix: "⬆\uFE0F\uD83D\uDC68\u200D\uD83D\uDCBB"
+    },
+    {
+      matchManagers: ["pep621"],
+      addLabels: ["python"],
+      commitMessagePrefix: "⬆\uFE0F\uD83D\uDC0D"
+    },
+    {
+      matchManagers: ["pre-commit"],
+      addLabels: ["pre-commit"],
+      commitMessagePrefix: "⬆\uFE0F\uD83E\uDE9D",
+    },
+    {
+      "description": "Automerge patch updates",
+      "matchUpdateTypes": ["patch"],
+      "automerge": true
+    }
+  ]
+}

.github/renovate.json5

@@ -1,28 +1,65 @@
 name: CD
 on:
+  push:
+    branches: [main]
   release:
     types: [published]
   workflow_dispatch:
 
+permissions:
+  attestations: write
+  contents: read
+  id-token: write
+
 jobs:
+  # Builds the sdist and wheels on all supported platforms and uploads the resulting
+  # wheels as GitHub artifacts `dev-cibw-*`, `test-cibw-*`, or `cibw-*`, depending on
+  # whether the workflow is triggered from a PR, a push to main, or a release, respectively.
   python-packaging:
     name: 🐍 Packaging
-    uses: ./.github/workflows/reusable-python-packaging.yml
+    uses: cda-tum/mqt-workflows/.github/workflows/[email protected]
+    with:
+      # Do not include local version information on pushes to main to facilitate TestPyPI uploads.
+      no-local-version: ${{ github.ref == 'refs/heads/main' && github.event_name == 'push' }}
+      # Do not build emulated wheels on pushes to main to reduce runner load for CD.
+      build-emulated-wheels: ${{ github.ref != 'refs/heads/main' || github.event_name != 'push' }}
 
+  # Downloads the previously generated artifacts and deploys to TestPyPI on pushes to main
+  deploy-test-pypi:
+    name: 🚀 Deploy to Test PyPI
+    runs-on: ubuntu-latest
+    environment:
+      name: test-pypi
+      url: https://test.pypi.org/p/mqt.core
+    needs: [python-packaging]
+    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
+    steps:
+      - uses: actions/download-artifact@v4
+        with:
+          pattern: test-cibw-*
+          path: dist
+          merge-multiple: true
+      - uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          repository-url: https://test.pypi.org/legacy/
+
+  # Downloads the previously generated artifacts and deploys to PyPI on published releases.
   deploy:
     if: github.event_name == 'release' && github.event.action == 'published'
     name: 🚀 Deploy to PyPI
     runs-on: ubuntu-latest
     environment:
       name: pypi
       url: https://pypi.org/p/mqt.core
-    permissions:
-      id-token: write
     needs: [python-packaging]
     steps:
       - uses: actions/download-artifact@v4
         with:
           pattern: cibw-*
           path: dist
           merge-multiple: true
+      - name: Generate artifact attestation for sdist and wheel(s)
+        uses: actions/attest-build-provenance@v2
+        with:
+          subject-path: "dist/*"
       - uses: pypa/gh-action-pypi-publish@release/v1

.github/workflows/cd.yml

@@ -14,37 +14,41 @@ concurrency:
 jobs:
   change-detection:
     name: 🔍 Change
-    uses: ./.github/workflows/reusable-change-detection.yml
+    uses: cda-tum/mqt-workflows/.github/workflows/reusable-change-detection.yml@v1.5
 
   cpp-tests:
     name: 🇨‌ Test
     needs: change-detection
     if: fromJSON(needs.change-detection.outputs.run-cpp-tests)
-    uses: ./.github/workflows/reusable-cpp-ci.yml
-    secrets:
-      token: ${{ secrets.CODECOV_TOKEN }}
+    uses: cda-tum/mqt-workflows/.github/workflows/reusable-cpp-ci.yml@v1.5
+    with:
+      cmake-args-macos: -DMQT_CORE_WITH_GMP=ON
 
   cpp-linter:
     name: 🇨‌ Lint
     needs: change-detection
     if: fromJSON(needs.change-detection.outputs.run-cpp-linter)
-    uses: ./.github/workflows/reusable-cpp-linter.yml
+    uses: cda-tum/mqt-workflows/.github/workflows/reusable-cpp-linter.yml@v1.5
     with:
       cmake-args: -DBUILD_MQT_CORE_BENCHMARKS=ON
 
   python-tests:
     name: 🐍 Test
     needs: change-detection
     if: fromJSON(needs.change-detection.outputs.run-python-tests)
-    uses: ./.github/workflows/reusable-python-ci.yml
-    secrets:
-      token: ${{ secrets.CODECOV_TOKEN }}
+    uses: cda-tum/mqt-workflows/.github/workflows/[email protected]
 
   code-ql:
     name: 📝 CodeQL
     needs: change-detection
     if: fromJSON(needs.change-detection.outputs.run-code-ql)
-    uses: ./.github/workflows/reusable-code-ql.yml
+    uses: cda-tum/mqt-workflows/.github/workflows/[email protected]
+
+  cd:
+    name: 🚀 CD
+    needs: change-detection
+    if: fromJSON(needs.change-detection.outputs.run-cd)
+    uses: cda-tum/mqt-workflows/.github/workflows/[email protected]
 
   required-checks-pass: # This job does nothing and is only used for branch protection
     name: 🚦 Check
@@ -55,6 +59,7 @@ jobs:
       - cpp-linter
       - python-tests
       - code-ql
+      - cd
     runs-on: ubuntu-latest
     steps:
       - name: Decide whether the needed jobs succeeded or failed
@@ -77,4 +82,8 @@ jobs:
               fromJSON(needs.change-detection.outputs.run-code-ql)
               && '' || 'code-ql,'
             }}
+            ${{
+              fromJSON(needs.change-detection.outputs.run-cd)
+              && '' || 'cd,'
+            }}
           jobs: ${{ toJSON(needs) }}

.github/workflows/ci.yml

@@ -6,9 +6,7 @@ on:
       - main
   pull_request_target:
     types: [opened, reopened, synchronize]
-
-permissions:
-  contents: read
+  merge_group:
 
 jobs:
   update_release_draft: