build(deps): bump DavidAnson/markdownlint-cli2-action from 19 to 20 (#1273)

* build(deps): bump DavidAnson/markdownlint-cli2-action from 19 to 20

Bumps [DavidAnson/markdownlint-cli2-action](https://github.com/davidanson/markdownlint-cli2-action) from 19 to 20.
- [Release notes](https://github.com/davidanson/markdownlint-cli2-action/releases)
- [Commits](DavidAnson/markdownlint-cli2-action@v19...v20)

---
updated-dependencies:
- dependency-name: DavidAnson/markdownlint-cli2-action
  dependency-version: '20'
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>

* Fix new lints in markdownlint@v20

---------

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Leon Matthes <[email protected]>

Author: dependabot[bot]

.github/workflows/github-cxx-qt-tests.yml

@@ -59,7 +59,7 @@ jobs:
     runs-on: ubuntu-24.04
     steps:
       - uses: actions/checkout@v4
-      - uses: DavidAnson/markdownlint-cli2-action@v19
+      - uses: DavidAnson/markdownlint-cli2-action@v20
         with:
           globs: '**/*.md'
 

README.md

@@ -155,7 +155,7 @@ The following CMake source files are available under the BSD-3-Clause
 
 * [cmake/CompilerCaching.cmake](./cmake/CompilerCaching.cmake) - a helper for using sccache
 
-# About KDAB
+## About KDAB
 
 CXX-Qt is supported and maintained by Klarälvdalens Datakonsult AB (KDAB).
 

book/src/concepts/casting.md

@@ -10,7 +10,7 @@ SPDX-License-Identifier: MIT OR Apache-2.0
 With the [base](../bridge/attributes.md) attribute, it is possible to inherit from another type.
 In order to access this parent class, we provide an API to cast up or down.
 Currently, this is supported for objects in both `extern "RustQt"` *and* `extern "C++Qt"` blocks, which have either a `#[qobject]` attribute,
-or a `#[base = T]` attribute. see [here](../bridge/attributes.md) for more details on these attributes.
+or a `#[base = T]` attribute. See the [attributes documentation](../bridge/attributes.md) for more details on these attributes.
 > Note: Types in "C++Qt" blocks are **required** to have the `#[qobject]` attribute
 
 ## Accessing the base class

book/src/concepts/wasm-builds.md

@@ -11,7 +11,7 @@ CXX-Qt and applications written with it can be compiled for WebAssembly, with a
 
 You will need to have Qt for WebAssembly installed. The next section shows versions that have been tested.
 
-Additionally, if you haven't already, clone the `emsdk` git repo from [here](https://github.com/emscripten-core/emsdk).
+Additionally, if you haven't already, clone the [`emsdk` git repo from Github](https://github.com/emscripten-core/emsdk).
 
 ## Using Correct Versions
 
@@ -200,4 +200,4 @@ error[E0433]: failed to resolve: use of undeclared type `IovLen`
 
 `socket2` is a dependency of `async-io`, which is a dependency of `async-std`.
 
-There is discussion around supporting wasm in the GitHub repository for `async-std`, and the progress is being tracked [here](https://github.com/async-rs/async-std/issues/220).
+There is discussion around supporting wasm in the GitHub repository for `async-std`, and the progress is being tracked [in this issue](https://github.com/async-rs/async-std/issues/220).

book/src/internals/build-system.md

@@ -25,21 +25,21 @@ We want to make the generated headers available, not just to CMake, but also wit
 
 For this we need to export them to a stable directory so that both CMake and Cargo can find them.
 
-# (Optional) Integration with CMake
+### (Optional) Integration with CMake
 
 Somehow, all of this should be compatible with both CMake, and Cargo-only builds.
 
-# The plan (for now)
+## The plan (for now)
 
 After many rounds of refactoring this, we believe that we need to be able to share data between build scripts for this to work halfway ergonomically.
 
-We want to use a similar approach to CXX, which uses Cargos `links` key to ensure a correct build order (see the documentation [here](https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key)).
+We want to use a similar approach to CXX, which uses Cargos `links` key to ensure a correct build order (see the [links key documentation](https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key)).
 When building with cxx-qt-build, you may simply specify that your code depends on another crate.
 Cargo will then make sure that the build scripts of the dependencies have run **before** the build script of this crate.
 
 We can additionally pass metadata between build scripts, which we use to find the `manifest.json` of each crate and the path to their "target" directory.
 
-## The "target" directory
+### The "target" directory
 
 Each build script can export artifacts into a folder with a well-known layout.
 It is also required to export a `manifest.json` file that tells downstream dependencies which of these artifacts to include and how to configure their own build.
@@ -68,7 +68,7 @@ Next to the crates directory, there should be a `qml_modules` directory, which c
 
 Each module should include a `plugin_init.o`, `.qmltypes`, `qmldir`, and any other necessary files.
 
-## Initializers with Cargo and CMake
+### Initializers with Cargo and CMake
 
 There are multiple ways to solve the issues presented by static initializers:
 
@@ -99,7 +99,7 @@ In CMake we mirror Qts behavior, which is to build the static initializer as an
 The initializer functions themselves are still built into the Rust static library and the `OBJECT` library must therefore link to it.
 This is taken care of by the `cxx_qt_import_crate`/`_import_qml_module` functions.
 
-## Integration with CMake
+### Integration with CMake
 
 Via the `CXXQT_EXPORT_DIR` environment variable CMake should be able to change the location of the "target" directory.
 CMake can then expect required artifacts to exist at pre-defined locations, which can be added as dependency, include directories, objects, etc. to the Crate target.

book/src/internals/crate-organization.md

@@ -20,7 +20,7 @@ This page lays out the goal of each crate and how it is differentiated from the
 - [🦾 `qt-build-utils` - Building with Qt](#qt-build-utils)
 - [🤝 `cxx-qt-cmake` - Handoff to CMake](#cxx-qt-cmake)
 
-# <a name="cxx-qt"></a>⭐ `cxx-qt` - The Star of the Show
+## <a name="cxx-qt"></a>⭐ `cxx-qt` - The Star of the Show
 
 The main crate of CXX-Qt.
 
@@ -39,7 +39,7 @@ Apart from a few extremely basic types that are needed for this goal, wrapping t
 
 This should also allow `cxx-qt-lib` and `cxx-qt-lib-extras` to be used without the user needing to use the `cxx-qt` crate itself, which is why they're explicitly seperated.
 
-# <a name="cxx-qt-build"></a> 👷 `cxx-qt-build` - The Construction Worker
+## <a name="cxx-qt-build"></a> 👷 `cxx-qt-build` - The Construction Worker
 
 `cxx-qt-build` provides the user-accessible API for building applications with CXX-Qt.
 
@@ -51,7 +51,7 @@ For CMake, it exposes the required artifacts into a well-known directory and str
 
 The access to Qts build tooling has actually been made available as a separate crate: `qt-build-utils`, which `cxx-qt-build` uses internally
 
-# <a name="cxx-qt-gen"></a> 💚 `cxx-qt-gen` - The Heart of CXX-Qt
+## <a name="cxx-qt-gen"></a> 💚 `cxx-qt-gen` - The Heart of CXX-Qt
 
 This crate contains the "main functionality" of CXX-Qt.
 
@@ -68,7 +68,7 @@ This transpiler is then used by the `#[cxx_qt::bridge]` macro via `cxx-qt-macro`
 
 > TODO: Add a documentation of the cxx-qt-gen stages and architecture in a separate page
 
-# <a name="cxx-qt-lib"></a> 📖 `cxx-qt-lib` - The "standard" Library
+## <a name="cxx-qt-lib"></a> 📖 `cxx-qt-lib` - The "standard" Library
 
 `cxx-qt-lib` is to `cxx-qt`, what Rusts `std` library is to `rustc`.
 
@@ -92,7 +92,7 @@ Additional types can be added into a separate, less maintained, crate (namely: `
 
 This leads us to the concrete policy for including types in `cxx-qt-lib`:
 
-## `cxx-qt-lib` inclusion policy
+### `cxx-qt-lib` inclusion policy
 
 - Default to adding anything you think may be useful to `cxx-qt-lib-extras`
 - Only add types to `cxx-qt-lib` directly, if they're either:
@@ -101,7 +101,7 @@ This leads us to the concrete policy for including types in `cxx-qt-lib`:
 
 We can then always promote types from -lib-extras to -lib, if/when it turns out this type is used regularly.
 
-# <a name="cxx-qt-lib-extras"></a> 📚 `cxx-qt-lib-extras` - The Bookshelf
+## <a name="cxx-qt-lib-extras"></a> 📚 `cxx-qt-lib-extras` - The Bookshelf
 
 As mentioned in the `cxx-qt-lib` library, we do not aim to maintain wrappers for the entire Qt API.
 However, it would still be useful to have a place where the community can share and collect bindings for whatever they have wrapped of the Qt API.
@@ -137,19 +137,19 @@ Simply copying individual files out of the crate into your own crate is also a r
 
 We only ask that you contribute your own wrappers and fixes back to -lib-extras so the wider ecosystem can benefit.
 
-# <a name="cxx-qt-macro"></a> 💻 `cxx-qt-macro` - Frontend for cxx-qt-gen
+## <a name="cxx-qt-macro"></a> 💻 `cxx-qt-macro` - Frontend for cxx-qt-gen
 
 For technical reasons within Cargo, procedural macros need to be a special type of crate.
 
 `cxx-qt-macro` wraps the bridge macro, which is then re-exported by the `cxx-qt` crate.
 
-# <a name="qt-build-utils"></a> 🦾 `qt-build-utils` - Building with Qt
+## <a name="qt-build-utils"></a> 🦾 `qt-build-utils` - Building with Qt
 
 This crate wraps Qts custom build tooling like moc.
 
 It is mostly used by `cxx-qt-build`. But because it may be useful to other crates in the Qt ecosystem as well, we have decided to split it into its own crate.
 
-# <a name="cxx-qt-cmake"></a> 🤝 [`cxx-qt-cmake`](https://github.com/kdab/cxx-qt-cmake) - Handoff to CMake
+## <a name="cxx-qt-cmake"></a> 🤝 [`cxx-qt-cmake`](https://github.com/kdab/cxx-qt-cmake) - Handoff to CMake
 
 Whilst this is not a crate, it's a separate "project", as it lives in another repository.
 `cxx-qt-cmake` simply contains the bits of CMake code that encapsulate the integration of `cxx-qt-build` artifacts into CMake.