Check and fix broken links in docs (#1085)

This PR adds a Github workflow to check if there is any broken links in
the docs. It also fixes existing broken links found by the workflow.
This PR closes #1084.

.github/workflows/link-check.yml

@@ -0,0 +1,30 @@
+name: Check broken links in docs
+
+on:
+  pull_request:
+    branches:
+      - master
+
+jobs:
+  check-broken-links-in-docs:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: Restore lychee cache
+        uses: actions/cache@v3
+        with:
+            path: .lycheecache
+            key: cache-lychee-${{ github.sha }}
+            restore-keys: cache-lychee-
+      - name: Check links in docs/*.md
+        uses: lycheeverse/[email protected]
+        with:
+          fail: true
+          token: ${{ secrets.GITHUB_TOKEN }}
+          args: --base docs --accept '200,201,202,203,204,429,500' --no-progress --cache --max-cache-age 1d './docs/**/*.md' --exclude https://users.cecs.anu.edu.au/~steveb/pubs/papers/**
+      - name: Save lychee cache
+        uses: actions/cache/save@v3
+        if: always()
+        with:
+            path: .lycheecache
+            key: ${{ steps.restore-cache.outputs.cache-primary-key }}

.github/workflows/merge-check.yml

@@ -20,7 +20,7 @@ jobs:
           # - this action
           # - minimal tests for stable Rust (we allow them to fail)
           # - binding tests (it may take long to run)
-          ignoreActions: "ready-to-merge,check-public-api-changes,minimal-tests-core/x86_64-unknown-linux-gnu/stable,minimal-tests-core/i686-unknown-linux-gnu/stable,minimal-tests-core/x86_64-apple-darwin/stable,v8-binding-test,openjdk-binding-test,jikesrvm-binding-test,julia-binding-test,ruby-binding-test (release),ruby-binding-test (debug)"
+          ignoreActions: "ready-to-merge,check-broken-links-in-docs,check-public-api-changes,minimal-tests-core/x86_64-unknown-linux-gnu/stable,minimal-tests-core/i686-unknown-linux-gnu/stable,minimal-tests-core/x86_64-apple-darwin/stable,v8-binding-test,openjdk-binding-test,jikesrvm-binding-test,julia-binding-test,ruby-binding-test (release),ruby-binding-test (debug)"
           # This action uses API. We have a quota of 1000 per hour.
           checkInterval: 600
         env:

docs/userguide/src/portingguide/howto/nogc.md

@@ -13,7 +13,11 @@ You want to set up the binding repository/directory structure before starting th
 
 [^1]: In fact some bindings may not be able to have such a directory structure due to the build tools used by the runtime.
 
-  - `mmtk-X/mmtk`: The MMTk side of the binding. To start with, this can be an almost direct copy of the [Dummy VM binding](https://github.com/mmtk/mmtk-core/tree/master/vmbindings/dummyvm). This is implemented in Rust.
+  - `mmtk-X/mmtk`: The MMTk side of the binding. This includes the implementation of [the `VMBinding` trait](https://docs.mmtk.io/api/mmtk/vm/trait.VMBinding.html),
+    and any necessary Rust code to integrate MMTk with the VM code (e.g. exposing MMTk functions to native, allowing up-calls from the MMTk binding to the runtime, etc).
+    To start with, you can take a look at one of our officially maintained language bindings as an example: [OpenJDK](https://github.com/mmtk/mmtk-openjdk/tree/master/mmtk),
+    [JikesRVM](https://github.com/mmtk/mmtk-jikesrvm/tree/master/mmtk), [V8](https://github.com/mmtk/mmtk-v8/tree/master/mmtk), [Julia](https://github.com/mmtk/mmtk-julia/tree/master/mmtk),
+    [V8](https://github.com/mmtk/mmtk-v8/tree/master/mmtk).
   - `mmtk-X/X`: Runtime-specific code for integrating with MMTk. This should act as a bridge between the generic GC interface offered by the runtime and the MMTk side of the binding. This is implemented in the runtime's implementation language. Often this will be one of C or C++.
   - You can place your runtime repository at any path. For the sake of this guide, we assume you will place the runtime repo as a sibling of the binding repo. You can also clone `mmtk-core` to a local path. Using a local repo of `mmtk-core` can be beneficial to your development in case you need to make certain changes to the core (though this is unlikely).
 
@@ -107,7 +111,7 @@ We recommend going through the [list of constants in the documentation](https://
 Now that we have most of the boilerplate set up, the next step is to initialize MMTk so that we can start allocating objects.
 
 ### Runtime-side changes
-Create a `mmtk.h` header file in the runtime folder of the binding (i.e. `mmtk-X/X`) which exposes the functions required to implement NoGC and `#include` it in the relevant runtime code. You can use the [DummyVM `mmtk.h` header file](https://github.com/mmtk/mmtk-core/blob/master/vmbindings/dummyvm/api/mmtk.h) as an example.
+Create a `mmtk.h` header file in the runtime folder of the binding (i.e. `mmtk-X/X`) which exposes the functions required to implement NoGC and `#include` it in the relevant runtime code. You can use the [example `mmtk.h` header file](https://github.com/mmtk/mmtk-core/blob/master/docs/header/mmtk.h) as an example.
 
 **Note:** It is convention to prefix all MMTk API functions exposed with `mmtk_` in order to avoid name clashes. It is *highly* recommended that you follow this convention.