chore: add comment and remove dbg trace message

.gitattributes

@@ -1,6 +1,3 @@
-*.lean text eol=lf
 *.expected.out -text
 RELEASES.md merge=union
 stage0/** binary linguist-generated
-# The following file is often manually edited, so do show it in diffs
-stage0/src/stdlib_flags.h -binary -linguist-generated

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,30 @@
+### Prerequisites
+
+* [ ] Put an X between the brackets on this line if you have done all of the following:
+    * Checked that your issue isn't already [filed](https://github.com/leanprover/lean4/issues).
+    * Reduced the issue to a self-contained, reproducible test case.
+
+### Description
+
+[Description of the issue]
+
+### Steps to Reproduce
+
+1. [First Step]
+2. [Second Step]
+3. [and so on...]
+
+**Expected behavior:** [What you expect to happen]
+
+**Actual behavior:** [What actually happens]
+
+**Reproduces how often:** [What percentage of the time does it reproduce?]
+
+### Versions
+
+You can get this information from copy and pasting the output of `lean --version`,
+please include the OS and what version of the OS you're running.
+
+### Additional Information
+
+Any additional information, configuration or data that might be necessary to reproduce the issue.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,51 +0,0 @@
----
-name: Bug report
-about: Create a bug report
-title: ''
-labels: bug
-assignees: ''
-
----
-
-### Prerequisites
-
-Please put an X between the brackets as you perform the following steps:
-
-* [ ] Check that your issue is not already filed:
-      https://github.com/leanprover/lean4/issues
-* [ ] Reduce the issue to a minimal, self-contained, reproducible test case.
-      Avoid dependencies to Mathlib or Batteries.
-* [ ] Test your test case against the latest nightly release, for example on
-      https://live.lean-lang.org/#project=lean-nightly
-      (You can also use the settings there to switch to “Lean nightly”)
-
-### Description
-
-[Clear and concise description of the issue]
-
-### Context
-
-[Broader context that the issue occurred in. If there was any prior discussion on [the Lean Zulip](https://leanprover.zulipchat.com), link it here as well.]
-
-### Steps to Reproduce
-
-1.
-2.
-3.
-
-**Expected behavior:** [Clear and concise description of what you expect to happen]
-
-**Actual behavior:** [Clear and concise description of what actually happens]
-
-### Versions
-
-[Output of `#version` or `#eval Lean.versionString`]
-[OS version, if not using live.lean-lang.org.]
-
-### Additional Information
-
-[Additional information, configuration or data that might be necessary to reproduce the issue]
-
-### Impact
-
-Add :+1: to [issues you consider important](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc). If others are impacted by this issue, please ask them to add :+1: to it.

.github/ISSUE_TEMPLATE/rfc.md

@@ -1,26 +0,0 @@
----
-name: Request for comments
-about: Create a feature proposal
-title: 'RFC: '
-labels: RFC
-assignees: ''
-
----
-
-### Proposal
-
-Clear and detailed description of the proposal. Consider the following questions:
-
-  - **User Experience**: How does this feature improve the user experience?
-
-  - **Beneficiaries**: Which Lean users and projects benefit most from this feature/change?
-
-  - **Maintainability**: Will this change streamline code maintenance or simplify its structure?
-
-### Community Feedback
-
-Ideas should be discussed on [the Lean Zulip](https://leanprover.zulipchat.com) prior to submitting a proposal. Summarize all prior discussions and link them here.
-
-### Impact
-
-Add :+1: to [issues you consider important](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc). If others benefit from the changes in this proposal being added, please ask them to add :+1: to it.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,21 +0,0 @@
-# Read this section before submitting
-
-* Ensure your PR follows the [External Contribution Guidelines](https://github.com/leanprover/lean4/blob/master/CONTRIBUTING.md).
-* Please make sure the PR has excellent documentation and tests. If we label it `missing documentation` or `missing tests` then it needs fixing!
-* Include the link to your `RFC` or `bug` issue in the description.
-* If the issue does not already have approval from a developer, submit the PR as draft.
-* The PR title/description will become the commit message. Keep it up-to-date as the PR evolves.
-* For `feat/fix` PRs, the first paragraph starting with "This PR" must be present and will become a
-  changelog entry unless the PR is labeled with `no-changelog`. If the PR does not have this label,
-  it must instead be categorized with one of the `changelog-*` labels (which will be done by a
-  reviewer for external PRs).
-* A toolchain of the form `leanprover/lean4-pr-releases:pr-release-NNNN` for Linux and M-series Macs will be generated upon build. To generate binaries for Windows and Intel-based Macs as well, write a comment containing `release-ci` on its own line.
-* If you rebase your PR onto `nightly-with-mathlib` then CI will test Mathlib against your PR.
-* You can manage the `awaiting-review`, `awaiting-author`, and `WIP` labels yourself, by writing a comment containing one of these labels on its own line.
-* Remove this section, up to and including the `---` before submitting.
-
----
-
-This PR <short changelog summary for feat/fix, see above>.
-
-Closes <`RFC` or `bug` issue number fixed by this PR, if any>

.github/dependabot.yml

@@ -1,8 +0,0 @@
-version: 2
-updates:
-  - package-ecosystem: "github-actions"
-    directory: "/"
-    schedule:
-      interval: "monthly"
-    commit-message:
-      prefix: "chore: CI"

.github/workflows/actionlint.yml

@@ -1,22 +0,0 @@
-name: Actionlint
-on:
-  push:
-    branches:
-      - 'master'
-    paths:
-      - '.github/**'
-  pull_request:
-    paths:
-      - '.github/**'
-  merge_group:
-
-jobs:
-  actionlint:
-    runs-on: ubuntu-latest
-    steps:
-    - name: Checkout
-      uses: actions/checkout@v4
-    - name: actionlint
-      uses: raven-actions/actionlint@v2
-      with:
-        pyflakes: false # we do not use python scripts

.github/workflows/backport.yml

@@ -1,26 +0,0 @@
-name: Backport
-on:
-  pull_request_target:
-    types:
-      - closed
-      - labeled
-
-jobs:
-  backport:
-    name: Backport
-    runs-on: ubuntu-latest
-    # Only react to merged PRs for security reasons.
-    # See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target.
-    if: >
-      github.event.pull_request.merged
-      && (
-        github.event.action == 'closed'
-        || (
-          github.event.action == 'labeled'
-          && contains(github.event.label.name, 'backport')
-        )
-      )
-    steps:
-      - uses: tibdex/backport@v2
-        with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/check-prelude.yml

@@ -1,29 +0,0 @@
-name: Check for modules that should use `prelude`
-
-on: [pull_request]
-
-jobs:
-  check-prelude:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          # the default is to use a virtual merge commit between the PR and master: just use the PR
-          ref: ${{ github.event.pull_request.head.sha }}
-          sparse-checkout: |
-            src/Lean
-            src/Std
-            src/lake/Lake
-      - name: Check Prelude
-        run: |
-          failed_files=""
-          while IFS= read -r -d '' file; do
-            if ! grep -q "^prelude$" "$file"; then
-              failed_files="$failed_files$file\n"
-            fi
-          done < <(find src/Lean src/Std src/lake/Lake -name '*.lean' -print0)
-          if [ -n "$failed_files" ]; then
-            echo -e "The following files should use 'prelude':\n$failed_files"
-            exit 1
-          fi

.github/workflows/check-stage0.yml

@@ -1,57 +0,0 @@
-name: Check for stage0 changes
-
-on:
-  merge_group:
-  pull_request:
-
-jobs:
-  check-stage0-on-queue:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-      with:
-        ref: ${{ github.event.pull_request.head.sha }}
-        filter: blob:none
-        fetch-depth: 0
-
-    - name: Find base commit
-      if: github.event_name == 'pull_request'
-      run: echo "BASE=$(git merge-base origin/${{ github.base_ref }} HEAD)" >> "$GITHUB_ENV"
-
-    - name: Identify stage0 changes
-      run: |
-        git diff "${BASE:-HEAD^}..HEAD" --name-only -- stage0 |
-          grep -v -x -F $'stage0/src/stdlib_flags.h\nstage0/src/lean.mk.in' \
-          > "$RUNNER_TEMP/stage0" || true
-        if test -s "$RUNNER_TEMP/stage0"
-        then
-          echo "CHANGES=yes" >> "$GITHUB_ENV"
-        else
-          echo "CHANGES=no" >> "$GITHUB_ENV"
-        fi
-      shell: bash
-
-    - if: github.event_name == 'pull_request'
-      name: Set label
-      uses: actions/github-script@v7
-      with:
-        script: |
-          const { owner, repo, number: issue_number  } = context.issue;
-          if (process.env.CHANGES == 'yes') {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['changes-stage0'] }).catch(() => {});
-          } else {
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'changes-stage0' }).catch(() => {});
-          }
-
-    - if: env.CHANGES == 'yes'
-      name: Report changes
-      run: |
-        echo "Found changes to stage0/, please do not merge using the merge queue." | tee "$GITHUB_STEP_SUMMARY"
-        # shellcheck disable=SC2129
-        echo '```'                  >> "$GITHUB_STEP_SUMMARY"
-        cat  "$RUNNER_TEMP/stage0"  >> "$GITHUB_STEP_SUMMARY"
-        echo '```'                  >> "$GITHUB_STEP_SUMMARY"
-
-    - if: github.event_name == 'merge_group' && env.CHANGES == 'yes'
-      name: Fail when on the merge queue
-      run: exit 1

.github/workflows/ci.yml

@@ -6,275 +6,85 @@ on:
     tags:
       - '*'
   pull_request:
-  merge_group:
+    branches:
+      - master
   schedule:
     - cron: '0 7 * * *'  # 8AM CET/11PM PT
-  # for manual re-release of a nightly
-  workflow_dispatch:
-    inputs:
-      action:
-        description: 'Action'
-        required: true
-        default: 'release nightly'
-        type: choice
-        options:
-        - release nightly
-
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }}
-  cancel-in-progress: true
 
 jobs:
-
-  # This job determines various settings for the following CI runs; see the `outputs` for details
-  configure:
+  set-nightly:
+    # don't schedule nightlies on forks
+    if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4'
     runs-on: ubuntu-latest
     outputs:
-      # 0: PRs without special label
-      # 1: PRs with `merge-ci` label, merge queue checks, master commits
-      # 2: PRs with `release-ci` label, releases (incl. nightlies)
-      check-level: ${{ steps.set-level.outputs.check-level }}
-      # The build matrix, dynamically generated here
-      matrix: ${{ steps.set-matrix.outputs.result }}
-      # Should we make a nightly release? If so, this output contains the lean version string, else it is empty
-      nightly: ${{ steps.set-nightly.outputs.nightly }}
-      # Should this be the CI for a tagged release?
-      # Yes only if a tag is pushed to the `leanprover` repository, and the tag is "v" followed by a valid semver.
-      # It sets `set-release.outputs.RELEASE_TAG` to the tag
-      # and sets `set-release.outputs.{LEAN_VERSION_MAJOR,LEAN_VERSION_MINOR,LEAN_VERSION_PATCH,LEAN_SPECIAL_VERSION_DESC}`
-      # to the semver components parsed via regex.
-      LEAN_VERSION_MAJOR: ${{ steps.set-release.outputs.LEAN_VERSION_MAJOR }}
-      LEAN_VERSION_MINOR: ${{ steps.set-release.outputs.LEAN_VERSION_MINOR }}
-      LEAN_VERSION_PATCH: ${{ steps.set-release.outputs.LEAN_VERSION_PATCH }}
-      LEAN_SPECIAL_VERSION_DESC: ${{ steps.set-release.outputs.LEAN_SPECIAL_VERSION_DESC }}
-      RELEASE_TAG: ${{ steps.set-release.outputs.RELEASE_TAG }}
-
+      nightly: ${{ steps.set.outputs.nightly }}
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
-        # don't schedule nightlies on forks
-        if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4' || inputs.action == 'release nightly'
+        uses: actions/checkout@v2
       - name: Set Nightly
-        if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4' || inputs.action == 'release nightly'
-        id: set-nightly
+        id: set
         run: |
           if [[ -n '${{ secrets.PUSH_NIGHTLY_TOKEN }}' ]]; then
             git remote add nightly https://foo:'${{ secrets.PUSH_NIGHTLY_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-nightly.git
             git fetch nightly --tags
             LEAN_VERSION_STRING="nightly-$(date -u +%F)"
             # do nothing if commit already has a different tag
-            if [[ "$(git name-rev --name-only --tags --no-undefined HEAD 2> /dev/null || echo "$LEAN_VERSION_STRING")" == "$LEAN_VERSION_STRING" ]]; then
-              echo "nightly=$LEAN_VERSION_STRING" >> "$GITHUB_OUTPUT"
+            if [[ $(git name-rev --name-only --tags --no-undefined HEAD 2> /dev/null || echo $LEAN_VERSION_STRING) == $LEAN_VERSION_STRING ]]; then
+              echo "::set-output name=nightly::$LEAN_VERSION_STRING"
             fi
           fi
 
-      - name: Check for official release
-        if: startsWith(github.ref, 'refs/tags/') && github.repository == 'leanprover/lean4'
-        id: set-release
-        run: |
-          TAG_NAME="${GITHUB_REF##*/}"
-
-          # From https://github.com/fsaintjacques/semver-tool/blob/master/src/semver
-
-          NAT='0|[1-9][0-9]*'
-          ALPHANUM='[0-9]*[A-Za-z-][0-9A-Za-z-]*'
-          IDENT="$NAT|$ALPHANUM"
-          FIELD='[0-9A-Za-z-]+'
-
-          SEMVER_REGEX="\
-          ^[vV]?\
-          ($NAT)\\.($NAT)\\.($NAT)\
-          (\\-(${IDENT})(\\.(${IDENT}))*)?\
-          (\\+${FIELD}(\\.${FIELD})*)?$"
-
-          if [[ ${TAG_NAME} =~ ${SEMVER_REGEX} ]]; then
-            echo "Tag ${TAG_NAME} matches SemVer regex, with groups ${BASH_REMATCH[1]} ${BASH_REMATCH[2]} ${BASH_REMATCH[3]} ${BASH_REMATCH[4]}"
-            {
-              echo "LEAN_VERSION_MAJOR=${BASH_REMATCH[1]}"
-              echo "LEAN_VERSION_MINOR=${BASH_REMATCH[2]}"
-              echo "LEAN_VERSION_PATCH=${BASH_REMATCH[3]}"
-              echo "LEAN_SPECIAL_VERSION_DESC=${BASH_REMATCH[4]##-}"
-              echo "RELEASE_TAG=$TAG_NAME"
-            } >> "$GITHUB_OUTPUT"
-          else
-            echo "Tag ${TAG_NAME} did not match SemVer regex."
-          fi
-
-      - name: Set check level
-        id: set-level
-        # We do not use github.event.pull_request.labels.*.name here because
-        # re-running a run does not update that list, and we do want to be able to
-        # rerun the workflow run after setting the `release-ci`/`merge-ci` labels.
-        run: |
-          check_level=0
-
-          if [[ -n "${{ steps.set-nightly.outputs.nightly }}" || -n "${{ steps.set-release.outputs.RELEASE_TAG }}" ]]; then
-            check_level=2
-          elif [[ "${{ github.event_name }}" != "pull_request" ]]; then
-            check_level=1
-          else
-            labels="$(gh api repos/${{ github.repository_owner }}/${{ github.event.repository.name }}/pulls/${{ github.event.pull_request.number }} --jq '.labels')"
-            if echo "$labels" | grep -q "release-ci"; then
-              check_level=2
-            elif echo "$labels" | grep -q "merge-ci"; then
-              check_level=1
-            fi
-          fi
-
-          echo "check-level=$check_level" >> "$GITHUB_OUTPUT"
-        env:
-          GH_TOKEN: ${{ github.token }}
-
-      - name: Configure build matrix
-        id: set-matrix
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const level = ${{ steps.set-level.outputs.check-level }};
-            console.log(`level: ${level}`);
-            // use large runners where available (original repo)
-            let large = ${{ github.repository == 'leanprover/lean4' }};
-            let matrix = [
-              {
-                // portable release build: use channel with older glibc (2.27)
-                "name": "Linux LLVM",
-                "os": "ubuntu-latest",
-                "release": false,
-                "check-level": 2,
-                "shell": "nix develop .#oldGlibc -c bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-x86_64-linux-gnu.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-linux.sh lean-llvm*",
-                "binary-check": "ldd -v",
-                // foreign code may be linked against more recent glibc
-                // reverse-ffi needs to be updated to link to LLVM libraries
-                "CTEST_OPTIONS": "-E 'foreign|leanlaketest_reverse-ffi'",
-                "CMAKE_OPTIONS": "-DLLVM=ON -DLLVM_CONFIG=${GITHUB_WORKSPACE}/build/llvm-host/bin/llvm-config"
-              },
-              {
-                "name": "Linux release",
-                "os": large ? "nscloud-ubuntu-22.04-amd64-4x8" : "ubuntu-latest",
-                "release": true,
-                "check-level": 0,
-                "shell": "nix develop .#oldGlibc -c bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-x86_64-linux-gnu.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-linux.sh lean-llvm*",
-                "binary-check": "ldd -v",
-                // foreign code may be linked against more recent glibc
-                "CTEST_OPTIONS": "-E 'foreign'"
-              },
-              {
-                "name": "Linux",
-                "os": large ? "nscloud-ubuntu-22.04-amd64-4x8" : "ubuntu-latest",
-                "check-stage3": level >= 2,
-                "test-speedcenter": level >= 2,
-                "check-level": 1,
-              },
-              {
-                "name": "Linux Debug",
-                "os": "ubuntu-latest",
-                "check-level": 2,
-                "CMAKE_PRESET": "debug",
-                // exclude seriously slow tests
-                "CTEST_OPTIONS": "-E 'interactivetest|leanpkgtest|laketest|benchtest|bv_bitblast_stress'"
-              },
-              // TODO: suddenly started failing in CI
-              /*{
-                "name": "Linux fsanitize",
-                "os": "ubuntu-latest",
-                "check-level": 2,
-                // turn off custom allocator & symbolic functions to make LSAN do its magic
-                "CMAKE_PRESET": "sanitize",
-                // exclude seriously slow/problematic tests (laketests crash)
-                "CTEST_OPTIONS": "-E 'interactivetest|leanpkgtest|laketest|benchtest'"
-              },*/
-              {
-                "name": "macOS",
-                "os": "macos-13",
-                "release": true,
-                "check-level": 2,
-                "shell": "bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-x86_64-apple-darwin.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-macos.sh lean-llvm*",
-                "binary-check": "otool -L",
-                "tar": "gtar" // https://github.com/actions/runner-images/issues/2619
-              },
-              {
-                "name": "macOS aarch64",
-                "os": "macos-14",
-                "CMAKE_OPTIONS": "-DLEAN_INSTALL_SUFFIX=-darwin_aarch64",
-                "release": true,
-                "check-level": 0,
-                "shell": "bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-aarch64-apple-darwin.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-macos.sh lean-llvm*",
-                "binary-check": "otool -L",
-                "tar": "gtar" // https://github.com/actions/runner-images/issues/2619
-              },
-              {
-                "name": "Windows",
-                "os": "windows-2022",
-                "release": true,
-                "check-level": 2,
-                "shell": "msys2 {0}",
-                "CMAKE_OPTIONS": "-G \"Unix Makefiles\"",
-                // for reasons unknown, interactivetests are flaky on Windows
-                "CTEST_OPTIONS": "--repeat until-pass:2",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-x86_64-w64-windows-gnu.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-mingw.sh lean-llvm*",
-                "binary-check": "ldd"
-              },
-              {
-                "name": "Linux aarch64",
-                "os": "nscloud-ubuntu-22.04-arm64-4x8",
-                "CMAKE_OPTIONS": "-DLEAN_INSTALL_SUFFIX=-linux_aarch64",
-                "release": true,
-                "check-level": 2,
-                "shell": "nix develop .#oldGlibcAArch -c bash -euxo pipefail {0}",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-aarch64-linux-gnu.tar.zst",
-                "prepare-llvm": "../script/prepare-llvm-linux.sh lean-llvm*"
-              },
-              {
-                "name": "Linux 32bit",
-                "os": "ubuntu-latest",
-                // Use 32bit on stage0 and stage1 to keep oleans compatible
-                "CMAKE_OPTIONS": "-DSTAGE0_USE_GMP=OFF -DSTAGE0_LEAN_EXTRA_CXX_FLAGS='-m32' -DSTAGE0_LEANC_OPTS='-m32' -DSTAGE0_MMAP=OFF -DUSE_GMP=OFF -DLEAN_EXTRA_CXX_FLAGS='-m32' -DLEANC_OPTS='-m32' -DMMAP=OFF -DLEAN_INSTALL_SUFFIX=-linux_x86 -DCMAKE_LIBRARY_PATH=/usr/lib/i386-linux-gnu/ -DSTAGE0_CMAKE_LIBRARY_PATH=/usr/lib/i386-linux-gnu/",
-                "cmultilib": true,
-                "release": true,
-                "check-level": 2,
-                "cross": true,
-                "shell": "bash -euxo pipefail {0}"
-              },
-              {
-                "name": "Web Assembly",
-                "os": "ubuntu-latest",
-                // Build a native 32bit binary in stage0 and use it to compile the oleans and the wasm build
-                "CMAKE_OPTIONS": "-DCMAKE_C_COMPILER_WORKS=1 -DSTAGE0_USE_GMP=OFF -DSTAGE0_LEAN_EXTRA_CXX_FLAGS='-m32' -DSTAGE0_LEANC_OPTS='-m32' -DSTAGE0_CMAKE_CXX_COMPILER=clang++ -DSTAGE0_CMAKE_C_COMPILER=clang -DSTAGE0_CMAKE_EXECUTABLE_SUFFIX=\"\" -DUSE_GMP=OFF -DMMAP=OFF -DSTAGE0_MMAP=OFF -DCMAKE_AR=../emsdk/emsdk-main/upstream/emscripten/emar -DCMAKE_TOOLCHAIN_FILE=../emsdk/emsdk-main/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake -DLEAN_INSTALL_SUFFIX=-linux_wasm32 -DSTAGE0_CMAKE_LIBRARY_PATH=/usr/lib/i386-linux-gnu/",
-                "wasm": true,
-                "cmultilib": true,
-                "release": true,
-                "check-level": 2,
-                "cross": true,
-                "shell": "bash -euxo pipefail {0}",
-                // Just a few selected tests because wasm is slow
-                "CTEST_OPTIONS": "-R \"leantest_1007\\.lean|leantest_Format\\.lean|leanruntest\\_1037.lean|leanruntest_ac_rfl\\.lean|leanruntest_tempfile.lean\\.|leanruntest_libuv\\.lean\""
-              }
-            ];
-            console.log(`matrix:\n${JSON.stringify(matrix, null, 2)}`)
-            return matrix.filter((job) => level >= job["check-level"])
-
   build:
-    needs: [configure]
-    if: github.event_name != 'schedule' || github.repository == 'leanprover/lean4'
-    strategy:
-      matrix:
-        include: ${{fromJson(needs.configure.outputs.matrix)}}
-      # complete all jobs
-      fail-fast: false
+    needs: set-nightly
+    if: always()
     runs-on: ${{ matrix.os }}
     defaults:
       run:
-        shell: ${{ matrix.shell || 'nix develop -c bash -euxo pipefail {0}' }}
+        shell: ${{ matrix.shell || 'nix-shell --run "bash -euxo pipefail {0}"' }}
+    strategy:
+      matrix:
+        include:
+          # portable release build: use channel with older glibc (2.27)
+          - name: Linux release
+            os: ubuntu-latest
+            release: true
+            shell: nix-shell --arg pkgsDist "import (fetchTarball \"channel:nixos-19.03\") {{}}" --run "bash -euxo pipefail {0}"
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/13.0.0/lean-llvm-x86_64-linux-gnu.tar.zst
+            prepare-llvm: script/prepare-llvm-linux.sh lean-llvm*
+            binary-check: ldd -v
+          - name: Linux
+            os: ubuntu-latest
+            check-stage3: true
+            test-speedcenter: true
+          - name: Linux Debug
+            os: ubuntu-latest
+            CMAKE_OPTIONS: -DCMAKE_BUILD_TYPE=Debug
+          - name: Linux fsanitize
+            os: ubuntu-latest
+            # turn off custom allocator & symbolic functions to make LSAN do its magic
+            CMAKE_OPTIONS: -DLEAN_EXTRA_CXX_FLAGS=-fsanitize=address,undefined -DLEANC_EXTRA_FLAGS='-fsanitize=address,undefined -fsanitize-link-c++-runtime' -DSMALL_ALLOCATOR=OFF -DBSYMBOLIC=OFF
+            # exclude problematic tests
+            CTEST_OPTIONS: -E laketest
+          - name: macOS
+            os: macos-latest
+            release: true
+            shell: bash -euxo pipefail {0}
+            CMAKE_OPTIONS: -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/13.0.0/lean-llvm-x86_64-apple-darwin.tar.zst
+            prepare-llvm: script/prepare-llvm-macos.sh lean-llvm*
+            binary-check: otool -L
+          - name: Windows
+            os: windows-2022
+            release: true
+            shell: msys2 {0}
+            CMAKE_OPTIONS: -G "Unix Makefiles"
+            # for reasons unknown, interactivetests are flaky on Windows
+            CTEST_OPTIONS: --repeat until-pass:2
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/13.0.0/lean-llvm-x86_64-w64-windows-gnu.tar.zst
+            prepare-llvm: script/prepare-llvm-mingw.sh lean-llvm*
+            binary-check: ldd
+      # complete all jobs
+      fail-fast: false
     name: ${{ matrix.name }}
     env:
       # must be inside workspace
@@ -285,125 +95,69 @@ jobs:
       # squelch error message about missing nixpkgs channel
       NIX_BUILD_SHELL: bash
       LSAN_OPTIONS: max_leaks=10
-      # somehow MinGW clang64 (or cmake?) defaults to `g++` even though it doesn't exist
-      CXX: c++
-      MACOSX_DEPLOYMENT_TARGET: 10.15
     steps:
+      - name: Checkout
+        uses: actions/checkout@v2
+        with:
+          submodules: true
       - name: Install Nix
-        uses: DeterminateSystems/nix-installer-action@main
-        if: runner.os == 'Linux' && !matrix.cmultilib
+        uses: cachix/install-nix-action@v15
+        if: matrix.os == 'ubuntu-latest'
       - name: Install MSYS2
         uses: msys2/setup-msys2@v2
         with:
           msystem: clang64
-          # `:` means do not prefix with msystem
-          pacboy: "make: python: cmake clang ccache gmp libuv git: zip: unzip: diffutils: binutils: tree: zstd tar:"
-        if: runner.os == 'Windows'
+          install: make python mingw-w64-clang-x86_64-cmake mingw-w64-clang-x86_64-clang mingw-w64-clang-x86_64-ccache git zip unzip diffutils binutils tree mingw-w64-clang-x86_64-zstd tar
+        if: matrix.os == 'windows-2022'
       - name: Install Brew Packages
         run: |
-          brew install ccache tree zstd coreutils gmp libuv
-        if: runner.os == 'macOS'
-      - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          # the default is to use a virtual merge commit between the PR and master: just use the PR
-          ref: ${{ github.event.pull_request.head.sha }}
-      # Do check out some CI-relevant files from virtual merge commit to accommodate CI changes on
-      # master (as the workflow files themselves are always taken from the merge)
-      # (needs to be after "Install *" to use the right shell)
-      - name: CI Merge Checkout
-        run: |
-          git fetch --depth=1 origin ${{ github.sha }}
-          git checkout FETCH_HEAD flake.nix flake.lock
-        if: github.event_name == 'pull_request'
-      # (needs to be after "Checkout" so files don't get overridden)
-      - name: Setup emsdk
-        uses: mymindstorm/setup-emsdk@v14
-        with:
-          version: 3.1.44
-          actions-cache-folder: emsdk
-        if: matrix.wasm
-      - name: Install 32bit c libs
-        run: |
-          sudo dpkg --add-architecture i386
-          sudo apt-get update
-          sudo apt-get install -y gcc-multilib g++-multilib ccache libuv1-dev:i386
-        if: matrix.cmultilib
+          brew install ccache tree zstd coreutils
+        if: matrix.os == 'macos-latest'
       - name: Cache
-        uses: actions/cache@v4
+        uses: actions/cache@v2
         with:
           path: .ccache
-          key: ${{ matrix.name }}-build-v3-${{ github.event.pull_request.head.sha }}
+          key: ${{ matrix.name }}-build-${{ github.sha }}
           # fall back to (latest) previous cache
           restore-keys: |
-            ${{ matrix.name }}-build-v3
-          save-always: true
-      # open nix-shell once for initial setup
+            ${{ matrix.name }}-build
       - name: Setup
         run: |
-          ccache --zero-stats
-        if: runner.os == 'Linux'
-      - name: Set up NPROC
-        run: |
-          echo "NPROC=$(nproc 2>/dev/null || sysctl -n hw.logicalcpu 2>/dev/null || echo 4)" >> $GITHUB_ENV
+          # open nix-shell once for initial setup
+          true
+        if: matrix.os == 'ubuntu-latest'
       - name: Build
         run: |
           mkdir build
           cd build
-          # arguments passed to `cmake`
-          # this also enables githash embedding into stage 1 library
-          OPTIONS=(-DCHECK_OLEAN_VERSION=ON)
-          OPTIONS+=(-DLEAN_EXTRA_MAKE_OPTS=-DwarningAsError=true)
-          if [[ -n '${{ matrix.cross_target }}' ]]; then
-            # used by `prepare-llvm`
-            export EXTRA_FLAGS=--target=${{ matrix.cross_target }}
-            OPTIONS+=(-DLEAN_PLATFORM_TARGET=${{ matrix.cross_target }})
-          fi
-          if [[ -n '${{ matrix.prepare-llvm }}' ]]; then
-            wget -q ${{ matrix.llvm-url }}
-            PREPARE="$(${{ matrix.prepare-llvm }})"
-            eval "OPTIONS+=($PREPARE)"
-          fi
-          if [[ -n '${{ matrix.release }}' && -n '${{ needs.configure.outputs.nightly }}' ]]; then
-            OPTIONS+=(-DLEAN_SPECIAL_VERSION_DESC=${{ needs.configure.outputs.nightly }})
-          fi
-          if [[ -n '${{ matrix.release }}' && -n '${{ needs.configure.outputs.RELEASE_TAG }}' ]]; then
-            OPTIONS+=(-DLEAN_VERSION_MAJOR=${{ needs.configure.outputs.LEAN_VERSION_MAJOR }})
-            OPTIONS+=(-DLEAN_VERSION_MINOR=${{ needs.configure.outputs.LEAN_VERSION_MINOR }})
-            OPTIONS+=(-DLEAN_VERSION_PATCH=${{ needs.configure.outputs.LEAN_VERSION_PATCH }})
-            OPTIONS+=(-DLEAN_VERSION_IS_RELEASE=1)
-            OPTIONS+=(-DLEAN_SPECIAL_VERSION_DESC=${{ needs.configure.outputs.LEAN_SPECIAL_VERSION_DESC }})
+          OPTIONS=()
+          [[ -z '${{ matrix.llvm-url }}' ]] || wget -q ${{ matrix.llvm-url }}
+          [[ -z '${{ matrix.prepare-llvm }}' ]] || eval "OPTIONS+=($(../${{ matrix.prepare-llvm }}))"
+          if [[ -n '${{ matrix.release }}' && -n '${{ needs.set-nightly.outputs.nightly }}' ]]; then
+            OPTIONS+=(-DLEAN_SPECIAL_VERSION_DESC=${{ needs.set-nightly.outputs.nightly }})
           fi
           # contortion to support empty OPTIONS with old macOS bash
-          cmake .. --preset ${{ matrix.CMAKE_PRESET || 'release' }} -B . ${{ matrix.CMAKE_OPTIONS }} ${OPTIONS[@]+"${OPTIONS[@]}"} -DLEAN_INSTALL_PREFIX=$PWD/..
-          time make -j$NPROC
-      - name: Install
-        run: |
-          make -C build install
+          cmake .. ${{ matrix.CMAKE_OPTIONS }} ${OPTIONS[@]+"${OPTIONS[@]}"} -DLEAN_INSTALL_PREFIX=$PWD/..
+          make -j4
+          make install
       - name: Check Binaries
         run: ${{ matrix.binary-check }} lean-*/bin/* || true
-      - name: Count binary symbols
-        run: |
-          for f in lean-*/bin/*; do
-            echo "$f: $(nm $f | grep " T " | wc -l) exported symbols"
-          done
-        if: matrix.name == 'Windows'
       - name: List Install Tree
         run: |
           # omit contents of Init/, ...
-          tree --du -h lean-*-* | grep -E ' (Init|Lean|Lake|LICENSE|[a-z])'
+          tree --du -h lean-* | grep -E ' (Init|Std|Lean|Lake|LICENSE|[a-z])'
       - name: Pack
         run: |
-          dir=$(echo lean-*-*)
+          dir=$(echo lean-*)
           mkdir pack
           # high-compression tar.zst + zip for release, fast tar.zst otherwise
-          if [[ '${{ startsWith(github.ref, 'refs/tags/') && matrix.release }}' == true || -n '${{ needs.configure.outputs.nightly }}' || -n '${{ needs.configure.outputs.RELEASE_TAG }}' ]]; then
-            ${{ matrix.tar || 'tar' }} cf - $dir | zstd -T0 --no-progress -19 -o pack/$dir.tar.zst
+          if [[ '${{ startsWith(github.ref, 'refs/tags/v') && matrix.release }}' == true || -n '${{ needs.set-nightly.outputs.nightly }}' ]]; then
+            tar cf - $dir | zstd -T0 --no-progress -19 -o pack/$dir.tar.zst
             zip -rq pack/$dir.zip $dir
           else
-            ${{ matrix.tar || 'tar' }} cf - $dir | zstd -T0 --no-progress -o pack/$dir.tar.zst
+            tar cf - $dir | zstd -T0 --no-progress -o pack/$dir.tar.zst
           fi
-      - uses: actions/upload-artifact@v4
+      - uses: actions/upload-artifact@v2
         if: matrix.release
         with:
           name: build-${{ matrix.name }}
@@ -411,148 +165,87 @@ jobs:
       - name: Lean stats
         run: |
           build/stage1/bin/lean --stats src/Lean.lean
-        if: ${{ !matrix.cross }}
       - name: Test
-        id: test
         run: |
-          time ctest --preset ${{ matrix.CMAKE_PRESET || 'release' }} --test-dir build/stage1 -j$NPROC --output-junit test-results.xml ${{ matrix.CTEST_OPTIONS }}
-        if: (matrix.wasm || !matrix.cross) && needs.configure.outputs.check-level >= 1
-      - name: Test Summary
-        uses: test-summary/action@v2
-        with:
-          paths: build/stage1/test-results.xml
-        # prefix `if` above with `always` so it's run even if tests failed
-        if: always() && steps.test.conclusion != 'skipped'
+          cd build/stage1
+          ctest -j4 --output-on-failure ${{ matrix.CTEST_OPTIONS }} < /dev/null
       - name: Check Test Binary
         run: ${{ matrix.binary-check }} tests/compiler/534.lean.out
-        if: (!matrix.cross) && steps.test.conclusion != 'skipped'
       - name: Build Stage 2
         run: |
-          make -C build -j$NPROC stage2
-        if: matrix.test-speedcenter
+          cd build
+          make -j4 stage2
+        if: matrix.build-stage2 || matrix.check-stage3
       - name: Check Stage 3
         run: |
-          make -C build -j$NPROC check-stage3
-        if: matrix.test-speedcenter
+          cd build
+          make -j4 check-stage3
+        if: matrix.check-stage3
       - name: Test Speedcenter Benchmarks
         run: |
-          # Necessary for some timing metrics but does not work on Namespace runners
-          # and we just want to test that the benchmarks run at all here
-          #echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
+          echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
           export BUILD=$PWD/build PATH=$PWD/build/stage1/bin:$PATH
-          cd tests/bench
-          nix shell .#temci -c temci exec --config speedcenter.yaml --included_blocks fast --runs 1
+          nix-shell -A with-temci --run "cd tests/bench; temci exec --config speedcenter.yaml --included_blocks fast --runs 1"
         if: matrix.test-speedcenter
       - name: Check rebootstrap
         run: |
-          # clean rebuild in case of Makefile changes
-          make -C build update-stage0 && rm -rf build/stage* && make -C build -j$NPROC
-        if: matrix.name == 'Linux' && needs.configure.outputs.check-level >= 1
+          cd build
+          make update-stage0 && make -j4
+        if: matrix.name == 'Linux'
       - name: CCache stats
         run: ccache -s
-
-  # This job collects results from all the matrix jobs
-  # This can be made the "required" job, instead of listing each
-  # matrix job separately
-  all-done:
-    name: Build matrix complete
-    runs-on: ubuntu-latest
-    needs: build
-    # mark as merely cancelled not failed if builds are cancelled
-    if: ${{ !cancelled() }}
-    steps:
-    - if: ${{ contains(needs.*.result, 'failure') && github.repository == 'leanprover/lean4' && github.ref_name == 'master' }}
-      uses: zulip/github-actions-zulip/send-message@v1
-      with:
-        api-key: ${{ secrets.ZULIP_BOT_KEY }}
-        email: "github-actions-bot@lean-fro.zulipchat.com"
-        organization-url: "https://lean-fro.zulipchat.com"
-        to: "infrastructure"
-        topic: "Github actions"
-        type: "stream"
-        content: |
-          A build of `${{ github.ref_name }}`, triggered by event `${{ github.event_name }}`, [failed](https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}).
-    - if: contains(needs.*.result, 'failure')
-      uses: actions/github-script@v7
-      with:
-        script: |
-            core.setFailed('Some jobs failed')
-
-
-  # This job creates releases from tags
-  # (whether they are "unofficial" releases for experiments, or official releases when the tag is "v" followed by a semver string.)
-  # We do not attempt to automatically construct a changelog here:
-  # unofficial releases don't need them, and official release notes will be written by a human.
+        
   release:
-    if: startsWith(github.ref, 'refs/tags/')
+    if: ${{ startsWith(github.ref, 'refs/tags/v') }}
     runs-on: ubuntu-latest
     needs: build
     steps:
-      - uses: actions/download-artifact@v4
+      - uses: actions/download-artifact@v2
         with:
           path: artifacts
       - name: Release
-        uses: softprops/action-gh-release@v2
+        uses: softprops/action-gh-release@v1       
         with:
           files: artifacts/*/*
           fail_on_unmatched_files: true
-          prerelease: ${{ !startsWith(github.ref, 'refs/tags/v') || contains(github.ref, '-rc') }}
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      - name: Update release.lean-lang.org
-        run: |
-          gh workflow -R leanprover/release-index run update-index.yml
-        env:
-          GITHUB_TOKEN: ${{ secrets.RELEASE_INDEX_TOKEN }}
-
-  # This job creates nightly releases during the cron job.
-  # It is responsible for creating the tag, and automatically generating a changelog.
+          
   release-nightly:
-    needs: [configure, build]
-    if: needs.configure.outputs.nightly
+    needs: [set-nightly, build]
+    if: needs.set-nightly.outputs.nightly
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v2
         with:
           # needed for tagging
           fetch-depth: 0
           token: ${{ secrets.PUSH_NIGHTLY_TOKEN }}
-      - uses: actions/download-artifact@v4
+      - uses: actions/download-artifact@v2
         with:
           path: artifacts
       - name: Prepare Nightly Release
         run: |
           git remote add nightly https://foo:'${{ secrets.PUSH_NIGHTLY_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-nightly.git
           git fetch nightly --tags
-          git tag "${{ needs.configure.outputs.nightly }}"
-          git push nightly "${{ needs.configure.outputs.nightly }}"
-          git push -f origin refs/tags/${{ needs.configure.outputs.nightly }}:refs/heads/nightly
-          last_tag="$(git log HEAD^ --simplify-by-decoration --pretty="format:%d" | grep -o "nightly-[-0-9]*" | head -n 1)"
+          git tag ${{ needs.set-nightly.outputs.nightly }}
+          git push nightly ${{ needs.set-nightly.outputs.nightly }}
+          last_tag=$(git describe HEAD^ --abbrev=0 --tags)
           echo -e "*Changes since ${last_tag}:*\n\n" > diff.md
-          git show "$last_tag":RELEASES.md > old.md
+          git show $last_tag:RELEASES.md > old.md
           #./script/diff_changelogs.py old.md doc/changes.md >> diff.md
           diff --changed-group-format='%>' --unchanged-group-format='' old.md RELEASES.md >> diff.md || true
           echo -e "\n*Full commit log*\n" >> diff.md
-          git log --oneline "$last_tag"..HEAD | sed 's/^/* /' >> diff.md
+          git log --oneline $last_tag..HEAD | sed 's/^/* /' >> diff.md
       - name: Release Nightly
-        uses: softprops/action-gh-release@v2
+        uses: softprops/action-gh-release@v1
         with:
           body_path: diff.md
           prerelease: true
           files: artifacts/*/*
           fail_on_unmatched_files: true
-          tag_name: ${{ needs.configure.outputs.nightly }}
+          tag_name: ${{ needs.set-nightly.outputs.nightly }}
           repository: ${{ github.repository_owner }}/lean4-nightly
         env:
           GITHUB_TOKEN: ${{ secrets.PUSH_NIGHTLY_TOKEN }}
-      - name: Update release.lean-lang.org
-        run: |
-          gh workflow -R leanprover/release-index run update-index.yml
-        env:
-          GITHUB_TOKEN: ${{ secrets.RELEASE_INDEX_TOKEN }}
-      - name: Update toolchain on mathlib4's nightly-testing branch
-        run: |
-          gh workflow -R leanprover-community/mathlib4 run nightly_bump_toolchain.yml
-        env:
-          GITHUB_TOKEN: ${{ secrets.MATHLIB4_BOT }}

.github/workflows/copyright-header.yml

@@ -1,20 +0,0 @@
-name: Check for copyright header
-
-on: [pull_request]
-
-jobs:
-  check-lean-files:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-
-    - name: Verify .lean files start with a copyright header.
-      run: |
-        FILES=$(find ./src -type d \( -path "./src/lake/examples" -o -path "./src/lake/tests" \) -prune -o -type f -name "*.lean" -exec perl -ne 'BEGIN { $/ = undef; } print "$ARGV\n" if !m{\A/-\nCopyright}; exit;' {} \;)
-        if [ -n "$FILES" ]; then
-          echo "Found .lean files which do not have a copyright header:"
-          echo "$FILES"
-          exit 1
-        else
-          echo "All copyright headers present."
-        fi

.github/workflows/jira.yml

@@ -1,34 +0,0 @@
-name: Jira sync
-
-on:
-  issues:
-    types: [closed]
-
-jobs:
-  jira-sync:
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Move Jira issue to Done
-        env:
-          JIRA_API_TOKEN: ${{ secrets.JIRA_API_TOKEN }}
-          JIRA_USERNAME: ${{ secrets.JIRA_USERNAME }}
-          JIRA_BASE_URL: ${{ secrets.JIRA_BASE_URL }}
-        run: |
-          issue_number=${{ github.event.issue.number }}
-
-          jira_issue_key=$(curl -s -u "${JIRA_USERNAME}:${JIRA_API_TOKEN}" \
-            -X GET -H "Content-Type: application/json" \
-            "${JIRA_BASE_URL}/rest/api/2/search?jql=summary~\"${issue_number}\"" | \
-            jq -r '.issues[0].key')
-
-          if [ -z "$jira_issue_key" ]; then
-            exit
-          fi
-
-          curl -s -u "${JIRA_USERNAME}:${JIRA_API_TOKEN}" \
-            -X POST -H "Content-Type: application/json" \
-            --data "{\"transition\": {\"id\": \"41\"}}" \
-            "${JIRA_BASE_URL}/rest/api/2/issue/${jira_issue_key}/transitions"
-
-          echo "Moved Jira issue ${jira_issue_key} to Done"

.github/workflows/labels-from-comments.yml

@@ -1,67 +0,0 @@
-# This workflow allows any user to add one of the `awaiting-review`, `awaiting-author`, `WIP`,
-# `release-ci`, or a `changelog-XXX` label by commenting on the PR or issue.
-# If any labels from the set {`awaiting-review`, `awaiting-author`, `WIP`} are added, other labels
-# from that set are removed automatically at the same time.
-# Similarly, if any `changelog-XXX` label is added, other `changelog-YYY` labels are removed.
-
-name: Label PR based on Comment
-
-on:
-  issue_comment:
-    types: [created]
-
-jobs:
-  update-label:
-    if: github.event.issue.pull_request != null && (contains(github.event.comment.body, 'awaiting-review') || contains(github.event.comment.body, 'awaiting-author') || contains(github.event.comment.body, 'WIP') || contains(github.event.comment.body, 'release-ci') || contains(github.event.comment.body, 'changelog-'))
-    runs-on: ubuntu-latest
-
-    steps:
-    - name: Add label based on comment
-      uses: actions/github-script@v7
-      with:
-        github-token: ${{ secrets.GITHUB_TOKEN }}
-        script: |
-          const { owner, repo, number: issue_number } = context.issue;
-          const commentLines = context.payload.comment.body.split('\r\n');
-
-          const awaitingReview = commentLines.includes('awaiting-review');
-          const awaitingAuthor = commentLines.includes('awaiting-author');
-          const wip = commentLines.includes('WIP');
-          const releaseCI = commentLines.includes('release-ci');
-          const changelogMatch = commentLines.find(line => line.startsWith('changelog-'));
-
-          if (awaitingReview || awaitingAuthor || wip) {
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'awaiting-review' }).catch(() => {});
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'awaiting-author' }).catch(() => {});
-            await github.rest.issues.removeLabel({ owner, repo, issue_number, name: 'WIP' }).catch(() => {});
-          }
-
-          if (awaitingReview) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['awaiting-review'] });
-          }
-          if (awaitingAuthor) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['awaiting-author'] });
-          }
-          if (wip) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['WIP'] });
-          }
-
-          if (releaseCI) {
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: ['release-ci'] });
-          }
-
-          if (changelogMatch) {
-            const changelogLabel = changelogMatch.trim();
-            const { data: existingLabels } = await github.rest.issues.listLabelsOnIssue({ owner, repo, issue_number });
-            const changelogLabels = existingLabels.filter(label => label.name.startsWith('changelog-'));
-
-            // Remove all other changelog labels
-            for (const label of changelogLabels) {
-              if (label.name !== changelogLabel) {
-                await github.rest.issues.removeLabel({ owner, repo, issue_number, name: label.name }).catch(() => {});
-              }
-            }
-
-            // Add the new changelog label
-            await github.rest.issues.addLabels({ owner, repo, issue_number, labels: [changelogLabel] });
-          }

.github/workflows/nix-ci.yml

@@ -6,137 +6,110 @@ on:
     tags:
       - '*'
   pull_request:
-  merge_group:
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
+    branches:
+      - master
 
 jobs:
-  # see ci.yml
-  configure:
-    runs-on: ubuntu-latest
-    outputs:
-      matrix: ${{ steps.set-matrix.outputs.result }}
-    steps:
-      - name: Configure build matrix
-        id: set-matrix
-        uses: actions/github-script@v7
-        with:
-          script: |
-            let large = ${{ github.repository == 'leanprover/lean4' }};
-            let matrix = [
-              {
-                "name": "Nix Linux",
-                "os": large ? "nscloud-ubuntu-22.04-amd64-8x8" : "ubuntu-latest",
-              }
-            ];
-            console.log(`matrix:\n${JSON.stringify(matrix, null, 2)}`);
-            return matrix;
-
   Build:
-    needs: [configure]
     runs-on: ${{ matrix.os }}
     defaults:
       run:
-        shell: nix run .#ciShell -- bash -euxo pipefail {0}
+        # Can't use `nix-shell` without configured nixpkgs path on macOS
+        shell: nix -v --experimental-features "nix-command flakes" run .#ciShell -- bash -euxo pipefail {0}
     strategy:
       matrix:
-        include: ${{fromJson(needs.configure.outputs.matrix)}}
+        include:
+          - name: Nix Linux
+            os: ubuntu-latest
+            # latest builds on https://hydra.nixos.org/jobset/nix/master/all at the time
+            nix_url: https://hydra.nixos.org/build/135773533/download/1/nix-2.4pre20210125_36c4d6f-x86_64-linux.tar.xz
+          #- name: Nix macOS
+          #  os: macos-latest
+          #  nix_url: https://hydra.nixos.org/build/135773542/download/1/nix-2.4pre20210125_36c4d6f-x86_64-darwin.tar.xz
       # complete all jobs
       fail-fast: false
     name: ${{ matrix.name }}
     env:
-      NIX_BUILD_ARGS: --print-build-logs --fallback
+      NIX_BUILD_ARGS: -v --print-build-logs --fallback
     steps:
       - name: Checkout
-        uses: actions/checkout@v4
-        with:
-          # the default is to use a virtual merge commit between the PR and master: just use the PR
-          ref: ${{ github.event.pull_request.head.sha }}
-      - name: Set Up Nix Cache
-        uses: actions/cache@v4
-        with:
-          path: nix-store-cache
-          key: ${{ matrix.name }}-nix-store-cache-${{ github.sha }}
-          # fall back to (latest) previous cache
-          restore-keys: |
-            ${{ matrix.name }}-nix-store-cache
-          save-always: true
-      - name: Further Set Up Nix Cache
-        shell: bash -euxo pipefail {0}
-        run: |
-          # Nix seems to mutate the cache, so make a copy
-          cp -r nix-store-cache nix-store-cache-copy || true
+        uses: actions/checkout@v2
+      # Install flakes-enabled Nix manually from Hydra since `install-nix-action` doesn't accept raw tarballs
       - name: Install Nix
-        uses: DeterminateSystems/nix-installer-action@main
-        with:
-          extra-conf: |
-            extra-sandbox-paths = /nix/var/cache/ccache?
-            substituters = file://${{ github.workspace }}/nix-store-cache-copy?priority=10&trusted=true https://cache.nixos.org  
-      - name: Prepare CCache Cache
+        shell: bash -euo pipefail {0}
         run: |
+          curl ${{ matrix.nix_url }} | tar -xJ
+          # Do a single-user install so actions/cache doesn't get confused about permissions
+          nix-*/install --no-daemon --no-channel-add --darwin-use-unencrypted-nix-store-volume
+          rm -rf nix-*
+      # Call `install-nix-action` anyways to run its Actions-specific setup
+      - name: Setup Nix
+        uses: cachix/install-nix-action@v12
+      - name: Fixup install-nix-action
+        shell: bash -euo pipefail {0}
+        run: |
+          # the path set by install-nix-action is valid only for multi-user installations
+          echo "NIX_SSL_CERT_FILE=$HOME/.nix-profile/etc/ssl/certs/ca-bundle.crt" > $GITHUB_ENV
+        if: matrix.name == 'macOS'
+      - name: Further setup Nix
+        run: |
+          mkdir -p ~/.config/nix
+          echo '
+            max-jobs = auto
+            extra-sandbox-paths = /nix/var/cache/ccache
+            extra-substituters = file://${{ github.workspace }}/nix-store-cache?priority=10&trusted=true
+            extra-trusted-substituters = https://lean4.cachix.org/
+            extra-trusted-public-keys = lean4.cachix.org-1:mawtxSxcaiWE24xCXXgh3qnvlTkyU7evRRnGeAhD4Wk=' > ~/.config/nix/nix.conf
           sudo mkdir -m0770 -p /nix/var/cache/ccache
-          sudo chown -R $USER /nix/var/cache/ccache
+          # macOS standard chown doesn't support --reference
+          nix shell .#nixpkgs.coreutils -c sudo chown --reference=/nix /nix/var/cache/ccache
+          echo 'max_size = 50M' > /nix/var/cache/ccache/ccache.conf
+
+          # install & use Cachix manually since `cachix-action` pushes *all* derivations (incl. `$mod-deps`, stage 2&3, etc.)
+          [ -z '${{ secrets.CACHIX_AUTH_TOKEN }}' ] || nix-env -iA cachix -f https://cachix.org/api/v1/install
       - name: Setup CCache Cache
-        uses: actions/cache@v4
+        uses: actions/cache@v2
         with:
           path: /nix/var/cache/ccache
           key: ${{ matrix.name }}-nix-ccache-${{ github.sha }}
           # fall back to (latest) previous cache
           restore-keys: |
             ${{ matrix.name }}-nix-ccache
-          save-always: true
-      - name: Further Set Up CCache Cache
-        run: |
-          sudo chown -R root:nixbld /nix/var/cache
-          sudo chmod -R 770 /nix/var/cache
+      - name: Setup Nix Cache
+        uses: actions/cache@v2
+        with:
+          path: nix-store-cache
+          key: ${{ matrix.name }}-nix-store-cache-${{ github.sha }}
+          # fall back to (latest) previous cache
+          restore-keys: |
+            ${{ matrix.name }}-nix-store-cache
       - name: Build
         run: |
-          nix build $NIX_BUILD_ARGS .#cacheRoots -o push-build
+          # .o files are not a runtime dependency on macOS because of lack of thin archives
+          nix build $NIX_BUILD_ARGS .#stage0 .#stage1.lean-all .#Lean.oTree .#iTree -o push-build
       - name: Test
         run: |
-          nix build --keep-failed $NIX_BUILD_ARGS .#test -o push-test || (ln -s /tmp/nix-build-*/build/source/src/build ./push-test; false)
-      - name: Test Summary
-        uses: test-summary/action@v2
-        with:
-          paths: push-test/test-results.xml
-        if: always()
-        continue-on-error: true
+          nix build $NIX_BUILD_ARGS .#test -o push-test
       - name: Build manual
         run: |
-          nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc#{lean-mdbook,leanInk,alectryon,inked} -o push-doc
-          nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc
-          # https://github.com/netlify/cli/issues/1809
-          cp -r --dereference ./result ./dist
-        if: matrix.name == 'Nix Linux'
+          nix build $NIX_BUILD_ARGS .#mdbook .#doc-test -o push-doc
+          nix build $NIX_BUILD_ARGS .#doc
+        if: matrix.name == 'Linux'
+      - name: Push to Cachix
+        run: |
+          [ -z "$CACHIX_AUTH_TOKEN" ] || cachix push -j4 lean4 ./push-* || true
+        env:
+          CACHIX_AUTH_TOKEN: '${{ secrets.CACHIX_AUTH_TOKEN }}'
       - name: Rebuild Nix Store Cache
         run: |
           rm -rf nix-store-cache || true
           nix copy ./push-* --to file://$PWD/nix-store-cache?compression=none
-      - id: deploy-info
-        name: Compute Deployment Metadata
-        run: |
-          set -e
-          python3 -c 'import base64; print("alias="+base64.urlsafe_b64encode(bytes.fromhex("${{github.sha}}")).decode("utf-8").rstrip("="))' >> "$GITHUB_OUTPUT"
-          echo "message=`git log -1 --pretty=format:"%s"`" >> "$GITHUB_OUTPUT"
-      - name: Publish manual to Netlify
-        uses: nwtgck/actions-netlify@v3.0
-        id: publish-manual
+      - name: Publish manual
+        uses: peaceiris/actions-gh-pages@v3
         with:
-          publish-dir: ./dist
-          production-branch: master
-          github-token: ${{ secrets.GITHUB_TOKEN }}
-          deploy-message: |
-            ${{ github.event_name == 'pull_request' && format('pr#{0}: {1}', github.event.number, github.event.pull_request.title) || format('ref/{0}: {1}', github.ref_name, steps.deploy-info.outputs.message) }}
-          alias: ${{ steps.deploy-info.outputs.alias }}
-          enable-commit-comment: false
-          enable-pull-request-comment: false
-          github-deployment-environment: "lean-lang.org/lean4/doc"
-          fails-without-credentials: false
-        env:
-          NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
-          NETLIFY_SITE_ID: "b8e805d2-7e9b-4f80-91fb-a84d72fc4a68"
-      - name: Fixup CCache Cache
-        run: |
-          sudo chown -R $USER /nix/var/cache
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: ./result
+          destination_dir: ./doc
+        if: matrix.name == 'Linux' && github.ref == 'refs/heads/master' && github.event_name == 'push'
+      - name: CCache stats
+        run: CCACHE_DIR=/nix/var/cache/ccache nix run .#nixpkgs.ccache -- -s

.github/workflows/pr-body.yml

@@ -1,25 +0,0 @@
-name: Check PR body for changelog convention
-
-on:
-  merge_group:
-  pull_request:
-    types: [opened, synchronize, reopened, edited, labeled, converted_to_draft, ready_for_review]
-
-jobs:
-  check-pr-body:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check PR body
-        if: github.event_name == 'pull_request'
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const { title, body, labels, draft } = context.payload.pull_request;
-            if (!draft && /^(feat|fix):/.test(title) && !labels.some(label => label.name == "changelog-no")) {
-              if (!labels.some(label => label.name.startsWith("changelog-"))) {
-                core.setFailed('feat/fix PR must have a `changelog-*` label');
-              }
-              if (!/^This PR [^<]/.test(body)) {
-                core.setFailed('feat/fix PR must have changelog summary starting with "This PR ..." as first line.');
-              }
-            }

.github/workflows/pr-release.yml

@@ -1,350 +0,0 @@
-# Push a release to the lean4-pr-releases repository, whenever someone pushes to a PR branch.
-
-# This needs to run with the `secrets.PR_RELEASES_TOKEN` token available,
-# but PR branches will generally come from forks,
-# so it is not possible to run this using the `pull_request` or `pull_request_target` workflows.
-# Instead we use `workflow_run`, which essentially allows us to escalate privileges
-# (but only runs the CI as described in the `master` branch, not in the PR branch).
-
-# The main specification/documentation for this workflow is at
-# https://leanprover-community.github.io/contribute/tags_and_branches.html
-# Keep that in sync!
-
-name: PR release
-
-on:
-  workflow_run: # https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run
-    workflows: [CI]
-    types: [completed]
-
-jobs:
-  on-success:
-    runs-on: ubuntu-latest
-    if: github.event.workflow_run.conclusion == 'success' && github.event.workflow_run.event == 'pull_request' && github.repository == 'leanprover/lean4'
-    steps:
-      - name: Retrieve information about the original workflow
-        uses: potiuk/get-workflow-origin@v1_1 # https://github.com/marketplace/actions/get-workflow-origin
-        # This action is deprecated and archived, but it seems hard to find a better solution for getting the PR number
-        # see https://github.com/orgs/community/discussions/25220 for some discussion
-        id: workflow-info
-        with:
-          token: ${{ secrets.GITHUB_TOKEN }}
-          sourceRunId: ${{ github.event.workflow_run.id }}
-
-      - name: Download artifact from the previous workflow.
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        id: download-artifact
-        uses: dawidd6/action-download-artifact@v7 # https://github.com/marketplace/actions/download-workflow-artifact
-        with:
-          run_id: ${{ github.event.workflow_run.id }}
-          path: artifacts
-          name: build-.*
-          name_is_regexp: true
-
-      - name: Push tag
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        run: |
-          git init --bare lean4.git
-          git -C lean4.git remote add origin https://github.com/${{ github.repository_owner }}/lean4.git
-          git -C lean4.git fetch -n origin master
-          git -C lean4.git fetch -n origin "${{ steps.workflow-info.outputs.sourceHeadSha }}"
-          git -C lean4.git tag -f pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }} "${{ steps.workflow-info.outputs.sourceHeadSha }}"
-          git -C lean4.git remote add pr-releases https://foo:'${{ secrets.PR_RELEASES_TOKEN }}'@github.com/${{ github.repository_owner }}/lean4-pr-releases.git
-          git -C lean4.git push -f pr-releases pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}
-      - name: Delete existing release if present
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        run: |
-          # Try to delete any existing release for the current PR.
-          gh release delete --repo ${{ github.repository_owner }}/lean4-pr-releases pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }} -y || true
-        env:
-          GH_TOKEN: ${{ secrets.PR_RELEASES_TOKEN }}
-      - name: Release
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: softprops/action-gh-release@v2
-        with:
-          name: Release for PR ${{ steps.workflow-info.outputs.pullRequestNumber }}
-          # There are coredumps files here as well, but all in deeper subdirectories.
-          files: artifacts/*/*
-          fail_on_unmatched_files: true
-          draft: false
-          tag_name: pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}
-          repository: ${{ github.repository_owner }}/lean4-pr-releases
-        env:
-          # The token used here must have `workflow` privileges.
-          GITHUB_TOKEN: ${{ secrets.PR_RELEASES_TOKEN }}
-
-      - name: Report release status
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: actions/github-script@v7
-        with:
-          script: |
-            await github.rest.repos.createCommitStatus({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              sha: "${{ steps.workflow-info.outputs.sourceHeadSha }}",
-              state: "success",
-              context: "PR toolchain",
-              description: "${{ github.repository_owner }}/lean4-pr-releases:pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}",
-            });
-
-      - name: Add label
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: actions/github-script@v7
-        with:
-          script: |
-            await github.rest.issues.addLabels({
-              issue_number: ${{ steps.workflow-info.outputs.pullRequestNumber }},
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              labels: ['toolchain-available']
-            })
-
-      # Next, determine the most recent nightly release in this PR's history.
-      - name: Find most recent nightly in feature branch
-        id: most-recent-nightly-tag
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        run: |
-          git -C lean4.git remote add nightly https://github.com/leanprover/lean4-nightly.git
-          git -C lean4.git fetch nightly '+refs/tags/nightly-*:refs/tags/nightly-*'
-          git -C lean4.git tag --merged "${{ steps.workflow-info.outputs.sourceHeadSha }}" --list "nightly-*" \
-            | sort -rV | head -n 1 | sed "s/^nightly-*/MOST_RECENT_NIGHTLY=/" | tee -a "$GITHUB_ENV"
-
-      - name: 'Setup jq'
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        uses: dcarbone/install-jq-action@v3.0.1
-
-      # Check that the most recently nightly coincides with 'git merge-base HEAD master'
-      - name: Check merge-base and nightly-testing-YYYY-MM-DD
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' }}
-        id: ready
-        run: |
-          echo "Most recent nightly release in your branch: $MOST_RECENT_NIGHTLY"
-          NIGHTLY_SHA=$(git -C lean4.git rev-parse "nightly-$MOST_RECENT_NIGHTLY^{commit}")
-          echo "SHA of most recent nightly release: $NIGHTLY_SHA"
-          MERGE_BASE_SHA=$(git -C lean4.git merge-base origin/master "${{ steps.workflow-info.outputs.sourceHeadSha }}")
-          echo "SHA of merge-base: $MERGE_BASE_SHA"
-          if [ "$NIGHTLY_SHA" = "$MERGE_BASE_SHA" ]; then
-            echo "The merge base of this PR coincides with the nightly release"
-
-            BATTERIES_REMOTE_TAGS="$(git ls-remote https://github.com/leanprover-community/batteries.git nightly-testing-"$MOST_RECENT_NIGHTLY")"
-            MATHLIB_REMOTE_TAGS="$(git ls-remote https://github.com/leanprover-community/mathlib4.git nightly-testing-"$MOST_RECENT_NIGHTLY")"
-
-            if [[ -n "$BATTERIES_REMOTE_TAGS" ]]; then
-              echo "... and Batteries has a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              MESSAGE=""
-
-              if [[ -n "$MATHLIB_REMOTE_TAGS" ]]; then
-                echo "... and Mathlib has a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              else
-                echo "... but Mathlib does not yet have a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-                MESSAGE="- ❗ Mathlib CI can not be attempted yet, as the \`nightly-testing-$MOST_RECENT_NIGHTLY\` tag does not exist there yet. We will retry when you push more commits. If you rebase your branch onto \`nightly-with-mathlib\`, Mathlib CI should run now."
-              fi
-            else
-              echo "... but Batteries does not yet have a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              MESSAGE="- ❗ Batteries CI can not be attempted yet, as the \`nightly-testing-$MOST_RECENT_NIGHTLY\` tag does not exist there yet. We will retry when you push more commits. If you rebase your branch onto \`nightly-with-mathlib\`, Batteries CI should run now."
-            fi
-
-          else
-            echo "The most recently nightly tag on this branch has SHA: $NIGHTLY_SHA"
-            echo "but 'git merge-base origin/master HEAD' reported: $MERGE_BASE_SHA"
-            git -C lean4.git log -10 origin/master
-
-            git -C lean4.git fetch origin nightly-with-mathlib
-            NIGHTLY_WITH_MATHLIB_SHA="$(git -C lean4.git rev-parse "origin/nightly-with-mathlib")"
-            MESSAGE="- ❗ Batteries/Mathlib CI will not be attempted unless your PR branches off the \`nightly-with-mathlib\` branch. Try \`git rebase $MERGE_BASE_SHA --onto $NIGHTLY_WITH_MATHLIB_SHA\`."
-          fi
-
-          if [[ -n "$MESSAGE" ]]; then
-
-            echo "Checking existing messages"
-
-            # The code for updating comments is duplicated in mathlib's
-            # scripts/lean-pr-testing-comments.sh
-            # so keep in sync
-
-            # Use GitHub API to check if a comment already exists
-            existing_comment="$(curl --retry 3 --location --silent \
-                                    -H "Authorization: token ${{ secrets.MATHLIB4_COMMENT_BOT }}" \
-                                    -H "Accept: application/vnd.github.v3+json" \
-                                    "https://api.github.com/repos/leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments" \
-                                    | jq 'first(.[] | select(.body | test("^- . Mathlib") or startswith("Mathlib CI status")) | select(.user.login == "leanprover-community-bot"))')"
-            existing_comment_id="$(echo "$existing_comment" | jq -r .id)"
-            existing_comment_body="$(echo "$existing_comment" | jq -r .body)"
-
-            if [[ "$existing_comment_body" != *"$MESSAGE"* ]]; then
-              MESSAGE="$MESSAGE ($(date "+%Y-%m-%d %H:%M:%S"))"
-
-              echo "Posting message to the comments: $MESSAGE"
-
-              # Append new result to the existing comment or post a new comment
-              # It's essential we use the MATHLIB4_COMMENT_BOT token here, so that Mathlib CI can subsequently edit the comment.
-              if [ -z "$existing_comment_id" ]; then
-                INTRO="Mathlib CI status ([docs](https://leanprover-community.github.io/contribute/tags_and_branches.html)):"
-                # Post new comment with a bullet point
-                echo "Posting as new comment at leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments"
-                curl -L -s \
-                  -X POST \
-                  -H "Authorization: token ${{ secrets.MATHLIB4_COMMENT_BOT }}" \
-                  -H "Accept: application/vnd.github.v3+json" \
-                  -d "$(jq --null-input --arg intro "$INTRO" --arg val "$MESSAGE" '{"body":($intro + "\n" + $val)}')" \
-                  "https://api.github.com/repos/leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments"
-              else
-                # Append new result to the existing comment
-                echo "Appending to existing comment at leanprover/lean4/issues/${{ steps.workflow-info.outputs.pullRequestNumber }}/comments"
-                curl -L -s \
-                  -X PATCH \
-                  -H "Authorization: token ${{ secrets.MATHLIB4_COMMENT_BOT }}" \
-                  -H "Accept: application/vnd.github.v3+json" \
-                  -d "$(jq --null-input --arg existing "$existing_comment_body" --arg message "$MESSAGE" '{"body":($existing + "\n" + $message)}')" \
-                  "https://api.github.com/repos/leanprover/lean4/issues/comments/$existing_comment_id"
-              fi
-            else
-              echo "The message already exists in the comment body."
-            fi
-            echo "mathlib_ready=false" >> "$GITHUB_OUTPUT"
-          else
-            echo "mathlib_ready=true" >> "$GITHUB_OUTPUT"
-          fi
-
-      - name: Report mathlib base
-        if: ${{ steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true' }}
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const description =
-              process.env.MOST_RECENT_NIGHTLY ?
-              "nightly-" + process.env.MOST_RECENT_NIGHTLY :
-              "not branched off nightly";
-            await github.rest.repos.createCommitStatus({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              sha: "${{ steps.workflow-info.outputs.sourceHeadSha }}",
-              state: "success",
-              context: "PR branched off:",
-              description: description,
-            });
-
-      # We next automatically create a Batteries branch using this toolchain.
-      # Batteries doesn't itself have a mechanism to report results of CI from this branch back to Lean
-      # Instead this is taken care of by Mathlib CI, which will fail if Batteries fails.
-      - name: Cleanup workspace
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          sudo rm -rf ./*
-
-      # Checkout the Batteries repository with all branches
-      - name: Checkout Batteries repository
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        uses: actions/checkout@v4
-        with:
-          repository: leanprover-community/batteries
-          token: ${{ secrets.MATHLIB4_BOT }}
-          ref: nightly-testing
-          fetch-depth: 0 # This ensures we check out all tags and branches.
-
-      - name: Check if tag exists
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        id: check_batteries_tag
-        run: |
-          git config user.name "leanprover-community-mathlib4-bot"
-          git config user.email "leanprover-community-mathlib4-bot@users.noreply.github.com"
-
-          if git ls-remote --heads --tags --exit-code origin "nightly-testing-${MOST_RECENT_NIGHTLY}" >/dev/null; then
-            BASE="nightly-testing-${MOST_RECENT_NIGHTLY}"
-          else
-            echo "This shouldn't be possible: couldn't find a 'nightly-testing-${MOST_RECENT_NIGHTLY}' tag at Batteries. Falling back to 'nightly-testing'."
-            BASE=nightly-testing
-          fi
-
-          echo "Using base branch: $BASE"
-
-          EXISTS="$(git ls-remote --heads origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} | wc -l)"
-          echo "Branch exists: $EXISTS"
-          if [ "$EXISTS" = "0" ]; then
-            echo "Branch does not exist, creating it."
-            git switch -c lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} "$BASE"
-            echo "leanprover/lean4-pr-releases:pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}" > lean-toolchain
-            git add lean-toolchain
-            git commit -m "Update lean-toolchain for testing https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          else
-            echo "Branch already exists, pushing an empty commit."
-            git switch lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}
-            # The Batteries `nightly-testing` or `nightly-testing-YYYY-MM-DD` branch may have moved since this branch was created, so merge their changes.
-            # (This should no longer be possible once `nightly-testing-YYYY-MM-DD` is a tag, but it is still safe to merge.)
-            git merge "$BASE" --strategy-option ours --no-commit --allow-unrelated-histories
-            git commit --allow-empty -m "Trigger CI for https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          fi
-
-      - name: Push changes
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          git push origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}
-
-
-      # We next automatically create a Mathlib branch using this toolchain.
-      # Mathlib CI will be responsible for reporting back success or failure
-      # to the PR comments asynchronously.
-      - name: Cleanup workspace
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          sudo rm -rf ./*
-
-      # Checkout the mathlib4 repository with all branches
-      - name: Checkout mathlib4 repository
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        uses: actions/checkout@v4
-        with:
-          repository: leanprover-community/mathlib4
-          token: ${{ secrets.MATHLIB4_BOT }}
-          ref: nightly-testing
-          fetch-depth: 0 # This ensures we check out all tags and branches.
-
-      - name: install elan
-        run: |
-          set -o pipefail
-          curl -sSfL https://github.com/leanprover/elan/releases/download/v3.0.0/elan-x86_64-unknown-linux-gnu.tar.gz | tar xz
-          ./elan-init -y --default-toolchain none
-          echo "$HOME/.elan/bin" >> "${GITHUB_PATH}"
-
-      - name: Check if tag exists
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        id: check_mathlib_tag
-        run: |
-          git config user.name "leanprover-community-mathlib4-bot"
-          git config user.email "leanprover-community-mathlib4-bot@users.noreply.github.com"
-
-          if git ls-remote --heads --tags --exit-code origin "nightly-testing-${MOST_RECENT_NIGHTLY}" >/dev/null; then
-            BASE="nightly-testing-${MOST_RECENT_NIGHTLY}"
-          else
-            echo "This shouldn't be possible: couldn't find a 'nightly-testing-${MOST_RECENT_NIGHTLY}' branch at Mathlib. Falling back to 'nightly-testing'."
-            BASE=nightly-testing
-          fi
-
-          echo "Using base tag: $BASE"
-
-          EXISTS="$(git ls-remote --heads origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} | wc -l)"
-          echo "Branch exists: $EXISTS"
-          if [ "$EXISTS" = "0" ]; then
-            echo "Branch does not exist, creating it."
-            git switch -c lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }} "$BASE"
-            echo "leanprover/lean4-pr-releases:pr-release-${{ steps.workflow-info.outputs.pullRequestNumber }}" > lean-toolchain
-            git add lean-toolchain
-            sed -i 's,require "leanprover-community" / "batteries" @ git ".\+",require "leanprover-community" / "batteries" @ git "lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}",' lakefile.lean
-            lake update batteries
-            git add lakefile.lean lake-manifest.json
-            git commit -m "Update lean-toolchain for testing https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          else
-            echo "Branch already exists, merging $BASE and bumping Batteries."
-            git switch lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}
-            # The Mathlib `nightly-testing` branch or `nightly-testing-YYYY-MM-DD` tag may have moved since this branch was created, so merge their changes.
-            # (This should no longer be possible once `nightly-testing-YYYY-MM-DD` is a tag, but it is still safe to merge.)
-            git merge "$BASE" --strategy-option ours --no-commit --allow-unrelated-histories
-            lake update batteries
-            git add lake-manifest.json
-            git commit --allow-empty -m "Trigger CI for https://github.com/leanprover/lean4/pull/${{ steps.workflow-info.outputs.pullRequestNumber }}"
-          fi
-
-      - name: Push changes
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          git push origin lean-pr-testing-${{ steps.workflow-info.outputs.pullRequestNumber }}

.github/workflows/pr-title.yml

@@ -1,20 +0,0 @@
-name: Check PR title for commit convention
-
-on:
-  merge_group:
-  pull_request:
-    types: [opened, synchronize, reopened, edited]
-
-jobs:
-  check-pr-title:
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check PR title
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const msg = context.payload.pull_request? context.payload.pull_request.title : context.payload.merge_group.head_commit.message;
-            console.log(`Message: ${msg}`)
-            if (!/^(feat|fix|doc|style|refactor|test|chore|perf): .*[^.]($|\n\n)/.test(msg)) {
-              core.setFailed('PR title does not follow the Commit Convention (https://leanprover.github.io/lean4/doc/dev/commit_convention.html).');
-            }

.github/workflows/pr.yml

@@ -0,0 +1,31 @@
+name: sanity-check opened PRs
+
+on:
+  # needs read/write GH token, do *not* execute arbitrary code from PR
+  pull_request_target:
+    types: [opened]
+
+jobs:
+  check-pr:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check Commit Message
+        uses: actions/github-script@v3
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const { data: commits } = await github.pulls.listCommits({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              pull_number: context.issue.number,
+            });
+            console.log(commits[0].commit.message);
+            // check first commit only (and only once) since later commits might be intended to be squashed away
+            if (!/^(feat|fix|doc|style|refactor|test|chore|perf): .*[^.]($|\n\n)/.test(commits[0].commit.message)) {
+              await github.issues.createComment({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                issue_number: context.issue.number,
+                body: 'Thanks for your contribution! Please make sure to follow our [Commit Convention](https://leanprover.github.io/lean4/doc/dev/commit_convention.html).',
+              });
+            }

.github/workflows/restart-on-label.yml

@@ -1,35 +0,0 @@
-name: Restart by label
-on:
-  pull_request_target:
-    types:
-      - unlabeled
-      - labeled
-jobs:
-  restart-on-label:
-    runs-on: ubuntu-latest
-    if: contains(github.event.label.name, 'merge-ci') || contains(github.event.label.name, 'release-ci')
-    steps:
-    - run: |
-        # Finding latest CI workflow run on current pull request
-        # (unfortunately cannot search by PR number, only base branch,
-        # and that is't even unique given PRs from forks, but the risk
-        # of confusion is low and the danger is mild)
-        echo "Trying to find a run with branch $head_ref and commit $head_sha"
-        run_id="$(gh run list -e pull_request -b "$head_ref" -c "$head_sha" \
-          --workflow 'CI' --limit 1 --json databaseId --jq '.[0].databaseId')"
-        echo "Run id: ${run_id}"
-        gh run view "$run_id"
-        echo "Cancelling (just in case)"
-        gh run cancel "$run_id" || echo "(failed)"
-        echo "Waiting for 30s"
-        sleep 30
-        gh run view "$run_id"
-        echo "Rerunning"
-        gh run rerun "$run_id"
-        gh run view "$run_id"
-      shell: bash
-      env:
-        head_ref: ${{ github.head_ref }}
-        head_sha: ${{ github.event.pull_request.head.sha }}
-        GH_TOKEN: ${{ github.token }}
-        GH_REPO: ${{ github.repository }}

.github/workflows/stale.yml

@@ -1,20 +0,0 @@
-name: 'Label stale PRs'
-on:
-  schedule:
-    - cron: '30 1 * * *'
-  workflow_dispatch:
-
-permissions:
-  pull-requests: write
-
-jobs:
-  stale:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/stale@v9
-        with:
-          days-before-stale: -1
-          days-before-pr-stale: 30
-          days-before-close: -1
-          stale-pr-label: 'stale'
-          only-labels: 'awaiting-author'

.github/workflows/update-stage0.yml

@@ -1,78 +0,0 @@
-name: Update stage0
-
-# This action will update stage0 on master as soon as
-# src/stdlib_flags.h and stage0/src/stdlib_flags.h
-# are out of sync there, or when manually triggered.
-# The update bypasses the merge queue to be quick.
-# Also see <doc/dev/bootstrap.md>.
-
-on:
-  push:
-    branches:
-      - 'master'
-  workflow_dispatch:
-
-concurrency:
-  group: stage0
-  cancel-in-progress: true
-
-jobs:
-  update-stage0:
-    runs-on: ubuntu-latest
-    steps:
-    # This action should push to an otherwise protected branch, so it
-    # uses a deploy key with write permissions, as suggested at
-    # https://stackoverflow.com/a/76135647/946226
-    - uses: actions/checkout@v4
-      with:
-        ssh-key: ${{secrets.STAGE0_SSH_KEY}}
-    - run: echo "should_update_stage0=yes" >> "$GITHUB_ENV"
-    - name: Check if automatic update is needed
-      if: github.event_name == 'push'
-      run: |
-        if diff -u src/stdlib_flags.h stage0/src/stdlib_flags.h
-        then
-          echo "src/stdlib_flags.h and stage0/src/stdlib_flags.h agree, nothing to do"
-          echo "should_update_stage0=no" >> "$GITHUB_ENV"
-        fi
-    - name: Setup git user
-      if: env.should_update_stage0 == 'yes'
-      run: |
-          git config --global user.name "Lean stage0 autoupdater"
-          git config --global user.email "<>"
-    # Would be nice, but does not work yet:
-    # https://github.com/DeterminateSystems/magic-nix-cache/issues/39
-    # This action does not run that often and building runs in a few minutes, so ok for now
-    #- if: env.should_update_stage0 == 'yes'
-    #  uses: DeterminateSystems/magic-nix-cache-action@v2
-    - if: env.should_update_stage0 == 'yes'
-      name: Restore Build Cache
-      uses: actions/cache/restore@v4
-      with:
-        path: nix-store-cache
-        key: Nix Linux-nix-store-cache-${{ github.sha }}
-        # fall back to (latest) previous cache
-        restore-keys: |
-          Nix Linux-nix-store-cache
-    - if: env.should_update_stage0 == 'yes'
-      name: Further Set Up Nix Cache
-      shell: bash -euxo pipefail {0}
-      run: |
-        # Nix seems to mutate the cache, so make a copy
-        cp -r nix-store-cache nix-store-cache-copy || true
-    - if: env.should_update_stage0 == 'yes'
-      name: Install Nix
-      uses: DeterminateSystems/nix-installer-action@main
-      with:
-        extra-conf: |
-          substituters = file://${{ github.workspace }}/nix-store-cache-copy?priority=10&trusted=true https://cache.nixos.org  
-    - if: env.should_update_stage0 == 'yes'
-      run: nix run .#update-stage0-commit
-    - if: env.should_update_stage0 == 'yes'
-      run: git show --stat
-    - if: env.should_update_stage0 == 'yes' && github.event_name == 'push'
-      name: Sanity check # to avoid loops
-      run: |
-        diff -u src/stdlib_flags.h stage0/src/stdlib_flags.h || exit 1
-    - if: env.should_update_stage0 == 'yes'
-      run: git push origin

.gitignore

@@ -2,12 +2,7 @@
 \#*
 .#*
 *.lock
-.lake
-lake-manifest.json
-/build
-/src/lakefile.toml
-/tests/lakefile.toml
-/lakefile.toml
+build
 GPATH
 GRTAGS
 GSYMS
@@ -30,4 +25,4 @@ fwIn.txt
 fwOut.txt
 wdErr.txt
 wdIn.txt
-wdOut.txt
+wdOut.txt

.gitmodules

@@ -0,0 +1,4 @@
+[submodule "lake"]
+        path = src/lake
+        url = https://github.com/leanprover/lake.git
+        ignore = untracked

.ignore

@@ -1 +0,0 @@
-stage0/

.vscode/settings.json

@@ -0,0 +1,7 @@
+{
+    "files.insertFinalNewline": true,
+    "files.trimTrailingWhitespace": true,
+    "[markdown]": {
+        "rewrap.wrappingColumn": 70
+    }
+}

CMakeLists.txt

@@ -11,13 +11,10 @@ foreach(var ${vars})
     list(APPEND STAGE0_ARGS "-D${CMAKE_MATCH_1}=${${var}}")
   elseif("${currentHelpString}" MATCHES "No help, variable specified on the command line." OR "${currentHelpString}" STREQUAL "")
     list(APPEND CL_ARGS "-D${var}=${${var}}")
-    if("${var}" MATCHES "USE_GMP|CHECK_OLEAN_VERSION")
+    if("${var}" STREQUAL "USE_GMP")
       # must forward options that generate incompatible .olean format
       list(APPEND STAGE0_ARGS "-D${var}=${${var}}")
     endif()
-    if("${var}" MATCHES "LLVM*")
-      list(APPEND STAGE0_ARGS "-D${var}=${${var}}")
-    endif()
   elseif(("${var}" MATCHES "CMAKE_.*") AND NOT ("${var}" MATCHES "CMAKE_BUILD_TYPE") AND NOT ("${var}" MATCHES "CMAKE_HOME_DIRECTORY"))
     list(APPEND PLATFORM_ARGS "-D${var}=${${var}}")
   endif()
@@ -26,46 +23,28 @@ endforeach()
 include(ExternalProject)
 project(LEAN CXX C)
 
-if(NOT (DEFINED STAGE0_CMAKE_EXECUTABLE_SUFFIX))
-    set(STAGE0_CMAKE_EXECUTABLE_SUFFIX "${CMAKE_EXECUTABLE_SUFFIX}")
+if("${CMAKE_SYSTEM_NAME}" MATCHES "Emscripten")
+  # For Emscripten, we build GMP before any of the stages and reuse it in all of them.
+  set(GMP_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/gmp-root)
+  set(EMSCRIPTEN_FLAGS "-s ALLOW_MEMORY_GROWTH=1 -s MAIN_MODULE=1 -O3")
+  ExternalProject_Add(
+    gmp
+    URL https://gmplib.org/download/gmp/gmp-6.2.1.tar.bz2
+    URL_HASH SHA256=eae9326beb4158c386e39a356818031bd28f3124cf915f8c5b1dc4c7a36b4d7c
+    BUILD_IN_SOURCE 1
+    CONFIGURE_COMMAND emconfigure ./configure "CFLAGS=${EMSCRIPTEN_FLAGS}" --host=wasm32-unknown-emscripten --disable-assembly --prefix=${GMP_INSTALL_PREFIX}
+    BUILD_COMMAND emmake make -j4
+    INSTALL_COMMAND emmake make install
+  )
+  set(EXTRA_DEPENDS "gmp")
+  list(APPEND CL_ARGS "-DGMP_INSTALL_PREFIX=${GMP_INSTALL_PREFIX}")
+  list(APPEND PLATFORM_ARGS "-DGMP_INSTALL_PREFIX=${GMP_INSTALL_PREFIX}")
 endif()
-
-# Don't do anything with cadical on wasm
-if (NOT ${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
-  # On CI Linux, we source cadical from Nix instead; see flake.nix
-  find_program(CADICAL cadical)
-  if(NOT CADICAL)
-    set(CADICAL_CXX c++)
-    find_program(CCACHE ccache)
-    if(CCACHE)
-      set(CADICAL_CXX "${CCACHE} ${CADICAL_CXX}")
-    endif()
-    # missing stdio locking API on Windows
-    if(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
-      string(APPEND CADICAL_CXXFLAGS " -DNUNLOCKED")
-    endif()
-    ExternalProject_add(cadical
-      PREFIX cadical
-      GIT_REPOSITORY https://github.com/arminbiere/cadical
-      GIT_TAG rel-1.9.5
-      CONFIGURE_COMMAND ""
-      # https://github.com/arminbiere/cadical/blob/master/BUILD.md#manual-build
-      BUILD_COMMAND $(MAKE) -f ${CMAKE_SOURCE_DIR}/src/cadical.mk CMAKE_EXECUTABLE_SUFFIX=${CMAKE_EXECUTABLE_SUFFIX} CXX=${CADICAL_CXX} CXXFLAGS=${CADICAL_CXXFLAGS}
-      BUILD_IN_SOURCE ON
-      INSTALL_COMMAND "")
-    set(CADICAL ${CMAKE_BINARY_DIR}/cadical/cadical${CMAKE_EXECUTABLE_SUFFIX} CACHE FILEPATH "path to cadical binary" FORCE)
-    set(EXTRA_DEPENDS "cadical")
-  endif()
-  list(APPEND CL_ARGS -DCADICAL=${CADICAL})
-endif()
-
 ExternalProject_add(stage0
   SOURCE_DIR "${LEAN_SOURCE_DIR}/stage0"
   SOURCE_SUBDIR src
   BINARY_DIR stage0
   # do not rebuild stage0 when git hash changes; it's not from this commit anyway
-  # (however, `CHECK_OLEAN_VERSION=ON` in CI will override this as we need to
-  # embed the githash into the stage 1 library built by stage 0)
   CMAKE_ARGS -DSTAGE=0 -DUSE_GITHASH=OFF ${PLATFORM_ARGS} ${STAGE0_ARGS}
   BUILD_ALWAYS ON  # cmake doesn't auto-detect changes without a download method
   INSTALL_COMMAND ""  # skip install
@@ -75,7 +54,7 @@ ExternalProject_add(stage1
   SOURCE_DIR "${LEAN_SOURCE_DIR}"
   SOURCE_SUBDIR src
   BINARY_DIR stage1
-  CMAKE_ARGS -DSTAGE=1 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage0 -DPREV_STAGE_CMAKE_EXECUTABLE_SUFFIX=${STAGE0_CMAKE_EXECUTABLE_SUFFIX} ${CL_ARGS}
+  CMAKE_ARGS -DSTAGE=1 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage0 ${CL_ARGS}
   BUILD_ALWAYS ON
   INSTALL_COMMAND ""
   DEPENDS stage0
@@ -84,7 +63,7 @@ ExternalProject_add(stage2
   SOURCE_DIR "${LEAN_SOURCE_DIR}"
   SOURCE_SUBDIR src
   BINARY_DIR stage2
-  CMAKE_ARGS -DSTAGE=2 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage1 -DPREV_STAGE_CMAKE_EXECUTABLE_SUFFIX=${CMAKE_EXECUTABLE_SUFFIX} ${CL_ARGS}
+  CMAKE_ARGS -DSTAGE=2 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage1 ${CL_ARGS}
   BUILD_ALWAYS ON
   INSTALL_COMMAND ""
   DEPENDS stage1
@@ -94,7 +73,7 @@ ExternalProject_add(stage3
   SOURCE_DIR "${LEAN_SOURCE_DIR}"
   SOURCE_SUBDIR src
   BINARY_DIR stage3
-  CMAKE_ARGS -DSTAGE=3 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage2 -DPREV_STAGE_CMAKE_EXECUTABLE_SUFFIX=${CMAKE_EXECUTABLE_SUFFIX} ${CL_ARGS}
+  CMAKE_ARGS -DSTAGE=3 -DPREV_STAGE=${CMAKE_BINARY_DIR}/stage2 ${CL_ARGS}
   BUILD_ALWAYS ON
   INSTALL_COMMAND ""
   DEPENDS stage2
@@ -107,10 +86,6 @@ add_custom_target(update-stage0
   COMMAND $(MAKE) -C stage1 update-stage0
   DEPENDS stage1)
 
-add_custom_target(update-stage0-commit
-  COMMAND $(MAKE) -C stage1 update-stage0-commit
-  DEPENDS stage1)
-
 add_custom_target(test
   COMMAND $(MAKE) -C stage1 test
   DEPENDS stage1)

CMakePresets.json

@@ -1,83 +0,0 @@
-{
-  "version": 2,
-  "cmakeMinimumRequired": {
-    "major": 3,
-    "minor": 10,
-    "patch": 0
-  },
-  "configurePresets": [
-    {
-      "name": "release",
-      "displayName": "Default development optimized build config",
-      "generator": "Unix Makefiles",
-      "binaryDir": "${sourceDir}/build/release"
-    },
-    {
-      "name": "debug",
-      "displayName": "Debug build config",
-      "cacheVariables": {
-        "CMAKE_BUILD_TYPE": "Debug"
-      },
-      "generator": "Unix Makefiles",
-      "binaryDir": "${sourceDir}/build/debug"
-    },
-    {
-      "name": "sanitize",
-      "displayName": "Sanitize build config",
-      "cacheVariables": {
-        "LEAN_EXTRA_CXX_FLAGS": "-fsanitize=address,undefined",
-        "LEANC_EXTRA_FLAGS": "-fsanitize=address,undefined -fsanitize-link-c++-runtime",
-        "SMALL_ALLOCATOR": "OFF",
-        "BSYMBOLIC": "OFF"
-      },
-      "generator": "Unix Makefiles",
-      "binaryDir": "${sourceDir}/build/sanitize"
-    },
-    {
-      "name": "sandebug",
-      "inherits": ["debug", "sanitize"],
-      "displayName": "Sanitize+debug build config",
-      "binaryDir": "${sourceDir}/build/sandebug"
-    }
-  ],
-  "buildPresets": [
-    {
-      "name": "release",
-      "configurePreset": "release"
-    },
-    {
-      "name": "debug",
-      "configurePreset": "debug"
-    },
-    {
-      "name": "sanitize",
-      "configurePreset": "sanitize"
-    },
-    {
-      "name": "sandebug",
-      "configurePreset": "sandebug"
-    }
-  ],
-  "testPresets": [
-    {
-      "name": "release",
-      "configurePreset": "release",
-      "output": {"outputOnFailure": true, "shortProgress": true}
-    },
-    {
-      "name": "debug",
-      "configurePreset": "debug",
-      "inherits": "release"
-    },
-    {
-      "name": "sanitize",
-      "configurePreset": "sanitize",
-      "inherits": "release"
-    },
-    {
-      "name": "sandebug",
-      "configurePreset": "sandebug",
-      "inherits": "release"
-    }
-  ]
-}

CODEOWNERS

@@ -1,46 +0,0 @@
-# Code Owners
-#
-# Documents responsible people per component.
-# Listed persons will automatically be asked by GitHub to review a PR touching these paths.
-# If multiple names are listed, a review by any of them is considered sufficient by default.
-
-/.github/ @kim-em
-/RELEASES.md @kim-em
-/src/kernel/ @leodemoura
-/src/lake/ @tydeu
-/src/Lean/Compiler/ @leodemoura
-/src/Lean/Data/Lsp/ @mhuisi
-/src/Lean/Elab/Deriving/ @kim-em
-/src/Lean/Elab/Tactic/ @kim-em
-/src/Lean/Language/ @Kha
-/src/Lean/Meta/Tactic/ @leodemoura
-/src/Lean/PrettyPrinter/ @kmill
-/src/Lean/Server/ @mhuisi
-/src/Lean/Widget/ @Vtec234
-/src/Init/Data/ @kim-em
-/src/Init/Data/Array/Lemmas.lean @digama0
-/src/Init/Data/List/Lemmas.lean @digama0
-/src/Init/Data/List/BasicAux.lean @digama0
-/src/Init/Data/Array/Subarray.lean @david-christiansen
-/src/Lean/Elab/Tactic/RCases.lean @digama0
-/src/Init/RCases.lean @digama0
-/src/Lean/Elab/Tactic/Ext.lean @digama0
-/src/Init/Ext.lean @digama0
-/src/Lean/Elab/Tactic/Simpa.lean @digama0
-/src/Lean/Elab/Tactic/NormCast.lean @digama0
-/src/Lean/Meta/Tactic/NormCast.lean @digama0
-/src/Lean/Meta/Tactic/TryThis.lean @digama0
-/src/Lean/Elab/Tactic/SimpTrace.lean @digama0
-/src/Lean/Elab/Tactic/NoMatch.lean @digama0
-/src/Lean/Elab/Tactic/ShowTerm.lean @digama0
-/src/Lean/Elab/Tactic/Repeat.lean @digama0
-/src/Lean/Meta/Tactic/Repeat.lean @digama0
-/src/Lean/Meta/CoeAttr.lean @digama0
-/src/Lean/Elab/GuardMsgs.lean @digama0
-/src/Lean/Elab/Tactic/Guard.lean @digama0
-/src/Init/Guard.lean @digama0
-/src/Lean/Server/CodeActions/ @digama0
-/src/Std/ @TwoFX
-/src/Std/Tactic/BVDecide/ @hargoniX
-/src/Lean/Elab/Tactic/BVDecide/ @hargoniX
-/src/Std/Sat/ @hargoniX

CONTRIBUTING.md

@@ -1,93 +1,57 @@
-External Contribution Guidelines
-============
+# Contribution Guidelines
 
-In the past, we accepted most pull requests. This practice produced hard to maintain code, performance problems, and bugs. In order to improve the quality and maintainability of our codebase, we've established the following guidelines for external contributions.
+Thank you for your interest in contributing to Lean! There are many ways to contribute and we appreciate all of them.
 
-Helpful links
--------
+## Bug reports
 
-* [Development Setup](./doc/dev/index.md)
-* [Testing](./doc/dev/testing.md)
-* [Commit convention](./doc/dev/commit_convention.md)
+Bug reports as new issues are always welcome. Please check the existing [issues](https://github.com/leanprover/lean4/issues) first.
+Reduce the issue to a self-contained, reproducible test case.
+If you have the chance, before reporting a bug, please search existing issues, as it's possible that
+someone else has already reported your error.
+If you're not sure if something is a bug or not, feel free to file a bug anyway. You may also want to discuss it with the Lean
+community using the [lean4 Zulip channel](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4).
 
-Before You Submit a Pull Request (PR):
--------
+## Simple fixes
 
-**Start with an Issue**: Before submitting a PR, always open an issue discussing the problem you wish to solve or the feature you'd like to add. Use the prefix `RFC:` (request for comments) if you are proposing a new feature. Ask for feedback from other users. Take the time to summarize all the feedback. This allows the maintainers to evaluate your proposal more efficiently. When creating a RFC, consider the following questions:
+Simple fixes for **typos and clear bugs** are welcome.
 
-  - **User Experience**: How does this feature improve the user experience?
+## Documentation
 
-  - **Beneficiaries**: Which Lean users and projects do benefit most from this feature/change?
+Tutorial-like examples are very welcome.
+They are useful for finding rough edges and bugs in Lean 4, for highlighting new features, and for showing how to use Lean.
+If you want to store your tutorial in the Lean 4 repository to make sure future changes will not break it, we suggest the following workflow:
+* Contact one of the Lean developers on Zulip, and check whether your tutorial is a good match for the Lean 4 repository.
+* Send bug reports and report rough edges. We will work with you until the tutorial looks great.
+* Add plenty of comments and make sure others will be able to follow it.
+* Create a pull request in the Lean 4 repository. After merging, we will link it to the official documentation and make sure it becomes part of our test suite.
 
-  - **Community Feedback**: Have you sought feedback or insights from other Lean users?
+You can use `.lean` or `.md` files to create your tutorial. The `.md` files are ideal when you want to format your prose using markdown. For an example, see [this `.md` file](https://github.com/leanprover/lean4/blob/master/doc/lean3changes.md).
 
-  - **Maintainability**: Will this change streamline code maintenance or simplify its structure?
+Contributions to the reference manual are also welcome, but since Lean 4 is changing rapidly, please contact us first using Zulip
+to find out which parts are stable enough to document. We will work with you to get this kind of
+pull request merged. We are also happy to meet using Zoom, Skype or Google hangout to coordinate this kind of effort.
 
-**Understand the Project**: Familiarize yourself with the project, existing issues, and latest commits. Ensure your contribution aligns with the project's direction and priorities.
+As Lean 4 matures, other forms of documentation (e.g., doc-strings) will be welcome too.
 
-**Stay Updated**: Regularly fetch and merge changes from the main branch to ensure your branch is up-to-date and can be smoothly integrated.
+## "Help wanted"
 
-**Help wanted**: We have issues tagged with ["help wanted"](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22), if you want to contribute to the project, please take a look at them. If you are interested in one of them, post comments, ask questions, and engage with the core developers there.
+For issues marked as [`help wanted`](https://github.com/leanprover/lean4/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22), pull requests (PR) are welcome and we will work with you to get a PR merged. Some of these issues are nontrivial. If you are interested, please consider adding comments to the issue and/or messaging the Lean developers in [Zulip](https://leanprover.zulipchat.com/#).
 
-Quality Over Quantity:
------
+## Unexpected Pull Requests
 
-**Focused Changes**: Each PR should address a single, clearly-defined issue or feature. Avoid making multiple unrelated changes in a single PR.
+We have very few core developers, and we cannot review arbitrary pull requests (PRs). Moreover, many features involve subtle tradeoffs, and it may require significant time and energy to even assess a proposed design. We suggest the following workflow:
 
-**Write Tests**: Every new feature or bug fix should come with relevant tests. This ensures the robustness and reliability of the contribution.
+* First, discuss your idea with the Lean community on Zulip. Ask the community to help collect examples, document the requirements, and detect complications.
+* If there is broad support, create a detailed issue for it on the Lean 4 repository at GitHub, and tag the issue with `RFC`.
+* Ask the community for help documenting the requirements, and for collecting examples and concerns.
+* Wait for one of the core developers to give you a "go ahead". At this point, the core developers will work with you to make sure your PR gets merged.
 
-**Documentation**: Update relevant documentation, including comments in the code, to explain the logic and reasoning behind your changes.
+We don't want to waste your time by you implementing a feature and then us not being able to merge it.
 
-Coding Standards:
-----
+## How to Contribute
 
-**Follow the Code Style**: Ensure that your code follows the established coding style of the project.
-
-**Lean on Lean**: Use Lean's built-in features and libraries effectively, avoiding reinventions.
-
-**Performance**: Make sure that your changes do not introduce performance regressions. If possible, optimize the solution for speed and resource usage.
-
-PR Submission:
----
-
-**Descriptive Title and Summary**: The PR title should briefly explain the purpose of the PR. The summary should give more detailed information on what changes are made and why. Links to Zulip threads are not acceptable as a summary. You are responsible for summarizing the discussion, and getting support for it.
-
-**Follow the commit convention**: Pull requests are squash merged, and the
-commit message is taken from the pull request title and body, so make sure they adhere to the [commit convention](https://github.com/leanprover/lean4/blob/master/doc/dev/commit_convention.md). Put questions and extra information, which should not be part of the final commit message, into a first comment rather than the Pull Request description.
-Because the change will be squashed, there is no need to polish the commit messages and history on the branch.
-
-**Link to Relevant Issues**: Reference any issues that your PR addresses to provide context.
-
-**Stay Responsive**: Once the PR is submitted, stay responsive to feedback and be prepared to make necessary revisions. We will close any PR that has been inactive (no response or updates from the submitter) for more than a month.
-
-Reviews and Feedback:
-----
-
-The lean4 repo is managed by the Lean FRO's *triage team* that aims to provide initial feedback on new bug reports, PRs, and RFCs weekly.
-This feedback generally consists of prioritizing the ticket using one of the following categories:
-* label `P-high`: We will work on this issue
-* label `P-medium`: We may work on this issue if we find the time
-* label `P-low`: We are not planning to work on this issue
-* *closed*: This issue is already fixed, it is not an issue, or is not sufficiently compatible with our roadmap for the project and we will not work on it nor accept external contributions on it
-
-For *bug reports*, the listed priority reflects our commitment to fixing the issue.
-It is generally indicative but not necessarily identical to the priority an external contribution addressing this bug would receive.
-For *PRs* and *RFCs*, the priority reflects our commitment to reviewing them and getting them to an acceptable state.
-Accepted RFCs are marked with the label `RFC accepted` and afterwards assigned a new "implementation" priority as with bug reports.
-
-General guidelines for interacting with reviews and feedback:
-
-**Be Patient**: Given the limited number of full-time maintainers and the volume of PRs, reviews may take some time.
-
-**Engage Constructively**: Always approach feedback positively and constructively. Remember, reviews are about ensuring the best quality for the project, not personal criticism.
-
-**Continuous Integration**: Ensure that all CI checks pass on your PR. Failed checks will delay the review process. The maintainers will not check PRs containing failures.
-
-What to Expect:
-----
-
-**Not All PRs Get Merged**: While we appreciate every contribution, not all PRs will be merged. Ensure your changes align with the project's goals and quality standards.
-
-**Feedback is a Gift**: It helps improve the project and can also help you grow as a developer or contributor.
-
-**Community Involvement**: Engage with the Lean community on our communication channels. This can lead to better collaboration and understanding of the project's direction.
+* Always follow the [commit convention](https://leanprover.github.io/lean4/doc/dev/commit_convention.html).
+* Follow the style of the surrounding code. When in doubt, look at other files using the particular syntax as well.
+* Make sure your code is documented.
+* New features or bug fixes should come with appropriate tests.
+* Ensure all tests work before submitting a PR; see [Development Setup](https://leanprover.github.io/lean4/doc/make/index.html#development-setup) and [Fixing Tests](https://leanprover.github.io/lean4/doc/dev/fixing_tests.html).

LICENSES

@@ -1341,33 +1341,3 @@ whether future versions of the GNU Lesser General Public License shall
 apply, that proxy's public statement of acceptance of any version is
 permanent authorization for you to choose that version for the
 Library.
-==============================================================================
-CaDiCaL is under the MIT License:
-==============================================================================
-MIT License
-
-Copyright (c) 2016-2021 Armin Biere, Johannes Kepler University Linz, Austria
-Copyright (c) 2020-2021 Mathias Fleury, Johannes Kepler University Linz, Austria
-Copyright (c) 2020-2021 Nils Froleyks, Johannes Kepler University Linz, Austria
-Copyright (c) 2022-2024 Katalin Fazekas, Vienna University of Technology, Austria
-Copyright (c) 2021-2024 Armin Biere, University of Freiburg, Germany
-Copyright (c) 2021-2024 Mathias Fleury, University of Freiburg, Germany
-Copyright (c) 2023-2024 Florian Pollitt, University of Freiburg, Germany
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.

README.md

@@ -1,20 +1,17 @@
-This is the repository for **Lean 4**.
+This is the repository for **Lean 4**, which is currently being released as milestone releases towards a first stable release.
+[Lean 3](https://github.com/leanprover/lean) is still the latest stable release.
 
 # About
 
-- [Quickstart](https://lean-lang.org/lean4/doc/quickstart.html)
-- [Homepage](https://lean-lang.org)
-- [Theorem Proving Tutorial](https://lean-lang.org/theorem_proving_in_lean4/)
-- [Functional Programming in Lean](https://lean-lang.org/functional_programming_in_lean/)
-- [Manual](https://lean-lang.org/lean4/doc/)
+- [Homepage](https://leanprover.github.io)
+- [Theorem Proving Tutorial](https://leanprover.github.io/theorem_proving_in_lean4/)
+- [Manual](https://leanprover.github.io/lean4/doc/)
 - [Release notes](RELEASES.md) starting at v4.0.0-m3
-- [Examples](https://lean-lang.org/lean4/doc/examples.html)
-- [External Contribution Guidelines](CONTRIBUTING.md)
-- [FAQ](https://lean-lang.org/lean4/doc/faq.html)
+- [FAQ](https://leanprover.github.io/lean4/doc/faq.html)
 
 # Installation
 
-See [Setting Up Lean](https://lean-lang.org/lean4/doc/setup.html).
+See [Setting Up Lean](https://leanprover.github.io/lean4/doc/setup.html).
 
 # Contributing
 
@@ -22,4 +19,4 @@ Please read our [Contribution Guidelines](CONTRIBUTING.md) first.
 
 # Building from Source
 
-See [Building Lean](https://lean-lang.org/lean4/doc/make/index.html) (documentation source: [doc/make/index.md](doc/make/index.md)).
+See [Building Lean](https://leanprover.github.io/lean4/doc/make/index.html).

default.nix

@@ -0,0 +1,9 @@
+# used for `nix-shell https://github.com/leanprover/lean4/archive/master.tar.gz -A nix`
+{ nix = (import ./shell.nix {}).nix; } //
+(import (
+  fetchTarball {
+    url = "https://github.com/edolstra/flake-compat/archive/c75e76f80c57784a6734356315b306140646ee84.tar.gz";
+    sha256 = "071aal00zp2m9knnhddgr2wqzlx6i6qa1263lv1y7bdn2w20h10h"; }
+) {
+  src =  ./.;
+}).defaultNix

doc/BoolExpr.lean

@@ -1,4 +1,5 @@
-open Batteries
+import Std
+open Std
 open Lean
 
 inductive BoolExpr where
@@ -103,9 +104,9 @@ syntax entry := ident " ↦ " term:max
 syntax entry,* "⊢" term : term
 
 macro_rules
-  | `( $[$xs ↦ $vs],* ⊢ $p) =>
+  | `( $[$xs:ident ↦ $vs:term],* ⊢ $p:term ) =>
     let xs := xs.map fun x => quote x.getId.toString
-    `(denote (List.toAssocList [$[($xs, $vs)],*]) `[BExpr| $p])
+    `(denote (List.toAssocList [$[( $xs , $vs )],*]) `[BExpr| $p])
 
 #check b ↦ true ⊢ b ∨ b
 #eval  a ↦ false, b ↦ false ⊢ b ∨ a

doc/SUMMARY.md

@@ -2,44 +2,32 @@
 
 - [What is Lean](./whatIsLean.md)
 - [Tour of Lean](./tour.md)
-- [Setting Up Lean](./quickstart.md)
-  - [Extended Setup Notes](./setup.md)
-- [Theorem Proving in Lean](./tpil.md)
-- [Functional Programming in Lean](fplean.md)
-- [Examples](./examples.md)
-  - [Palindromes](examples/palindromes.lean.md)
-  - [Binary Search Trees](examples/bintree.lean.md)
-  - [A Certified Type Checker](examples/tc.lean.md)
-  - [The Well-Typed Interpreter](examples/interp.lean.md)
-  - [Dependent de Bruijn Indices](examples/deBruijn.lean.md)
-  - [Parametric Higher-Order Abstract Syntax](examples/phoas.lean.md)
+- [Setting Up Lean](./setup.md)
+  - [Quickstart](./quickstart.md)
 
 # Language Manual
-<!-- - [Using Lean](./using_lean.md) -->
-<!-- - [Lexical Structure](./lexical_structure.md) -->
-<!-- - [Expressions](./expressions.md) -->
-<!-- - [Declarations](./declarations.md) -->
+- [Using Lean](./using_lean.md)
+- [Lexical Structure](./lexical_structure.md)
+- [Expressions](./expressions.md)
+- [Declarations](./declarations.md)
 - [Organizational features](./organization.md)
   - [Sections](./sections.md)
   - [Namespaces](./namespaces.md)
   - [Implicit Arguments](./implicit.md)
   - [Auto Bound Implicit Arguments](./autobound.md)
-<!-- - [Dependent Types](./deptypes.md) -->
-<!--   - [Simple Type Theory](./simptypes.md) -->
-<!--   - [Types as objects](./typeobjs.md) -->
-<!--   - [Function Abstraction and Evaluation](./funabst.md) -->
-<!--   - [Introducing Definitions](./introdef.md) -->
-<!--   - [What makes dependent type theory dependent?](./dep.md) -->
-<!-- - [Tactics](./tactics.md) -->
+- [Dependent Types](./deptypes.md)
+  - [Simple Type Theory](./simptypes.md)
+  - [Types as objects](./typeobjs.md)
+  - [Function Abstraction and Evaluation](./funabst.md)
+  - [Introducing Definitions](./introdef.md)
+  - [What makes dependent type theory dependent?](./dep.md)
+- [Tactics](./tactics.md)
 - [Syntax Extensions](./syntax.md)
   - [The `do` Notation](./do.md)
+  - [User-defined notation](./notation.md)
   - [String Interpolation](./stringinterp.md)
-  - [User-Defined Notation](./notation.md)
   - [Macro Overview](./macro_overview.md)
-  - [Elaborators](./elaborators.md)
-  - [Examples](./syntax_examples.md)
-    - [Balanced Parentheses](./syntax_example.md)
-    - [Arithmetic DSL](./metaprogramming-arith.md)
+  - [A Guided Example](./syntax_example.md)
 - [Declaring New Types](./decltypes.md)
   - [Enumerated Types](./enum.md)
   - [Inductive Types](./inductive.md)
@@ -59,36 +47,26 @@
   - [Thunk](./thunk.md)
   - [Task and Thread](./task.md)
 - [Functions](./functions.md)
-- [Monads](./monads/intro.md)
-  - [Functor](./monads/functors.lean.md)
-  - [Applicative](./monads/applicatives.lean.md)
-  - [Monad](./monads/monads.lean.md)
-  - [Reader](./monads/readers.lean.md)
-  - [State](./monads/states.lean.md)
-  - [Except](./monads/except.lean.md)
-  - [Transformers](./monads/transformers.lean.md)
-  - [Laws](./monads/laws.lean.md)
 
 # Other
 
 - [Frequently Asked Questions](./faq.md)
 - [Significant Changes from Lean 3](./lean3changes.md)
 - [Syntax Highlighting Lean in LaTeX](./syntax_highlight_in_latex.md)
-- [User Widgets](examples/widgets.lean.md)
-- [Semantic Highlighting](./semantic_highlighting.md)
 
 # Development
 
 - [Development Guide](./dev/index.md)
+- [Commit Convention](./dev/commit_convention.md)
 - [Building Lean](./make/index.md)
   - [Ubuntu Setup](./make/ubuntu.md)
   - [macOS Setup](./make/osx-10.9.md)
   - [Windows MSYS2 Setup](./make/msys2.md)
   - [Windows with WSL](./make/wsl.md)
-- [Bootstrapping](./dev/bootstrap.md)
-- [Testing](./dev/testing.md)
-- [Debugging](./dev/debugging.md)
-- [Commit Convention](./dev/commit_convention.md)
-- [Release checklist](./dev/release_checklist.md)
-- [Building This Manual](./dev/mdbook.md)
+  - [Nix Setup (*Experimental*)](./make/nix.md)
 - [Foreign Function Interface](./dev/ffi.md)
+- [Unit Testing](./dev/testing.md)
+- [Building This Manual](./dev/mdbook.md)
+- [Fixing Tests](./dev/fixing_tests.md)
+- [Debugging](./dev/debugging.md)
+- [C++ Coding Style](./dev/cpp_coding_style.md)

doc/alectryon.css

@@ -1,786 +0,0 @@
-@charset "UTF-8";
-/*
-Copyright © 2019 Clément Pit-Claudel
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-*/
-
-/*******************************/
-/* CSS reset for .alectryon-io */
-/*******************************/
-
-.content {
-    /*
-    Use `initial` instead of `contents` to avoid a browser bug which removes
-    the element from the accessibility tree.
-    https://developer.mozilla.org/en-US/docs/Web/CSS/display#display_contents
-     */
-    display: initial;
-}
-
-.alectryon-io blockquote {
-    line-height: inherit;
-}
-
-.alectryon-io blockquote:after {
-    display: none;
-}
-
-.alectryon-io label {
-    display: inline;
-    font-size: inherit;
-    margin: 0;
-}
-
-.alectryon-io a {
-    text-decoration: none !important;
-    font-style: oblique !important;
-    color: unset;
-}
-
-/* Undo <small> and <blockquote>, added to improve RSS rendering. */
-
-.alectryon-io small.alectryon-output,
-.alectryon-io small.alectryon-type-info {
-    font-size: inherit;
-}
-
-.alectryon-io blockquote.alectryon-goal,
-.alectryon-io blockquote.alectryon-message {
-    font-weight: normal;
-    font-size: inherit;
-}
-
-/***************/
-/* Main styles */
-/***************/
-
-.alectryon-coqdoc .doc .code,
-.alectryon-coqdoc .doc .comment,
-.alectryon-coqdoc .doc .inlinecode,
-.alectryon-mref,
-.alectryon-block, .alectryon-io,
-.alectryon-toggle-label, .alectryon-banner {
-    font-family: "Source Code Pro", Consolas, "Ubuntu Mono", Menlo, "DejaVu Sans Mono", monospace, monospace !important;
-    font-size: 0.875em;
-    font-feature-settings: "COQX" 1 /* Coq ligatures */, "XV00" 1 /* Legacy */, "calt" 1 /* Fallback */;
-    line-height: initial;
-}
-
-.alectryon-io, .alectryon-block, .alectryon-toggle-label, .alectryon-banner {
-    overflow: visible;
-    overflow-wrap: break-word;
-    position: relative;
-    white-space: pre-wrap;
-}
-
-/*
-CoqIDE doesn't turn off the unicode bidirectional algorithm (and PG simply
-respects the user's `bidi-display-reordering` setting), so don't turn it off
-here either.  But beware unexpected results like `Definition test_אב := 0.`
-
-.alectryon-io span {
-    direction: ltr;
-    unicode-bidi: bidi-override;
-}
-
-In any case, make an exception for comments:
-
-.highlight .c {
-    direction: embed;
-    unicode-bidi: initial;
-}
-*/
-
-.alectryon-mref,
-.alectryon-mref-marker {
-    align-self: center;
-    box-sizing: border-box;
-    display: inline-block;
-    font-size: 80%;
-    font-weight: bold;
-    line-height: 1;
-    box-shadow: 0 0 0 1pt black;
-    padding: 1pt 0.3em;
-    text-decoration: none;
-}
-
-.alectryon-block .alectryon-mref-marker,
-.alectryon-io .alectryon-mref-marker {
-    user-select: none;
-    margin: -0.25em 0 -0.25em 0.5em;
-}
-
-.alectryon-inline .alectryon-mref-marker {
-    margin: -0.25em 0.15em -0.25em 0.625em; /* 625 = 0.5em / 80% */
-}
-
-.alectryon-mref {
-    color: inherit;
-    margin: -0.5em 0.25em;
-}
-
-.alectryon-goal:target .goal-separator .alectryon-mref-marker,
-:target > .alectryon-mref-marker {
-    animation: blink 0.2s step-start 0s 3 normal none;
-    background-color: #fcaf3e;
-    position: relative;
-}
-
-@keyframes blink {
-    50% {
-        box-shadow: 0 0 0 3pt #fcaf3e, 0 0 0 4pt black;
-        z-index: 10;
-    }
-}
-
-.alectryon-toggle,
-.alectryon-io .alectryon-extra-goal-toggle {
-    display: none;
-}
-
-.alectryon-bubble,
-.alectryon-io label,
-.alectryon-toggle-label {
-    cursor: pointer;
-}
-
-.alectryon-toggle-label {
-    display: block;
-    font-size: 0.8em;
-}
-
-.alectryon-io .alectryon-input {
-    padding: 0.1em 0; /* Enlarge the hitbox slightly to fill interline gaps */
-}
-
-.alectryon-io .alectryon-token {
-    white-space: pre-wrap;
-    display: inline;
-}
-
-.alectryon-io .alectryon-sentence.alectryon-target .alectryon-input {
-    /* FIXME if keywords were ‘bolder’ we wouldn't need !important */
-    font-weight: bold !important; /* Use !important to avoid a * selector */
-}
-
-.alectryon-bubble:before,
-.alectryon-toggle-label:before,
-.alectryon-io label.alectryon-input:after,
-.alectryon-io .alectryon-goal > label:before {
-    border: 1px solid #babdb6;
-    border-radius: 1em;
-    box-sizing: border-box;
-    content: '';
-    display: inline-block;
-    font-weight: bold;
-    height: 0.25em;
-    margin-bottom: 0.15em;
-    vertical-align: middle;
-    width: 0.75em;
-}
-
-.alectryon-toggle-label:before,
-.alectryon-io .alectryon-goal > label:before {
-    margin-right: 0.25em;
-}
-
-.alectryon-io .alectryon-goal > label:before {
-    margin-top: 0.125em;
-}
-
-.alectryon-io label.alectryon-input {
-    padding-right: 1em; /* Prevent line wraps before the checkbox bubble */
-}
-
-.alectryon-io label.alectryon-input:after {
-    margin-left: 0.25em;
-    margin-right: -1em; /* Compensate for the anti-wrapping space */
-}
-
-.alectryon-failed {
-    /* Underlines are broken in Chrome (they reset at each element boundary)… */
-    /* text-decoration: red wavy underline; */
-    /* … but it isn't too noticeable with dots */
-    text-decoration: red dotted underline;
-    text-decoration-skip-ink: none;
-    /* Chrome prints background images in low resolution, yielding a blurry underline */
-    /* background: bottom / 0.3em auto repeat-x url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAyLjY0NiAxLjg1MiIgaGVpZ2h0PSI4IiB3aWR0aD0iMTAiPjxwYXRoIGQ9Ik0wIC4yNjVjLjc5NCAwIC41MyAxLjMyMiAxLjMyMyAxLjMyMi43OTQgMCAuNTMtMS4zMjIgMS4zMjMtMS4zMjIiIGZpbGw9Im5vbmUiIHN0cm9rZT0icmVkIiBzdHJva2Utd2lkdGg9Ii41MjkiLz48L3N2Zz4=); */
-}
-
-/* Wrapping :hover rules in a media query ensures that tapping a Coq sentence
-   doesn't trigger its :hover state (otherwise, on mobile, tapping a sentence to
-   hide its output causes it to remain visible (its :hover state gets triggered.
-   We only do it for the default style though, since other styles don't put the
-   output over the main text, so showing too much is not an issue. */
-@media (any-hover: hover) {
-    .alectryon-bubble:hover:before,
-    .alectryon-toggle-label:hover:before,
-    .alectryon-io label.alectryon-input:hover:after {
-        background: #eeeeec;
-    }
-
-    .alectryon-io label.alectryon-input:hover {
-        text-decoration: underline dotted #babdb6;
-	    text-shadow: 0 0 1px rgb(46, 52, 54, 0.3); /* #2e3436 + opacity */
-    }
-
-    .alectryon-io .alectryon-sentence:hover .alectryon-output,
-    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper,
-    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper {
-        z-index: 2; /* Place hovered goals above .alectryon-sentence.alectryon-target ones */
-    }
-}
-
-.alectryon-toggle:checked + .alectryon-toggle-label:before,
-.alectryon-io .alectryon-sentence > .alectryon-toggle:checked + label.alectryon-input:after,
-.alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal > label:before {
-    background-color: #babdb6;
-    border-color: #babdb6;
-}
-
-/* Disable clicks on sentences when the document-wide toggle is set. */
-.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input {
-    cursor: unset;
-    pointer-events: none;
-}
-
-/* Hide individual checkboxes when the document-wide toggle is set. */
-.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input:after {
-    display: none;
-}
-
-/* .alectryon-output is displayed by toggles, :hover, and .alectryon-target rules */
-.alectryon-io .alectryon-output {
-    box-sizing: border-box;
-    display: none;
-    left: 0;
-    right: 0;
-    position: absolute;
-    padding: 0.25em 0;
-    overflow: visible; /* Let box-shadows overflow */
-    z-index: 1; /* Default to an index lower than that used by :hover */
-}
-
-.alectryon-io .alectryon-type-info-wrapper {
-    position: absolute;
-    display: inline-block;
-    width: 100%;
-}
-
-.alectryon-io .alectryon-type-info-wrapper.full-width {
-    left: 0;
-    min-width: 100%;
-    max-width: 100%;
-}
-
-.alectryon-io .alectryon-type-info .goal-separator {
-    height: unset;
-    margin-top: 0em;
-}
-
-.alectryon-io .alectryon-type-info-wrapper .alectryon-type-info {
-    box-sizing: border-box;
-    bottom: 100%;
-    position: absolute;
-    /*padding: 0.25em 0;*/
-    visibility: hidden;
-    overflow: visible; /* Let box-shadows overflow */
-    z-index: 1; /* Default to an index lower than that used by :hover */
-    white-space: pre-wrap !important;
-}
-
-.alectryon-io .alectryon-type-info-wrapper .alectryon-type-info .alectryon-goal.alectryon-docstring {
-    white-space: pre-wrap !important;
-}
-
-@media (any-hover: hover) { /* See note above about this @media query */
-    .alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) {
-        display: block;
-    }
-
-    .alectryon-io.output-hidden .alectryon-sentence:hover .alectryon-output:not(:hover) {
-        display: none !important;
-    }
-
-    .alectryon-io.type-info-hidden .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info,
-    .alectryon-io.type-info-hidden .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info {
-        /*visibility: hidden !important;*/
-    }
-
-    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info,
-    .alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info {
-        visibility: visible;
-        transition-delay: 0.5s;
-    }
-}
-
-.alectryon-io .alectryon-sentence.alectryon-target .alectryon-output {
-    display: block;
-}
-
-/* Indicate active (hovered or targeted) goals with a shadow. */
-.alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-messages,
-.alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-messages,
-.alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-goals,
-.alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-goals,
-.alectryon-io .alectryon-token:hover .alectryon-type-info-wrapper .alectryon-type-info {
-    box-shadow: 2px 2px 2px gray;
-}
-
-.alectryon-io .alectryon-extra-goals .alectryon-goal .goal-hyps {
-    display: none;
-}
-
-.alectryon-io .alectryon-extra-goals .alectryon-extra-goal-toggle:not(:checked) + .alectryon-goal label.goal-separator hr {
-    /* Dashes indicate that the hypotheses are hidden */
-    border-top-style: dashed;
-}
-
-
-/* Show just a small preview of the other goals; this is undone by the
-   "extra-goal" toggle and by :hover and .alectryon-target in windowed mode. */
-.alectryon-io .alectryon-extra-goals .alectryon-goal .goal-conclusion {
-    max-height: 5.2em;
-    overflow-y: auto;
-    /* Combining ‘overflow-y: auto’ with ‘display: inline-block’ causes extra space
-       to be added below the box. ‘vertical-align: middle’ gets rid of it. */
-    vertical-align: middle;
-}
-
-.alectryon-io .alectryon-goals,
-.alectryon-io .alectryon-messages {
-    background: #f6f7f6;
-	/*border: thin solid #d3d7cf; /* Convenient when pre's background is already #EEE */
-    display: block;
-    padding: 0.25em;
-}
-
-.alectryon-message::before {
-    content: '';
-    float: right;
-    /* etc/svg/square-bubble-xl.svg */
-    background: url("data:image/svg+xml,%3Csvg width='14' height='14' viewBox='0 0 3.704 3.704' xmlns='http://www.w3.org/2000/svg'%3E%3Cg fill-rule='evenodd' stroke='%23000' stroke-width='.264'%3E%3Cpath d='M.794.934h2.115M.794 1.463h1.455M.794 1.992h1.852'/%3E%3C/g%3E%3Cpath d='M.132.14v2.646h.794v.661l.926-.661h1.72V.14z' fill='none' stroke='%23000' stroke-width='.265'/%3E%3C/svg%3E") top right no-repeat;
-    height: 14px;
-    width: 14px;
-}
-
-.alectryon-toggle:checked + label + .alectryon-container {
-    width: unset;
-}
-
-/* Show goals when a toggle is set */
-.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input + .alectryon-output,
-.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output {
-    display: block;
-    position: static;
-    width: unset;
-    background: unset; /* Override the backgrounds set in floating in windowed mode */
-    padding: 0.25em 0; /* Re-assert so that later :hover rules don't override this padding */
-}
-
-.alectryon-toggle:checked + label + .alectryon-container label.alectryon-input + .alectryon-output .goal-hyps,
-.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output .goal-hyps {
-    /* Overridden back in windowed style */
-    flex-flow: row wrap;
-    justify-content: flex-start;
-}
-
-.alectryon-toggle:checked + label + .alectryon-container .alectryon-sentence .alectryon-output > div,
-.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output > div {
-    display: block;
-}
-
-.alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal .goal-hyps {
-    display: flex;
-}
-
-.alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal .goal-conclusion {
-    max-height: unset;
-    overflow-y: unset;
-}
-
-.alectryon-toggle:checked + label + .alectryon-container .alectryon-sentence > .alectryon-toggle ~ .alectryon-wsp,
-.alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-wsp {
-    display: none;
-}
-
-.alectryon-io .alectryon-messages,
-.alectryon-io .alectryon-message,
-.alectryon-io .alectryon-goals,
-.alectryon-io .alectryon-goal,
-.alectryon-io .goal-hyps > span,
-.alectryon-io .goal-conclusion {
-    border-radius: 0.15em;
-}
-
-.alectryon-io .alectryon-goal,
-.alectryon-io .alectryon-message {
-    align-items: center;
-    background: #f6f7f6;
-    border: 0em;
-    display: block;
-    flex-direction: column;
-    margin: 0.25em;
-    padding: 0.5em;
-    position: relative;
-}
-
-.alectryon-io .goal-hyps {
-    align-content: space-around;
-    align-items: baseline;
-    display: flex;
-    flex-flow: column nowrap; /* re-stated in windowed mode */
-    justify-content: space-around;
-    /* LATER use a ‘gap’ property instead of margins once supported */
-    margin: -0.15em -0.25em; /* -0.15em to cancel the item spacing */
-    padding-bottom: 0.35em; /* 0.5em-0.15em to cancel the 0.5em of .goal-separator */
-}
-
-.alectryon-io .goal-hyps > br {
-    display: none; /* Only for RSS readers */
-}
-
-.alectryon-io .goal-hyps > span,
-.alectryon-io .goal-conclusion {
-    /*background: #eeeeec;*/
-    display: inline-block;
-    padding: 0.15em 0.35em;
-}
-
-.alectryon-io .goal-hyps > span {
-    align-items: baseline;
-    display: inline-flex;
-    margin: 0.15em 0.25em;
-}
-
-.alectryon-block var,
-.alectryon-inline var,
-.alectryon-io .goal-hyps > span > var {
-    font-weight: 600;
-    font-style: unset;
-}
-
-.alectryon-io .goal-hyps > span > var {
-    /* Shrink the list of names, but let it grow as long as space is available. */
-    flex-basis: min-content;
-    flex-grow: 1;
-}
-
-.alectryon-io .goal-hyps > span b {
-    font-weight: 600;
-    margin: 0 0 0 0.5em;
-    white-space: pre;
-}
-
-.alectryon-io .hyp-body,
-.alectryon-io .hyp-type {
-    display: flex;
-    align-items: baseline;
-}
-
-.alectryon-io .goal-separator {
-    align-items: center;
-    display: flex;
-    flex-direction: row;
-    height: 1em; /* Fixed height to ignore goal name and markers */
-    margin-top: -0.5em; /* Compensated in .goal-hyps when shown */
-}
-
-.alectryon-io .goal-separator hr {
-    border: none;
-    border-top: thin solid #555753;
-    display: block;
-    flex-grow: 1;
-    margin: 0;
-}
-
-.alectryon-io .goal-separator .goal-name {
-    font-size: 0.75em;
-    margin-left: 0.5em;
-}
-
-/**********/
-/* Banner */
-/**********/
-
-.alectryon-banner {
-    background: #eeeeec;
-    border: 1px solid #babcbd;
-    font-size: 0.75em;
-    padding: 0.25em;
-    text-align: center;
-    margin: 1em 0;
-}
-
-.alectryon-banner a {
-    cursor: pointer;
-    text-decoration: underline;
-}
-
-.alectryon-banner kbd {
-    background: #d3d7cf;
-    border-radius: 0.15em;
-    border: 1px solid #babdb6;
-    box-sizing: border-box;
-    display: inline-block;
-    font-family: inherit;
-    font-size: 0.9em;
-    height: 1.3em;
-    line-height: 1.2em;
-    margin: -0.25em 0;
-    padding: 0 0.25em;
-    vertical-align: middle;
-}
-
-/**********/
-/* Toggle */
-/**********/
-
-.alectryon-toggle-label {
-    margin: 1rem 0;
-}
-
-/******************/
-/* Floating style */
-/******************/
-
-/* If there's space, display goals to the right of the code, not below it. */
-@media (min-width: 80rem) {
-    /* Unlike the windowed case, we don't want to move output blocks to the side
-       when they are both :checked and -targeted, since it gets confusing as
-       things jump around; hence the commented-output part of the selector,
-       which would otherwise increase specificity */
-    .alectryon-floating .alectryon-sentence.alectryon-target /* > .alectryon-toggle ~ */ .alectryon-output,
-    .alectryon-floating .alectryon-sentence:hover .alectryon-output {
-        top: 0;
-        left: 100%;
-        right: -100%;
-        padding: 0 0.5em;
-        position:  absolute;
-    }
-
-    .alectryon-floating .alectryon-output {
-        min-height: 100%;
-    }
-
-    .alectryon-floating .alectryon-sentence:hover .alectryon-output {
-        background: white; /* Ensure that short goals hide long ones */
-    }
-
-    /* This odd margin-bottom property prevents the sticky div from bumping
-       against the bottom of its container (.alectryon-output).  The alternative
-       would be enlarging .alectryon-output, but that would cause overflows,
-       enlarging scrollbars and yielding scrolling towards the bottom of the
-       page.  Doing things this way instead makes it possible to restrict
-       .alectryon-output to a reasonable size (100%, through top = bottom = 0).
-       See also https://stackoverflow.com/questions/43909940/. */
-    /* See note on specificity above */
-    .alectryon-floating .alectryon-sentence.alectryon-target /* > .alectryon-toggle ~ */ .alectryon-output > div,
-    .alectryon-floating .alectryon-sentence:hover .alectryon-output > div {
-        margin-bottom: -200%;
-        position: sticky;
-        top: 0;
-    }
-
-    .alectryon-floating .alectryon-toggle:checked + label + .alectryon-container .alectryon-sentence .alectryon-output > div,
-    .alectryon-floating .alectryon-io .alectryon-sentence > .alectryon-toggle:checked ~ .alectryon-output > div {
-        margin-bottom: unset; /* Undo the margin */
-    }
-
-    /* Float underneath the current fragment
-    @media (max-width: 80rem) {
-        .alectryon-floating .alectryon-output {
-            top: 100%;
-        }
-    } */
-}
-
-/********************/
-/* Multi-pane style */
-/********************/
-
-.alectryon-windowed {
-    border: 0 solid #2e3436;
-    box-sizing: border-box;
-}
-
-.alectryon-windowed .alectryon-sentence:hover .alectryon-output {
-    background: white; /* Ensure that short goals hide long ones */
-}
-
-.alectryon-windowed .alectryon-output {
-    position: fixed; /* Overwritten by the ‘:checked’ rules */
-}
-
-/* See note about specificity below */
-.alectryon-windowed .alectryon-sentence:hover .alectryon-output,
-.alectryon-windowed .alectryon-sentence.alectryon-target > .alectryon-toggle ~ .alectryon-output {
-    padding: 0.5em;
-    overflow-y: auto; /* Windowed contents may need to scroll */
-}
-
-.alectryon-windowed .alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-messages,
-.alectryon-windowed .alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-messages,
-.alectryon-windowed .alectryon-io .alectryon-sentence:hover .alectryon-output:not(:hover) .alectryon-goals,
-.alectryon-windowed .alectryon-io .alectryon-sentence.alectryon-target .alectryon-output  .alectryon-goals {
-    box-shadow: none; /* A shadow is unnecessary here and incompatible with overflow-y set to auto */
-}
-
-.alectryon-windowed .alectryon-io .alectryon-sentence.alectryon-target .alectryon-output .goal-hyps {
-    /* Restated to override the :checked style */
-    flex-flow: column nowrap;
-    justify-content: space-around;
-}
-
-
-.alectryon-windowed .alectryon-sentence.alectryon-target .alectryon-extra-goals .alectryon-goal .goal-conclusion
-/* Like .alectryon-io .alectryon-extra-goal-toggle:checked + .alectryon-goal .goal-conclusion */ {
-    max-height: unset;
-    overflow-y: unset;
-}
-
-.alectryon-windowed .alectryon-output > div {
-    display: flex; /* Put messages after goals */
-    flex-direction: column-reverse;
-}
-
-/*********************/
-/* Standalone styles */
-/*********************/
-
-.alectryon-standalone {
-    font-family: 'IBM Plex Serif', 'PT Serif', 'Merriweather', 'DejaVu Serif', serif;
-    line-height: 1.5;
-}
-
-@media screen and (min-width: 50rem) {
-    html.alectryon-standalone {
-        /* Prevent flickering when hovering a block causes scrollbars to appear. */
-        margin-left: calc(100vw - 100%);
-        margin-right: 0;
-    }
-}
-
-/* Coqdoc */
-
-.alectryon-coqdoc .doc .code,
-.alectryon-coqdoc .doc .inlinecode,
-.alectryon-coqdoc .doc .comment {
-    display: inline;
-}
-
-.alectryon-coqdoc .doc .comment {
-    color: #eeeeec;
-}
-
-.alectryon-coqdoc .doc .paragraph {
-    height: 0.75em;
-}
-
-/* Centered, Floating */
-
-.alectryon-standalone .alectryon-centered,
-.alectryon-standalone .alectryon-floating {
-    max-width: 50rem;
-    margin: auto;
-}
-
-@media (min-width: 80rem) {
-    .alectryon-standalone .alectryon-floating {
-        max-width: 80rem;
-    }
-
-    .alectryon-standalone .alectryon-floating > * {
-        width: 50%;
-        margin-left: 0;
-    }
-}
-
-/* Windowed */
-
-.alectryon-standalone .alectryon-windowed {
-    display: block;
-    margin: 0;
-    overflow-y: auto;
-    position: absolute;
-    padding: 0 1em;
-}
-
-.alectryon-standalone .alectryon-windowed > * {
-    /* Override properties of docutils_basic.css */
-    margin-left: 0;
-    max-width: unset;
-}
-
-.alectryon-standalone .alectryon-windowed .alectryon-io {
-    box-sizing: border-box;
-    width: 100%;
-}
-
-/* No need to predicate the ‘:hover’ rules below on ‘:not(:checked)’, since ‘left’,
-   ‘right’, ‘top’, and ‘bottom’ will be inactived by the :checked rules setting
-   ‘position’ to ‘static’ */
-
-
-/* Specificity: We want the output to stay inline when hovered while unfolded
-   (:checked), but we want it to move when it's targeted (i.e. when the user
-   is browsing goals one by one using the keyboard, in which case we want to
-   goals to appear in consistent locations).  The selectors below ensure
-   that :hover < :checked < -targeted in terms of specificity. */
-/* LATER: Reimplement this stuff with CSS variables */
-.alectryon-windowed .alectryon-sentence.alectryon-target > .alectryon-toggle ~ .alectryon-output {
-    position: fixed;
-}
-
-@media screen and (min-width: 60rem) {
-    .alectryon-standalone .alectryon-windowed {
-        border-right-width: thin;
-        bottom: 0;
-        left: 0;
-        right: 50%;
-        top: 0;
-    }
-
-    .alectryon-standalone .alectryon-windowed .alectryon-sentence:hover .alectryon-output,
-    .alectryon-standalone .alectryon-windowed .alectryon-sentence.alectryon-target .alectryon-output {
-        bottom: 0;
-        left: 50%;
-        right: 0;
-        top: 0;
-    }
-}
-
-@media screen and (max-width: 60rem) {
-    .alectryon-standalone .alectryon-windowed {
-        border-bottom-width: 1px;
-        bottom: 40%;
-        left: 0;
-        right: 0;
-        top: 0;
-    }
-
-    .alectryon-standalone .alectryon-windowed .alectryon-sentence:hover .alectryon-output,
-    .alectryon-standalone .alectryon-windowed .alectryon-sentence.alectryon-target .alectryon-output {
-        bottom: 0;
-        left: 0;
-        right: 0;
-        top: 60%;
-    }
-}

doc/alectryon.js

@@ -1,190 +0,0 @@
-var Alectryon;
-(function(Alectryon) {
-    (function (slideshow) {
-        function anchor(sentence) { return "#" + sentence.id; }
-
-        function current_sentence() { return slideshow.sentences[slideshow.pos]; }
-
-        function unhighlight() {
-            var sentence = current_sentence();
-            if (sentence) sentence.classList.remove("alectryon-target");
-            slideshow.pos = -1;
-        }
-
-        function highlight(sentence) {
-            sentence.classList.add("alectryon-target");
-        }
-
-        function scroll(sentence) {
-            // Put the top of the current fragment close to the top of the
-            // screen, but scroll it out of view if showing it requires pushing
-            // the sentence past half of the screen.  If sentence is already in
-            // a reasonable position, don't move.
-            var parent = sentence.parentElement;
-            /* We want to scroll the whole document, so start at root… */
-            while (parent && !parent.classList.contains("alectryon-root"))
-                parent = parent.parentElement;
-            /* … and work up from there to find a scrollable element.
-               parent.scrollHeight can be greater than parent.clientHeight
-               without showing scrollbars, so we add a 10px buffer. */
-            while (parent && parent.scrollHeight <= parent.clientHeight + 10)
-                parent = parent.parentElement;
-            /* <body> and <html> elements can have their client rect overflow
-             * the window if their height is unset, so scroll the window
-             * instead */
-            if (parent && (parent.nodeName == "BODY" || parent.nodeName == "HTML"))
-                parent = null;
-
-            var rect = function(e) { return e.getBoundingClientRect(); };
-            var parent_box = parent ? rect(parent) : { y: 0, height: window.innerHeight },
-                sentence_y = rect(sentence).y - parent_box.y,
-                fragment_y = rect(sentence.parentElement).y - parent_box.y;
-
-            // The assertion below sometimes fails for the first element in a block.
-            // console.assert(sentence_y >= fragment_y);
-
-            if (sentence_y < 0.1 * parent_box.height ||
-                sentence_y > 0.7 * parent_box.height) {
-                (parent || window).scrollBy(
-                    0, Math.max(sentence_y - 0.5 * parent_box.height,
-                                fragment_y - 0.1 * parent_box.height));
-            }
-        }
-
-        function highlighted(pos) {
-            return slideshow.pos == pos;
-        }
-
-        function navigate(pos, inhibitScroll) {
-            unhighlight();
-            slideshow.pos = Math.min(Math.max(pos, 0), slideshow.sentences.length - 1);
-            var sentence = current_sentence();
-            highlight(sentence);
-            if (!inhibitScroll)
-                scroll(sentence);
-        }
-
-        var keys = {
-            PAGE_UP: 33,
-            PAGE_DOWN: 34,
-            ARROW_UP: 38,
-            ARROW_DOWN: 40,
-            h: 72, l: 76, p: 80, n: 78
-        };
-
-        function onkeydown(e) {
-            e = e || window.event;
-            if (e.ctrlKey || e.metaKey) {
-                if (e.keyCode == keys.ARROW_UP)
-                    slideshow.previous();
-                else if (e.keyCode == keys.ARROW_DOWN)
-                    slideshow.next();
-                else
-                    return;
-            } else {
-                // if (e.keyCode == keys.PAGE_UP || e.keyCode == keys.p || e.keyCode == keys.h)
-                //     slideshow.previous();
-                // else if (e.keyCode == keys.PAGE_DOWN || e.keyCode == keys.n || e.keyCode == keys.l)
-                //     slideshow.next();
-                // else
-                return;
-            }
-            e.preventDefault();
-        }
-
-        function start() {
-            slideshow.navigate(0);
-        }
-
-        function toggleHighlight(idx) {
-            if (highlighted(idx))
-                unhighlight();
-            else
-                navigate(idx, true);
-        }
-
-        function handleClick(evt) {
-            if (evt.ctrlKey || evt.metaKey) {
-                var sentence = evt.currentTarget;
-
-                // Ensure that the goal is shown on the side, not inline
-                var checkbox = sentence.getElementsByClassName("alectryon-toggle")[0];
-                if (checkbox)
-                    checkbox.checked = false;
-
-                toggleHighlight(sentence.alectryon_index);
-                evt.preventDefault();
-            }
-        }
-
-        function init() {
-            document.onkeydown = onkeydown;
-            slideshow.pos = -1;
-            slideshow.sentences = Array.from(document.getElementsByClassName("alectryon-sentence"));
-            slideshow.sentences.forEach(function (s, idx) {
-                s.addEventListener('click', handleClick, false);
-                s.alectryon_index = idx;
-            });
-        }
-
-        slideshow.start = start;
-        slideshow.end = unhighlight;
-        slideshow.navigate = navigate;
-        slideshow.next = function() { navigate(slideshow.pos + 1); };
-        slideshow.previous = function() { navigate(slideshow.pos + -1); };
-        window.addEventListener('DOMContentLoaded', init);
-    })(Alectryon.slideshow || (Alectryon.slideshow = {}));
-
-    (function (styles) {
-        var styleNames = ["centered", "floating", "windowed"];
-
-        function className(style) {
-            return "alectryon-" + style;
-        }
-
-        function setStyle(style) {
-            var root = document.getElementsByClassName("alectryon-root")[0];
-            styleNames.forEach(function (s) {
-                root.classList.remove(className(s)); });
-            root.classList.add(className(style));
-        }
-
-        function init() {
-            var banner = document.getElementsByClassName("alectryon-banner")[0];
-            if (banner) {
-                banner.append(" Style: ");
-                styleNames.forEach(function (styleName, idx) {
-                    var s = styleName;
-                    var a = document.createElement("a");
-                    a.onclick = function() { setStyle(s); };
-                    a.append(styleName);
-                    if (idx > 0) banner.append("; ");
-                    banner.appendChild(a);
-                });
-                banner.append(".");
-            }
-        }
-
-        window.addEventListener('DOMContentLoaded', init);
-
-        styles.setStyle = setStyle;
-    })(Alectryon.styles || (Alectryon.styles = {}));
-})(Alectryon || (Alectryon = {}));
-
-function setHidden(elements, isVisible, token) {
-    for (let i = 0; i < elements.length; i++) {
-        if (isVisible) {
-            elements[i].classList.remove(token)
-        } else {
-            elements[i].classList.add(token)
-        }
-    }
-}
-
-function toggleShowTypes(checkbox) {
-    setHidden(document.getElementsByClassName("alectryon-io"), checkbox.checked, "type-info-hidden")
-}
-
-function toggleShowGoals(checkbox) {
-    setHidden(document.getElementsByClassName("alectryon-io"), checkbox.checked, "output-hidden")
-}

doc/array.md

@@ -39,17 +39,16 @@ To create an array of size `n` in which all the elements are initialized to some
 
 You can access array elements by using brackets (`[` and `]`).
 ```lean
-def f (a : Array Nat) (i : Fin a.size) :=
-  a[i] + a[i]
-```
-Note that the index `i` has type `Fin a.size`, i.e., it is natural number less than `a.size`.
-You can also write
-```lean
-def f (a : Array Nat) (i : Nat) (h  : i < a.size) :=
-  a[i] + a[i]
+#eval #['a', 'b', 'c'][1]
+-- 'b'
+
+def getThird (xs : Array Nat) : Nat :=
+  xs[2]
+
+#eval getThird #[10, 20, 30, 40]
+-- 30
 ```
 The bracket operator is whitespace sensitive.
-
 ```lean
 def f (xs : List Nat) : List Nat :=
   xs ++ xs
@@ -57,21 +56,7 @@ def f (xs : List Nat) : List Nat :=
 def as : Array Nat :=
   #[1, 2, 3, 4]
 
-def idx : Fin 4 :=
-  2
-
 #eval f [1, 2, 3] -- This is a function application
 
-#eval as[idx] -- This is an array access
-```
-The notation `a[i]` has two variants: `a[i]!` and `a[i]?`. In both cases, `i` has type `Nat`. The first one
-produces a panic error message if the index `i` is out of bounds. The latter returns an `Option` type.
-
-```lean
-#eval #['a', 'b', 'c'][1]?
--- some 'b'
-#eval #['a', 'b', 'c'][5]?
--- none
-#eval #['a', 'b', 'c'][1]!
--- 'b!
+#eval as[2] -- This is an array access
 ```

doc/autobound.md

@@ -43,5 +43,3 @@ set_option autoImplicit false
 -- def compose (g : β → γ) (f : α → β) (x : α) : γ :=
 --   g (f x)
 ```
-The Lean language server provides [semantic highlighting](./semantic_highlighting.md) information to editors, and it provides
-visual feedback whether an identifier has been interpreted as an auto bound implicit argument.

doc/bin/README.md

@@ -11,4 +11,4 @@ the following command executes a simple set of examples
 
 % bin/lean examples/ex.lean
 
-For more information on Lean and supported editors, please see https://lean-lang.org/documentation/.
+For more information on Lean and supported editors, please see https://leanprover.github.io/documentation/.

doc/book.toml

@@ -10,12 +10,6 @@ build-dir = "out"
 
 [output.html]
 git-repository-url = "https://github.com/leanprover/lean4"
-additional-css = ["alectryon.css", "pygments.css"]
-additional-js = ["alectryon.js"]
-
-[output.html.fold]
-enable = true
-level = 0
 
 [output.html.playground.boring-prefixes]
 lean = "# "

doc/char.md

@@ -1,11 +1 @@
 # Characters
-
-A value of type `Char`, also known as a character, is a [Unicode scalar value](https://www.unicode.org/glossary/#unicode_scalar_value). It is represented using an unsigned 32-bit integer and is statically guaranteed to be a valid Unicode scalar value.
-
-Syntactically, character literals are enclosed in single quotes.
-```lean
-#eval 'a' -- 'a'
-#eval '∀' -- '∀'
-```
-
-Characters are ordered and can be decidably compared using the relational operators `=`, `<`, `≤`, `>`, `≥`.

doc/dev/bootstrap.md

@@ -1,3 +1,4 @@
+
 # Lean Build Bootstrapping
 
 Since version 4, Lean is a partially bootstrapped program: most parts of the
@@ -15,18 +16,17 @@ stage0/
   bin/lean
 stage1/
   include/
-    config.h  # config variables used to build `lean` such as used allocator
-    runtime/lean.h  # runtime header, used by extracted C code, uses `config.h`
+    config.h  # config variables used to build `lean` such as use allocator
+    runtime/lean.h  # runtime headers, used by extracted C code, uses `config.h`
   share/lean/
-    lean.mk  # used by `leanmake`
+    Makefile  # used by `leanmake`
   lib/
     lean/**/*.olean  # the Lean library (incl. the compiler) compiled by the previous stage's `lean`
     temp/**/*.{c,o}  # the library extracted to C and compiled by `leanc`
-    libInit.a libLean.a  # static libraries of the Lean library
+    libInit.a libStd.a libLean.a  # static libraries of the Lean library
     libleancpp.a  # a static library of the C++ sources of Lean
-    libleanshared.so  # a dynamic library including the static libraries above
   bin/
-    lean  # the Lean compiler & server, a small executable that calls directly into libleanshared.so
+    lean  # the Lean compiler & server linked together from the above libraries
     leanc  # a wrapper around a C compiler supplying search paths etc
     leanmake  # a wrapper around `make` supplying the Makefile above
 stage2/...
@@ -55,7 +55,7 @@ We are not aware of any "meta-meta" parts that influence more than two stages of
 compilation, so stage 3 should always be identical to stage 2 and only exists as
 a sanity check.
 
-In summary, doing a standard build via `make` internally involves these steps:
+In summary, doing a standard build via `make` involves these steps:
 
 1. compile the `stage0/src` archived sources into `stage0/bin/lean`
 1. use it to compile the current library (*including* your changes) into `stage1/lib`
@@ -65,59 +65,19 @@ You now have a Lean binary and library that include your changes, though their
 own compilation was not influenced by them, that you can use to test your
 changes on test programs whose compilation *will* be influenced by the changes.
 
-## Updating stage0
-
 Finally, when we want to use new language features in the library, we need to
-update the archived C source code of the stage 0 compiler in `stage0/src`.
-
-The github repository will automatically update stage0 on `master` once
-`src/stdlib_flags.h` and `stage0/src/stdlib_flags.h` are out of sync.
-
-If you have write access to the lean4 repository, you can also manually
-trigger that process, for example to be able to use new features in the compiler itself.
-You can do that on <https://github.com/leanprover/lean4/actions/workflows/update-stage0.yml>
-or using Github CLI with
-```
-gh workflow run update-stage0.yml
-```
-
-Leaving stage0 updates to the CI automation is preferable, but should you need
-to do it locally, you can use `make update-stage0-commit` in `build/release` to
-update `stage0` from `stage1` or `make -C stageN update-stage0-commit` to
-update from another stage. This command will automatically stage the updated files
-and introduce a commit,so make sure to commit your work before that.
-
-If you rebased the branch (either onto a newer version of `master`, or fixing
-up some commits prior to the stage0 update, recreate the stage0 update commits.
-The script `script/rebase-stage0.sh` can be used for that.
-
-The CI should prevent PRs with changes to stage0 (besides `stdlib_flags.h`)
-from entering `master` through the (squashing!) merge queue, and label such PRs
-with the `changes-stage0` label. Such PRs should have a cleaned up history,
-with separate stage0 update commits; then coordinate with the admins to merge
-your PR using rebase merge, bypassing the merge queue.
-
+update the stage 0 compiler, which can be done via `make -C stageN update-stage0`.
+`make update-stage0` without `-C` defaults to stage1.
 
 ## Further Bootstrapping Complications
 
 As written above, changes in meta code in the current stage usually will only
 affect later stages. This is an issue in two specific cases.
 
-* For the special case of *quotations*, it is desirable to have changes in builtin parsers affect them immediately: when the changes in the parser become active in the next stage, builtin macros implemented via quotations should generate syntax trees compatible with the new parser, and quotation patterns in builtin macros and elaborators should be able to match syntax created by the new parser and macros.
-  Since quotations capture the syntax tree structure during execution of the current stage and turn it into code for the next stage, we need to run the current stage's builtin parsers in quotations via the interpreter for this to work.
-  Caveats:
-  * We activate this behavior by default when building stage 1 by setting `-Dinternal.parseQuotWithCurrentStage=true`.
-    We force-disable it inside `macro/macro_rules/elab/elab_rules` via `suppressInsideQuot` as they are guaranteed not to run in the next stage and may need to be run in the current one, so the stage 0 parser is the correct one to use for them.
-    It may be necessary to extend this disabling to functions that contain quotations and are (exclusively) used by one of the mentioned commands. A function using quotations should never be used by both builtin and non-builtin macros/elaborators. Example: https://github.com/leanprover/lean4/blob/f70b7e5722da6101572869d87832494e2f8534b7/src/Lean/Elab/Tactic/Config.lean#L118-L122
-  * The parser needs to be reachable via an `import` statement, otherwise the version of the previous stage will silently be used.
-  * Only the parser code (`Parser.fn`) is affected; all metadata such as leading tokens is taken from the previous stage.
-
-  For an example, see https://github.com/leanprover/lean4/commit/f9dcbbddc48ccab22c7674ba20c5f409823b4cc1#diff-371387aed38bb02bf7761084fd9460e4168ae16d1ffe5de041b47d3ad2d22422R13
-
 * For *non-builtin* meta code such as `notation`s or `macro`s in
   `Notation.lean`, we expect changes to affect the current file and all later
   files of the same stage immediately, just like outside the stdlib. To ensure
-  this, we build stage 1 using `-Dinterpreter.prefer_native=false` -
+  this, we need to build the stage using `-Dinterpreter.prefer_native=false` -
   otherwise, when executing a macro, the interpreter would notice that there is
   already a native symbol available for this function and run it instead of the
   new IR, but the symbol is from the previous stage!
@@ -135,13 +95,28 @@ affect later stages. This is an issue in two specific cases.
   further stages (e.g. after an `update-stage0`) will then need to be compiled
   with the flag set to `false` again since they will expect the new signature.
 
-  When enabling `prefer_native`, we usually want to *disable* `parseQuotWithCurrentStage` as it would otherwise make quotations use the interpreter after all.
-  However, there is a specific case where we want to set both options to `true`: when we make changes to a non-builtin parser like `simp` that has a builtin elaborator, we cannot have the new parser be active outside of quotations in stage 1 as the builtin elaborator from stage 0 would not understand them; on the other hand, we need quotations in e.g. the builtin `simp` elaborator to produce the new syntax in the next stage.
-  As this issue usually affects only tactics, enabling `debug.byAsSorry` instead of `prefer_native` can be a simpler solution.
+  For an example, see https://github.com/leanprover/lean4/commit/da4c46370d85add64ef7ca5e7cc4638b62823fbb.
 
-  For a `prefer_native` example, see https://github.com/leanprover/lean4/commit/da4c46370d85add64ef7ca5e7cc4638b62823fbb.
+* For the special case of *quotations*, it is desirable to have changes in
+  built-in parsers affect them immediately: when the changes in the parser
+  become active in the next stage, macros implemented via quotations should
+  generate syntax trees compatible with the new parser, and quotation patterns
+  in macro and elaborators should be able to match syntax created by the new
+  parser and macros. Since quotations capture the syntax tree structure during
+  execution of the current stage and turn it into code for the next stage, we
+  need to run the current stage's built-in parsers in quotation via the
+  interpreter for this to work. Caveats:
+  * Since interpreting full parsers is not nearly as cheap and we rarely change
+    built-in syntax, this needs to be opted in using `-Dinternal.parseQuotWithCurrentStage=true`.
+  * The parser needs to be reachable via an `import` statement, otherwise the
+    version of the previous stage will silently be used.
+  * Only the parser code (`Parser.fn`) is affected; all metadata such as leading
+    tokens is taken from the previous stage.
+
+  For an example, see https://github.com/leanprover/lean4/commit/f9dcbbddc48ccab22c7674ba20c5f409823b4cc1#diff-371387aed38bb02bf7761084fd9460e4168ae16d1ffe5de041b47d3ad2d22422
+  (from before the flag defaulted to `false`).
 
 To modify either of these flags both for building and editing the stdlib, adjust
 the code in `stage0/src/stdlib_flags.h`. The flags will automatically be reset
 on the next `update-stage0` when the file is overwritten with the original
-version in `src/`.
+version in `src/`.

doc/dev/commit_convention.md

@@ -1,15 +1,10 @@
 Git Commit Convention
 =====================
 
-We are using the following convention for writing git commit messages. For pull
-requests, make sure the pull request title and description follow this
-convention, as the squash-merge commit will inherit title and body from the
-pull request.
-
-This convention is based on the one from the AngularJS project ([doc][angularjs-doc],
+We are using the following convention for writing git-commit messages.
+It is based on the one from AngularJS project([doc][angularjs-doc],
 [commits][angularjs-git]).
 
-
 [angularjs-git]: https://github.com/angular/angular.js/commits/master
 [angularjs-doc]: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#
 

doc/dev/cpp_coding_style.md

@@ -0,0 +1,155 @@
+[google-style]: https://google.github.io/styleguide/cppguide.html
+[cpplint]: /src/cmake/Modules/cpplint.py
+
+# Coding Style
+
+The Lean project is moving away from using any C++ as more and more of
+the compiler is being bootstrapped in Lean itself. But the remaining
+C++ codebase is using modified version of [Google's C++ Style
+Guide][google-style].
+
+## [C++11](http://en.wikipedia.org/wiki/C%2B%2B11) features
+
+Lean makes extensive use of new features in the C++ 11 standard.
+Developers must be familiar with the standard to be able to understand
+the code. Here are some of the features that are extensively used.
+
+- Type inference (aka `auto` keyword).
+- Initializer lists.
+- Lambda functions and expressions.
+- `nullptr` constant.
+- Strongly typed enumerations.
+- Right angle brackets with no space is now allowed in C++ 11.
+- Thread local storage.
+- Threading facilities.
+- Tuple types.
+- Smart pointers.
+- When using ``std::list`` make sure to include the `std::`
+  qualifier so you do not accidentally use the ``lean::list`` type.
+- When using ``std::copy`` make sure to include the `std::`
+  qualifier so you do not accidentally use the ``lean::copy`` type.
+- Small and focused functions are preferred: foo().  Try not to
+  exceed 500 lines in a function, except in tests.
+- Do **not** use the `#ifndef-#define-#endif` idiom for header files.
+  Instead use `#pragma once`.
+- Write `type const & v` instead of `const type & v`.
+- Use `const` extensively.
+- Use the macro `lean_assert` for assertions. The macro `lean_assert`
+  is extensively used when writing unit tests.
+
+## Naming
+
+- Class, method, and function names are lower case
+Use `_` for composite names. Example: `type_checker`.
+- Class/struct fields should start with the prefix `m_`.
+
+  Example:
+  ```c++
+  class point {
+      int m_x;
+      int m_y;
+  public:
+      ...
+  };
+  ```
+
+## Namespaces
+
+All code is in the `lean` namespace. Each frontend is stored in a
+separate nested namespace. For example, the SMT 2.0 frontend is stored
+in the `lean::smt` namespace.
+
+Exception: some debugging functions are stored outside of the `lean`
+namespace. These functions are called `print` and are meant to be used
+when debugging Lean using `gdb`.
+
+Do not use `using namespace` in a header file.
+
+## Templates
+
+Organize template source code using the approach described at http://www.codeproject.com/Articles/3515/How-To-Organize-Template-Source-Code
+
+## Idioms
+
+Use some popular C++ idioms:
+
+- [Pimpl](http://c2.com/cgi/wiki?PimplIdiom)
+- [RAII](http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization) Resource Acquisition Is Initialization
+
+## Formatting
+
+* Use 4 spaces for indentation.
+
+* `if-then-else` curly brackets not always required.  The following
+  forms are acceptable:
+
+  ```c++
+  if (cond) {
+      ...
+  } else {
+      ...
+  }
+  ```
+  and
+
+  ```c++
+  if (cond)
+    statement1;
+  else
+    statement2;
+  ```
+
+  In *exceptional cases*, we also use
+
+  ```c++
+  if (cond) statement;
+  ```
+
+  and
+
+  ```c++
+  if (cond) statement1; else stament2;
+  ```
+  * `if-then-else-if-else`
+
+  The following forms are acceptable:
+
+  ```c++
+  if (cond) {
+      ...
+  } else if (cond) {
+      ...
+  } else {
+      ...
+  }
+  ```c++
+  and
+
+  ```c++
+  if (cond)
+      statement1;
+  else if (cond)
+      statement2;
+  else
+      statement3;
+  ```
+
+* Format code using extra spaces to make code more readable.  For example:
+
+  ```c++
+  environment const & m_env;
+  cache               m_cache;
+  normalizer          m_normalizer;
+  volatile bool       m_interrupted;
+  ```
+  instead of:
+
+  ```c++
+  environment const & m_env;
+  cache m_cache;
+  normalizer m_normalizer;
+  volatile bool m_interrupted;
+  ```
+
+* Spaces in expressions.  Write `a == b` instead of `a==b`. Similarly,
+  we write `x < y + 1` instead of `x<y+1`.

doc/dev/debugging.md

@@ -5,7 +5,7 @@ Some notes on how to debug Lean, which may also be applicable to debugging Lean
 
 ## Tracing
 
-In `CoreM` and derived monads, we use `trace[traceCls] "msg with {interpolations}"` to fill the structured trace viewable with `set_option trace.traceCls true`.
+In `CoreM` and derived monads, we use `trace![traceCls] "msg with {interpolations}"` to fill the structured trace viewable with `set_option trace.traceCls true`.
 New trace classes have to be registered using `registerTraceClass` first.
 
 Notable trace classes:
@@ -20,12 +20,9 @@ Notable trace classes:
 * `Meta.isDefEq`: unification
 * `interpreter`: full execution trace of the interpreter. Only available in debug builds.
 
-In pure contexts or when execution is aborted before the messages are finally printed, one can instead use the term `dbg_trace "msg with {interpolations}"; val` (`;` can also be replaced by a newline), which will print the message to stderr before evaluating `val`. `dbgTraceVal val` can be used as a shorthand for `dbg_trace "{val}"; val`.
+In pure contexts or when execution is aborted before the messages are finally printed, one can instead use the term `dbg_trace "msg with {interpolations}"; val` (`;` can also be replaced by a newline), which will print the message directly to stderr before evaluating `val`. `dbgTraceVal val` can be used as a shorthand for `dbg_trace "{val}"; val`.
 Note that if the return value is not actually used, the trace code is silently dropped as well.
 
-By default, such stderr output is buffered and shown as messages after a command has been elaborated, which is necessary to ensure deterministic ordering of messages under parallelism.
-If Lean aborts the process before it can finish the command or takes too long to do that, using `-DstderrAsMessages=false` avoids this buffering and shows `dbg_trace` output (but not `trace`s or other diagnostics) immediately.
-
 ## Debuggers
 
 `gdb`/`lldb` can be used to inspect stack traces of compiled Lean code, though they cannot print values of Lean variables and terms in any legible way yet.

doc/dev/ffi.md

@@ -11,8 +11,6 @@ There are two primary attributes for interoperating with other languages:
   It can also be used with `def` to provide an internal definition, but ensuring consistency of both definitions is up to the user.
 * `@[export sym] def leanSym : ...` exports `leanSym` under the unmangled symbol name `sym`.
 
-For simple examples of how to call foreign code from Lean and vice versa, see <https://github.com/leanprover/lean4/blob/master/src/lake/examples/ffi> and <https://github.com/leanprover/lean4/blob/master/src/lake/examples/reverse-ffi>, respectively.
-
 ## The Lean ABI
 
 The Lean Application Binary Interface (ABI) describes how the signature of a Lean declaration is encoded as a native calling convention.
@@ -23,7 +21,7 @@ If `n` is 0, the corresponding C declaration is
 extern s sym;
 ```
 where `s` is the C translation of `β` as specified in the next section.
-In the case of an `@[extern]` definition, the symbol's value is guaranteed to be initialized only after calling the Lean module's initializer or that of an importing module; see [Initialization](#initialization).
+In the case of an `@[extern]` definition, the symbol's value is guaranteed to be initialized only after calling the Lean module's initializer or that of an importing module; see [Initialization](.#init).
 
 If `n` is greater than 0, the corresponding C declaration is
 ```c
@@ -34,7 +32,7 @@ In the case of `@[extern]` all *irrelevant* types are removed first; see next se
 
 ### Translating Types from Lean to C
 
-* The integer types `UInt8`, ..., `UInt64`, `USize` are represented by the C types `uint8_t`, ..., `uint64_t`, `size_t`, respectively
+* The integer types `UInt8`, ..., `UInt64`, `USize` are represented by the C types `uint8_t`, ..., `uint64_t`, `usize_t`, respectively
 * `Char` is represented by `uint32_t`
 * `Float` is represented by `double`
 * An *enum* inductive type of at least 2 and at most 2^32 constructors, each of which with no parameters, is represented by the first type of `uint8_t`, `uint16_t`, `uint32_t` that is sufficient to represent all constructor indices.
@@ -45,67 +43,17 @@ In the case of `@[extern]` all *irrelevant* types are removed first; see next se
   * it is none of the types described above
   * it is not marked `unsafe`
   * it has a single constructor with a single parameter of *relevant* type
-
   is represented by the representation of that parameter's type.
-
+  
   For example, `{ x : α // p }`, the `Subtype` structure of a value of type `α` and an irrelevant proof, is represented by the representation of `α`.
 * `Nat` is represented by `lean_object *`.
   Its runtime value is either a pointer to an opaque bignum object or, if the lowest bit of the "pointer" is 1 (`lean_is_scalar`), an encoded unboxed natural number (`lean_box`/`lean_unbox`).
 * A universe `Sort u`, type constructor `... → Sort u`, or proposition `p : Prop` is *irrelevant* and is either statically erased (see above) or represented as a `lean_object *` with the runtime value `lean_box(0)`
 * Any other type is represented by `lean_object *`.
-  Its runtime value is a pointer to an object of a subtype of `lean_object` (see the "Inductive types" section below) or the unboxed value `lean_box(cidx)` for the `cidx`th constructor of an inductive type if this constructor does not have any relevant parameters.
+  Its runtime value is a pointer to an object of a subtype of `lean_object` (see respective declarations in `lean.h`) or the unboxed value `lean_box(cidx)` for the `cidx`th constructor of an inductive type if this constructor does not have any relevant parameters.
 
   Example: the runtime value of `u : Unit` is always `lean_box(0)`.
 
-#### Inductive types
-
-For inductive types which are in the fallback `lean_object *` case above and not trivial constructors, the type is stored as a `lean_ctor_object`, and `lean_is_ctor` will return true. A `lean_ctor_object` stores the constructor index in the header, and the fields are stored in the `m_objs` portion of the object.
-
-The memory order of the fields is derived from the types and order of the fields in the declaration. They are ordered as follows:
-
-* Non-scalar fields stored as `lean_object *`
-* Fields of type `USize`
-* Other scalar fields, in decreasing order by size
-
-Within each group the fields are ordered in declaration order. **Warning**: Trivial wrapper types still count toward a field being treated as non-scalar for this purpose.
-
-* To access fields of the first kind, use `lean_ctor_get(val, i)` to get the `i`th non-scalar field.
-* To access `USize` fields, use `lean_ctor_get_usize(val, n+i)` to get the `i`th usize field and `n` is the total number of fields of the first kind.
-* To access other scalar fields, use `lean_ctor_get_uintN(val, off)` or `lean_ctor_get_usize(val, off)` as appropriate. Here `off` is the byte offset of the field in the structure, starting at `n*sizeof(void*)` where `n` is the number of fields of the first two kinds.
-
-For example, a structure such as
-```lean
-structure S where
-  ptr_1 : Array Nat
-  usize_1 : USize
-  sc64_1 : UInt64
-  ptr_2 : { x : UInt64 // x > 0 } -- wrappers don't count as scalars
-  sc64_2 : Float -- `Float` is 64 bit
-  sc8_1 : Bool
-  sc16_1 : UInt16
-  sc8_2 : UInt8
-  sc64_3 : UInt64
-  usize_2 : USize
-  ptr_3 : Char -- trivial wrapper around `UInt32`
-  sc32_1 : UInt32
-  sc16_2 : UInt16
-```
-would get re-sorted into the following memory order:
-
-* `S.ptr_1` - `lean_ctor_get(val, 0)`
-* `S.ptr_2` - `lean_ctor_get(val, 1)`
-* `S.ptr_3` - `lean_ctor_get(val, 2)`
-* `S.usize_1` - `lean_ctor_get_usize(val, 3)`
-* `S.usize_2` - `lean_ctor_get_usize(val, 4)`
-* `S.sc64_1` - `lean_ctor_get_uint64(val, sizeof(void*)*5)`
-* `S.sc64_2` - `lean_ctor_get_float(val, sizeof(void*)*5 + 8)`
-* `S.sc64_3` - `lean_ctor_get_uint64(val, sizeof(void*)*5 + 16)`
-* `S.sc32_1` - `lean_ctor_get_uint32(val, sizeof(void*)*5 + 24)`
-* `S.sc16_1` - `lean_ctor_get_uint16(val, sizeof(void*)*5 + 28)`
-* `S.sc16_2` - `lean_ctor_get_uint16(val, sizeof(void*)*5 + 30)`
-* `S.sc8_1` - `lean_ctor_get_uint8(val, sizeof(void*)*5 + 32)`
-* `S.sc8_2` - `lean_ctor_get_uint8(val, sizeof(void*)*5 + 33)`
-
 ### Borrowing
 
 By default, all `lean_object *` parameters of an `@[extern]` function are considered *owned*, i.e. the external code is passed a "virtual RC token" and is responsible for passing this token along to another consuming function (exactly once) or freeing it via `lean_dec`.
@@ -121,13 +69,13 @@ When including Lean code as part of a larger program, modules must be *initializ
 Module initialization entails
 * initialization of all "constants" (nullary functions), including closed terms lifted out of other functions
 * execution of all `[init]` functions
-* execution of all `[builtin_init]` functions, if the `builtin` parameter of the module initializer has been set
+* execution of all `[builtinInit]` functions, if the `builtin` parameter of the module initializer has been set
 
 The module initializer is automatically run with the `builtin` flag for executables compiled from Lean code and for "plugins" loaded with `lean --plugin`.
 For all other modules imported by `lean`, the initializer is run without `builtin`.
-Thus `[init]` functions are run iff their module is imported, regardless of whether they have native code available or not, while `[builtin_init]` functions are only run for native executable or plugins, regardless of whether their module is imported or not.
+Thus `[init]` functions are run iff their module is imported, regardless of whether they have native code available or not, while `[builtinInit]` functions are only run for native executable or plugins, regardless of whether their module is imported or not.
 `lean` uses built-in initializers for e.g. registering basic parsers that should be available even without importing their module (which is necessary for bootstrapping).
-
+  
 The initializer for module `A.B` is called `initialize_A_B` and will automatically initialize any imported modules.
 Module initializers are idempotent (when run with the same `builtin` flag), but not thread-safe.
 Together with initialization of the Lean runtime, you should execute code like the following exactly once before accessing any Lean declarations:
@@ -160,15 +108,6 @@ if (lean_io_result_is_ok(res)) {
 lean_io_mark_end_initialization();
 ```
 
-In addition, any other thread not spawned by the Lean runtime itself must be initialized for Lean use by calling
-```c
-void lean_initialize_thread();
-```
-and should be finalized in order to free all thread-local resources by calling
-```c
-void lean_finalize_thread();
-```
-
 ## `@[extern]` in the Interpreter
 
 The interpreter can run Lean declarations for which symbols are available in loaded shared libraries, which includes `@[extern]` declarations.
@@ -179,4 +118,4 @@ Thus to e.g. run `#eval` on such a declaration, you need to
 Note that it is not sufficient to load the foreign library containing the external symbol because the interpreter depends on code that is emitted for each `@[extern]` declaration.
 Thus it is not possible to interpret an `@[extern]` declaration in the same file.
 
-See [`tests/compiler/foreign`](https://github.com/leanprover/lean4/tree/master/tests/compiler/foreign/) for an example.
+See `tests/compiler/foreign` for an example.

doc/dev/fixing_tests.md

@@ -0,0 +1,39 @@
+Fixing Tests
+============
+
+The test suite contains some tests that compare the produced output
+with the expected output. For example, the directory `tests/lean`
+contains files such as [`bad_class.lean`](../tests/lean/bad_class.lean) and
+[`bad_class.lean.expected.out`](../tests/lean/bad_class.lean.expected.out).
+The later contains the expected output for the test file `bad_class.lean`.
+
+When the Lean source code or the standard library are modified, some of these
+tests break because the produced output is slightly different, and we have
+to reflect the changes in the `.lean.expected.out` files.
+We should not blindly copy the new produced output since we may accidentally
+miss a bug introduced by recent changes.
+The test suite contains commands that allow us to see what changed in a convenient way.
+First, we must install [meld](http://meldmerge.org/). On Ubuntu, we can do it by simply executing
+
+```
+sudo apt-get install meld
+```
+
+Now, suppose `bad_class.lean` test is broken. We can see the problem by going to `test/lean` directory and
+executing
+
+```
+./test_single.sh -i bad_class.lean
+```
+
+When the `-i` option is provided, `meld` is automatically invoked
+whenever there is discrepancy between the produced and expected
+outputs. `meld` can also be used to repair the problems.
+
+In Emacs, we can also execute `M-x lean4-diff-test-file` to check/diff the file of the current buffer.
+To mass-copy all `.produced.out` files to the respective `.expected.out` file, use `tests/lean/copy-produced`.
+When using the Nix setup, add `--keep-failed` to the `nix build` call and then call
+```sh
+tests/lean/copy-produced <build-dir>/source/tests/lean
+```
+instead where `<build-dir>` is the path printed out by `nix build`.

doc/dev/index.md

@@ -1,45 +1,68 @@
 # Development Workflow
+- [Commit Convention](./commit_convention.md)
+- [Building Lean](../make/index.md)
+  - [Ubuntu Setup](../make/ubuntu.md)
+  - [macOS Setup](../make/osx-10.9.md)
+  - [Windows MSYS2 Setup](../make/msys2.md)
+  - [Windows with WSL](../make/wsl.md)
+  - [Nix Setup (*Experimental*)](../make/nix.md)
+- [Unit Testing](./testing.md)
+- [Building This Manual](./mdbook.md)
+- [Fixing Tests](./fixing_tests.md)
+- [Debugging](./debugging.md)
+- [C++ Coding Style](./dev/cpp_coding_style.md)
 
-If you want to make changes to Lean itself, start by [building Lean](../make/index.md) from a clean checkout to make sure that everything is set up correctly.
-After that, read on below to find out how to set up your editor for changing the Lean source code, followed by further sections of the development manual where applicable such as on the [test suite](testing.md) and [commit convention](commit_convention.md).
+You will notice there is a `stage0` folder. This is for bootstrapping
+the compiler development.  Generally you do not change any code in
+`stage0` manually.  It is important that you read [bootstrapping
+pipeline](bootstrap.md) so you understand how this works.
 
-If you are planning to make any changes that may affect the compilation of Lean itself, e.g. changes to the parser, elaborator, or compiler, you should first read about the [bootstrapping pipeline](bootstrap.md).
-You should not edit the `stage0` directory except using the commands described in that section when necessary.
+The dev team uses `elan` to manage which `lean` toolchain to use
+locally and `elan` can be used to setup the version of Lean you are
+manually building.  This means you generally do not use `make
+install`. You use `elan` instead.
 
 ## Development Setup
 
-You can use any of the [supported editors](../setup.md) for editing the Lean source code.
-If you set up `elan` as below, opening `src/` as a *workspace folder* should ensure that stage 0 (i.e. the stage that first compiles `src/`) will be used for files in that directory.
+You can use any of the [supported editors](../setup.md) for editing
+the Lean source code. If you set up `elan` as below, opening `src/` as
+a *workspace folder* should ensure that stage 0 will be used for file
+in that directory.
 
-### Dev setup using elan
+## Dev setup using elan
 
 You can use [`elan`](https://github.com/leanprover/elan) to easily
 switch between stages and build configurations based on the current
 directory, both for the `lean`, `leanc`, and `leanmake` binaries in your shell's
 PATH and inside your editor.
 
-To install elan, you can do so, without installing a default version of Lean, using (Unix)
+To install elan, you can do so, without installing a default version of Lean, using
 
 ```bash
+[Unix]
 curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh -s -- --default-toolchain none
-```
-or (Windows)
-```
+
+[Windows]
 curl -O --location https://raw.githubusercontent.com/leanprover/elan/master/elan-init.ps1
 powershell -f elan-init.ps1 --default-toolchain none
 del elan-init.ps1
 ```
 
-The `lean-toolchain` files in the Lean 4 repository are set up to use the `lean4-stage0`
-toolchain for editing files in `src` and the `lean4` toolchain for editing files in `tests`.
-
-Run the following commands to make `lean4` point at `stage1` and `lean4-stage0` point at `stage0`:
+You can use `elan toolchain link` to give a specific stage build
+directory a reference name, then use `elan override set` to associate
+such a name to the current directory. We usually want to use `stage0`
+for editing files in `src` and `stage1` for everything else (e.g.
+tests).
 ```bash
 # in the Lean rootdir
 elan toolchain link lean4 build/release/stage1
 elan toolchain link lean4-stage0 build/release/stage0
+# make `lean` etc. point to stage1 in the rootdir and subdirs
+elan override set lean4
+cd src
+# make `lean` etc. point to stage0 anywhere inside `src`
+elan override set lean4-stage0
 ```
-
 You can also use the `+toolchain` shorthand (e.g. `lean +lean4-debug`) to switch
 toolchains on the spot. `lean4-mode` will automatically use the `lean` executable
 associated with the directory of the current file as long as `lean4-rootdir` is
@@ -51,32 +74,3 @@ You might find that debugging through elan, e.g. via `gdb lean`, disables some
 things like symbol autocompletion because at first only the elan proxy binary
 is loaded. You can instead pass the explicit path to `bin/lean` in your build
 folder to gdb, or use `gdb $(elan which lean)`.
-
-It is also possible to generate releases that others can use,
-simply by pushing a tag to your fork of the Lean 4 github repository
-(and waiting about an hour; check the `Actions` tab for completion).
-If you push `my-tag` to a fork in your github account `my_name`,
-you can then put `my_name/lean4:my-tag` in your `lean-toolchain` file in a project using `lake`.
-(You must use a tag name that does not start with a numeral, or contain `_`).
-
-### VS Code
-
-There is a `lean.code-workspace` file that correctly sets up VS Code with workspace roots for the stage0/stage1 setup described above as well as with other settings.
-You should always load it when working on Lean, such as by invoking
-```
-code lean.code-workspace
-```
-on the command line.
-
-### `ccache`
-
-Lean's build process uses [`ccache`](https://ccache.dev/) if it is
-installed to speed up recompilation of the generated C code. Without
-`ccache`, you'll likely spend more time than necessary waiting on
-rebuilds - it's a good idea to make sure it's installed.
-
-### `prelude`
-Unlike most Lean projects, all submodules of the `Lean` module begin with the
-`prelude` keyword. This disables the automated import of `Init`, meaning that
-developers need to figure out their own subset of `Init` to import. This is done
-such that changing files in `Init` doesn't force a full rebuild of `Lean`.

doc/dev/mdbook.md

@@ -1,12 +1,3 @@
-# Documentation
-
-The Lean `doc` folder contains the [Lean Manual](https://lean-lang.org/lean4/doc/) and is
-authored in a combination of markdown (`*.md`) files and literate Lean files.  The .lean files are
-preprocessed using a tool called [LeanInk](https://github.com/leanprover/leanink) and
-[Alectryon](https://github.com/Kha/alectryon) which produces a generated markdown file.  We then run
-`mdbook` on the result to generate the html pages.
-
-
 ## Settings
 
 We are using the following settings while editing the markdown docs.
@@ -23,87 +14,30 @@ We are using the following settings while editing the markdown docs.
 
 ## Build
 
-### Using Nix
-
-Building the manual using Nix (which is what the CI does) is as easy as
-```bash
-$ nix build --update-input lean ./doc
-```
-You can also open a shell with `mdbook` for running the commands mentioned below with
-`nix develop ./doc#book`. Otherwise, read on.
-
-### Manually
-
-To build and test the book you have to preprocess the .lean files with Alectryon then use our own
-fork of the Rust tool named [mdbook](https://github.com/leanprover/mdbook). We have our own fork of
-mdBook with the following additional features:
+This manual is generated by
+[mdBook](https://github.com/rust-lang/mdBook). We are currently using
+a [fork](https://github.com/leanprover/mdBook) of it for the following
+additional features:
 
 * Add support for hiding lines in other languages
   [#1339](https://github.com/rust-lang/mdBook/pull/1339)
-* Make `mdbook test` call the `lean` compiler to test the snippets.
-* Ability to test a single chapter at a time which is handy when you
-are working on that chapter.  See the `--chapter` option.
+* Replace calling `rustdoc --test` from `mdbook test` with `./test`
 
-So you need to setup these tools before you can run `mdBook`.
+To build this manual, first install the fork via
+```bash
+cargo install --git https://github.com/leanprover/mdBook mdbook
+```
+Then use e.g. [`mdbook watch`](https://rust-lang.github.io/mdBook/cli/watch.html) in the `doc/` folder:
 
-1. install [Rust](https://www.rust-lang.org/tools/install)
-which provides you with the `cargo` tool for building rust packages.
-Then run the following:
-    ```bash
-    cargo install --git https://github.com/leanprover/mdBook mdbook
-    ```
+```bash
+cd doc
+mdbook watch --open  # opens the output in `out/` in your default browser
+```
 
-1. Clone https://github.com/leanprover/LeanInk.git and run `lake build` then make the resulting
-   binary available to Alectryon using e.g.
-    ```bash
-    # make `leanInk` available in the current shell
-    export PATH=$PWD/build/bin:$PATH
-    ```
+Run `mdbook test` to test all `lean` code blocks.
 
-1. Create a Python 3.10 environment.
-
-1. Install Alectryon:
-    ```
-    python3 -m pip install git+https://github.com/Kha/alectryon.git@typeid
-    ```
-
-1. Now you are ready to process the `*.lean` files using Alectryon as follows:
-
-    ```
-    cd lean4/doc
-    alectryon --frontend lean4+markup examples/palindromes.lean --backend webpage -o palindromes.lean.md
-    ```
-
-    Repeat this for the other .lean files you care about or write a script to process them all.
-
-1. Now you can build the book using:
-    ```
-    cd lean4/doc
-    mdbook build
-    ```
-
-This will put the HTML in a `out` folder so you can load `out/index.html` in your web browser and
-it should look like https://lean-lang.org/lean4/doc/.
-
-1. It is also handy to use e.g. [`mdbook watch`](https://rust-lang.github.io/mdBook/cli/watch.html)
-   in the `doc/` folder so that it keeps the html up to date while you are editing.
-
-    ```bash
-    mdbook watch --open  # opens the output in `out/` in your default browser
-    ```
-
-## Testing Lean Snippets
-
-You can run the following in the `doc/` folder to test all the lean code snippets.
-
-    ```bash
-    mdbook test
-    ```
-
-and you can use the `--chapter` option to test a specific chapter that you are working on:
-
-    ```bash
-    mdbook test --chapter Array
-    ```
-
-Use chapter name `?` to get a list of all the chapter names.
+Using the [Nix setup](make/nix.md), you can instead open a shell with
+the mdBook fork downloaded from our binary cache:
+```bash
+nix develop .#doc
+```

doc/dev/release_checklist.md

@@ -1,262 +0,0 @@
-# Releasing a stable version
-
-This checklist walks you through releasing a stable version.
-See below for the checklist for release candidates.
-
-We'll use `v4.6.0` as the intended release version as a running example.
-
-- One week before the planned release, ensure that
-  (1) someone has written the release notes and
-  (2) someone has written the first draft of the release blog post.
-  If there is any material in `./releases_drafts/` on the `releases/v4.6.0` branch, then the release notes are not done.
-  (See the section "Writing the release notes".)
-- `git checkout releases/v4.6.0`
-  (This branch should already exist, from the release candidates.)
-- `git pull`
-- In `src/CMakeLists.txt`, verify you see
-  - `set(LEAN_VERSION_MINOR 6)` (for whichever `6` is appropriate)
-  - `set(LEAN_VERSION_IS_RELEASE 1)`
-  - (both of these should already be in place from the release candidates)
-- `git tag v4.6.0`
-- `git push $REMOTE v4.6.0`, where `$REMOTE` is the upstream Lean repository (e.g., `origin`, `upstream`)
-- Now wait, while CI runs.
-  - You can monitor this at `https://github.com/leanprover/lean4/actions/workflows/ci.yml`,
-    looking for the `v4.6.0` tag.
-  - This step can take up to an hour.
-  - If you are intending to cut the next release candidate on the same day,
-    you may want to start on the release candidate checklist now.
-- Go to https://github.com/leanprover/lean4/releases and verify that the `v4.6.0` release appears.
-  - Edit the release notes on Github to select the "Set as the latest release".
-  - Follow the instructions in creating a release candidate for the "GitHub release notes" step,
-    now that we have a written `RELEASES.md` section.
-    Do a quick sanity check.
-- Next, we will move a curated list of downstream repos to the latest stable release.
-  - For each of the repositories listed below:
-    - Make a PR to `master`/`main` changing the toolchain to `v4.6.0`
-      - Update the toolchain file
-      - In the Lakefile, if there are dependencies on specific version tags of dependencies that you've already pushed as part of this process, update them to the new tag.
-        If they depend on `main` or `master`, don't change this; you've just updated the dependency, so it will work and be saved in the manifest
-      - Run `lake update`
-      - The PR title should be "chore: bump toolchain to v4.6.0".
-    - Merge the PR once CI completes.
-    - Create the tag `v4.6.0` from `master`/`main` and push it.
-    - Merge the tag `v4.6.0` into the `stable` branch and push it.
-  - We do this for the repositories:
-    - [lean4checker](https://github.com/leanprover/lean4checker)
-      - No dependencies
-      - Toolchain bump PR
-      - Create and push the tag
-      - Merge the tag into `stable`
-    - [Batteries](https://github.com/leanprover-community/batteries)
-      - No dependencies
-      - Toolchain bump PR
-      - Create and push the tag
-      - Merge the tag into `stable`
-    - [ProofWidgets4](https://github.com/leanprover-community/ProofWidgets4)
-      - Dependencies: `Batteries`
-      - Note on versions and branches:
-        - `ProofWidgets` uses a sequential version tagging scheme, e.g. `v0.0.29`,
-          which does not refer to the toolchain being used.
-        - Make a new release in this sequence after merging the toolchain bump PR.
-        - `ProofWidgets` does not maintain a `stable` branch.
-      - Toolchain bump PR
-      - Create and push the tag, following the version convention of the repository
-    - [Aesop](https://github.com/leanprover-community/aesop)
-      - Dependencies: `Batteries`
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - Merge the tag into `stable`
-    - [doc-gen4](https://github.com/leanprover/doc-gen4)
-      - Dependencies: exist, but they're not part of the release workflow
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [Verso](https://github.com/leanprover/verso)
-      - Dependencies: exist, but they're not part of the release workflow
-      - The `SubVerso` dependency should be compatible with _every_ Lean release simultaneously, rather than following this workflow
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [import-graph](https://github.com/leanprover-community/import-graph)
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - There is no `stable` branch; skip this step
-    - [Mathlib](https://github.com/leanprover-community/mathlib4)
-      - Dependencies: `Aesop`, `ProofWidgets4`, `lean4checker`, `Batteries`, `doc-gen4`, `import-graph`
-      - Toolchain bump PR notes:
-        - In addition to updating the `lean-toolchain` and `lakefile.lean`,
-          in `.github/workflows/lean4checker.yml` update the line
-          `git checkout v4.6.0` to the appropriate tag. 
-        - Push the PR branch to the main Mathlib repository rather than a fork, or CI may not work reliably
-        - Create and push the tag
-        - Create a new branch from the tag, push it, and open a pull request against `stable`.
-          Coordinate with a Mathlib maintainer to get this merged.
-    - [REPL](https://github.com/leanprover-community/repl)
-      - Dependencies: `Mathlib` (for test code)
-      - Note that there are two copies of `lean-toolchain`/`lakefile.lean`:
-        in the root, and in `test/Mathlib/`. Edit both, and run `lake update` in both directories.
-      - Toolchain bump PR including updated Lake manifest
-      - Create and push the tag
-      - Merge the tag into `stable`
-- The `v4.6.0` section of `RELEASES.md` is out of sync between
-  `releases/v4.6.0` and `master`. This should be reconciled:
-  - Replace the `v4.6.0` section on `master` with the `v4.6.0` section on `releases/v4.6.0`
-    and commit this to `master`.
-- Merge the release announcement PR for the Lean website - it will be deployed automatically
-- Finally, make an announcement!
-  This should go in https://leanprover.zulipchat.com/#narrow/stream/113486-announce, with topic `v4.6.0`.
-  Please see previous announcements for suggested language.
-  You will want a few bullet points for main topics from the release notes.
-  Link to the blog post from the Zulip announcement.
-- Make sure that whoever is handling social media knows the release is out.
-
-## Optimistic(?) time estimates:
-- Initial checks and push the tag: 30 minutes.
-- Waiting for the release: 60 minutes.
-- Fixing release notes: 10 minutes.
-- Bumping toolchains in downstream repositories, up to creating the Mathlib PR: 30 minutes.
-- Waiting for Mathlib CI and bors: 120 minutes.
-- Finalizing Mathlib tags and stable branch, and updating REPL: 15 minutes.
-- Posting announcement and/or blog post: 20 minutes.
-
-# Creating a release candidate.
-
-This checklist walks you through creating the first release candidate for a version of Lean.
-
-We'll use `v4.7.0-rc1` as the intended release version in this example.
-
-- Decide which nightly release you want to turn into a release candidate.
-  We will use `nightly-2024-02-29` in this example.
-- It is essential that Batteries and Mathlib already have reviewed branches compatible with this nightly.
-  - Check that both Batteries and Mathlib's `bump/v4.7.0` branch contain `nightly-2024-02-29`
-    in their `lean-toolchain`.
-  - The steps required to reach that state are beyond the scope of this checklist, but see below!
-- Create the release branch from this nightly tag:
-    ```
-    git remote add nightly https://github.com/leanprover/lean4-nightly.git
-    git fetch nightly tag nightly-2024-02-29
-    git checkout nightly-2024-02-29
-    git checkout -b releases/v4.7.0
-    ```
-- In `RELEASES.md` replace `Development in progress` in the `v4.7.0` section with `Release notes to be written.`
-- We will rely on automatically generated release notes for release candidates,
-  and the written release notes will be used for stable versions only.
-  It is essential to choose the nightly that will become the release candidate as early as possible, to avoid confusion.
-- In `src/CMakeLists.txt`,
-  - verify that you see `set(LEAN_VERSION_MINOR 7)` (for whichever `7` is appropriate); this should already have been updated when the development cycle began.
-  - `set(LEAN_VERSION_IS_RELEASE 1)` (this should be a change; on `master` and nightly releases it is always `0`).
-  - Commit your changes to `src/CMakeLists.txt`, and push.
-- `git tag v4.7.0-rc1`
-- `git push origin v4.7.0-rc1`
-- Ping the FRO Zulip that release notes need to be written. The release notes do not block completing the rest of this checklist.
-- Now wait, while CI runs.
-  - You can monitor this at `https://github.com/leanprover/lean4/actions/workflows/ci.yml`, looking for the `v4.7.0-rc1` tag.
-  - This step can take up to an hour.
-- (GitHub release notes) Once the release appears at https://github.com/leanprover/lean4/releases/
-  - Verify that the release is marked as a prerelease (this should have been done automatically by the CI release job).
-  - In the "previous tag" dropdown, select `v4.6.0`, and click "Generate release notes".
-    This will add a list of all the commits since the last stable version.
-    - Delete "update stage0" commits, and anything with a completely inscrutable commit message.
-- Next, we will move a curated list of downstream repos to the release candidate.
-  - This assumes that for each repository either:
-    * There is already a *reviewed* branch `bump/v4.7.0` containing the required adaptations.
-      The preparation of this branch is beyond the scope of this document.
-    * The repository does not need any changes to move to the new version.
-  - For each of the target repositories:
-    - If the repository does not need any changes (i.e. `bump/v4.7.0` does not exist) then create
-      a new PR updating `lean-toolchain` to `leanprover/lean4:v4.7.0-rc1` and running `lake update`.
-    - Otherwise:
-      - Checkout the `bump/v4.7.0` branch.
-      - Verify that the `lean-toolchain` is set to the nightly from which the release candidate was created.
-      - `git merge origin/master`
-      - Change the `lean-toolchain` to `leanprover/lean4:v4.7.0-rc1`
-      - In `lakefile.lean`, change any dependencies which were using `nightly-testing` or `bump/v4.7.0` branches
-        back to `master` or `main`, and run `lake update` for those dependencies.
-      - Run `lake build` to ensure that dependencies are found (but it's okay to stop it after a moment).
-      - `git commit`
-      - `git push`
-      - Open a PR from `bump/v4.7.0` to `master`, and either merge it yourself after CI, if appropriate,
-        or notify the maintainers that it is ready to go.
-    - Once the PR has been merged, tag `master` with `v4.7.0-rc1` and push this tag.
-  - We do this for the same list of repositories as for stable releases, see above.
-    As above, there are dependencies between these, and so the process above is iterative.
-    It greatly helps if you can merge the `bump/v4.7.0` PRs yourself!
-    It is essential for Mathlib CI that you then create the next `bump/v4.8.0` branch
-    for the next development cycle.
-    Set the `lean-toolchain` file on this branch to same `nightly` you used for this release.
-  - For Batteries/Aesop/Mathlib, which maintain a `nightly-testing` branch, make sure there is a tag
-    `nightly-testing-2024-02-29` with date corresponding to the nightly used for the release
-    (create it if not), and then on the `nightly-testing` branch `git reset --hard master`, and force push.
-- Make an announcement!
-  This should go in https://leanprover.zulipchat.com/#narrow/stream/113486-announce, with topic `v4.7.0-rc1`.
-  Please see previous announcements for suggested language.
-  You will want a few bullet points for main topics from the release notes.
-  Please also make sure that whoever is handling social media knows the release is out.
-- Begin the next development cycle (i.e. for `v4.8.0`) on the Lean repository, by making a PR that:
-  - Updates `src/CMakeLists.txt` to say `set(LEAN_VERSION_MINOR 8)`
-  - Replaces the "release notes will be copied" text in the `v4.6.0` section of `RELEASES.md` with the
-    finalized release notes from the `releases/v4.6.0` branch.
-  - Replaces the "development in progress" in the `v4.7.0` section of `RELEASES.md` with
-    ```
-    Release candidate, release notes will be copied from the branch `releases/v4.7.0` once completed.
-    ```
-    and inserts the following section before that section:
-    ```
-    v4.8.0
-    ----------
-    Development in progress.
-    ```
-  - Removes all the entries from the `./releases_drafts/` folder.
-  - Titled "chore: begin development cycle for v4.8.0"
-
-
-## Time estimates:
-Slightly longer than the corresponding steps for a stable release.
-Similar process, but more things go wrong.
-In particular, updating the downstream repositories is significantly more work
-(because we need to merge existing `bump/v4.7.0` branches, not just update a toolchain).
-
-# Preparing `bump/v4.7.0` branches
-
-While not part of the release process per se,
-this is a brief summary of the work that goes into updating Batteries/Aesop/Mathlib to new versions.
-
-Please read https://leanprover-community.github.io/contribute/tags_and_branches.html
-
-* Each repo has an unreviewed `nightly-testing` branch that
-  receives commits automatically from `master`, and
-  has its toolchain updated automatically for every nightly.
-  (Note: the aesop branch is not automated, and is updated on an as needed basis.)
-  As a consequence this branch is often broken.
-  A bot posts in the (private!) "Mathlib reviewers" stream on Zulip about the status of these branches.
-* We fix the breakages by committing directly to `nightly-testing`: there is no PR process.
-  * This can either be done by the person managing this process directly,
-    or by soliciting assistance from authors of files, or generally helpful people on Zulip!
-* Each repo has a `bump/v4.7.0` which accumulates reviewed changes adapting to new versions.
-* Once `nightly-testing` is working on a given nightly, say `nightly-2024-02-15`, we will create a PR to `bump/v4.7.0`.
-* For Mathlib, there is a script in `scripts/create-adaptation-pr.sh` that automates this process.
-* For Batteries and Aesop it is currently manual.
-* For all of these repositories, the process is the same:
-  * Make sure `bump/v4.7.0` is up to date with `master` (by merging `master`, no PR necessary)
-  * Create from `bump/v4.7.0` a `bump/nightly-2024-02-15` branch.
-  * In that branch, `git merge nightly-testing` to bring across changes from `nightly-testing`.
-  * Sanity check changes, commit, and make a PR to `bump/v4.7.0` from the `bump/nightly-2024-02-15` branch.
-  * Solicit review, merge the PR into `bump/v4.7.0`.
-* It is always okay to merge in the following directions:
-  `master` -> `bump/v4.7.0` -> `bump/nightly-2024-02-15` -> `nightly-testing`.
-  Please remember to push any merges you make to intermediate steps!
-
-# Writing the release notes
-
-We are currently trying a system where release notes are compiled all at once from someone looking through the commit history.
-The exact steps are a work in progress.
-Here is the general idea:
-
-* The work is done right on the `releases/v4.6.0` branch sometime after it is created but before the stable release is made.
-  The release notes for `v4.6.0` will later be copied to `master` when we begin a new development cycle.
-* There can be material for release notes entries in commit messages.
-* There can also be pre-written entries in `./releases_drafts`, which should be all incorporated in the release notes and then deleted from the branch.
-  See `./releases_drafts/README.md` for more information.
-* The release notes should be written from a downstream expert user's point of view.
-
-This section will be updated when the next release notes are written (for `v4.10.0`).

doc/dev/testing.md

@@ -1,10 +1,13 @@
-# Test Suite
+# Unit Testing
 
-After [building Lean](../make/index.md) you can run all the tests using
+You can run the unit tests after completing a build using the following:
+
+After [building lean](../make/index.md) you can run all the tests using
 ```
 cd build/release
 make test ARGS=-j4
 ```
+
 Change the 4 to the maximum number of parallel tests you want to
 allow. The best choice is the number of CPU cores on your machine as
 the tests are mostly CPU bound.  You can find the number of processors
@@ -16,12 +19,6 @@ adding the `-C stageN` argument. The default when run as above is stage 1.  The
 Lean tests will automatically use that stage's corresponding Lean
 executables
 
-Running `make test` will not pick up new test files; run
-```bash
-cmake build/release/stage1
-```
-to update the list of tests.
-
 You can also use `ctest` directly if you are in the right folder.  So
 to run stage1 tests with a 300 second timeout run this:
 
@@ -29,29 +26,25 @@ to run stage1 tests with a 300 second timeout run this:
 cd build/release/stage1
 ctest -j 4 --output-on-failure --timeout 300
 ```
-Useful `ctest` flags are `-R <name of test>` to run a single test, and
-`--rerun-failed` to run all tests that failed during the last run.
-You can also pass `ctest` flags via `make test ARGS="--rerun-failed"`.
 
 To get verbose output from ctest pass the `--verbose` command line
 option. Test output is normally suppressed and only summary
-information is displayed. This option will show all test output.
+information is displayed. This option will show all test output
 
-## Test Suite Organization
+Here is the summary of the test source code organization.
+All these tests are included by [/src/shell/CMakeLists.txt](https://github.com/leanprover/lean4/blob/master/src/shell/CMakeLists.txt):
 
-All these tests are included by [src/shell/CMakeLists.txt](https://github.com/leanprover/lean4/blob/master/src/shell/CMakeLists.txt):
-
-- [`tests/lean`](https://github.com/leanprover/lean4/tree/master/tests/lean/): contains tests that come equipped with a
-  .lean.expected.out file. The driver script [`test_single.sh`](https://github.com/leanprover/lean4/tree/master/tests/lean/test_single.sh) runs
+- `tests/lean`: contains tests that come equipped with a
+  .lean.expected.out file. The driver script `test_single.sh` runs
   each test and checks the actual output (*.produced.out) with the
   checked in expected output.
 
-- [`tests/lean/run`](https://github.com/leanprover/lean4/tree/master/tests/lean/run/): contains tests that are run through the lean
+- `tests/lean/run`: contains tests that are run through the lean
   command line one file at a time. These tests only look for error
   codes and do not check the expected output even though output is
   produced, it is ignored.
 
-- [`tests/lean/interactive`](https://github.com/leanprover/lean4/tree/master/tests/lean/interactive/): are designed to test server requests at a
+- `tests/lean/interactive`: are designed to test server requests at a
   given position in the input file. Each .lean file contains comments
   that indicate how to simulate a client request at that position.
   using a `--^` point to the line position. Example:
@@ -61,7 +54,7 @@ All these tests are included by [src/shell/CMakeLists.txt](https://github.com/le
     Bla.
       --^ textDocument/completion
     ```
-    In this example, the test driver [`test_single.sh`](https://github.com/leanprover/lean4/tree/master/tests/lean/interactive/test_single.sh) will simulate an
+    In this example, the test driver `test_single.sh` will simulate an
     auto-completion request at `Bla.`. The expected output is stored in
     a .lean.expected.out in the json format that is part of the
     [Language Server
@@ -78,57 +71,19 @@ All these tests are included by [src/shell/CMakeLists.txt](https://github.com/le
     --^ collectDiagnostics
     ```
 
-- [`tests/lean/server`](https://github.com/leanprover/lean4/tree/master/tests/lean/server/): Tests more of the Lean `--server` protocol.
+- `tests/lean/server`: Tests more of the Lean `--server` protocol.
   There are just a few of them, and it uses .log files containing
   JSON.
 
-- [`tests/compiler`](https://github.com/leanprover/lean4/tree/master/tests/compiler/): contains tests that will run the Lean compiler and
+- `tests/compiler`: contains tests that will run the Lean compiler and
   build an executable that is executed and the output is compared to
   the .lean.expected.out file. This test also contains a subfolder
-  [`foreign`](https://github.com/leanprover/lean4/tree/master/tests/compiler/foreign/) which shows how to extend Lean using C++.
+  `foreign` which shows how to extend Lean using C++.
 
-- [`tests/lean/trust0`](https://github.com/leanprover/lean4/tree/master/tests/lean/trust0): tests that run Lean in a mode that Lean doesn't
+- `tests/lean/trust0`: tests that run Lean in a mode that Lean doesn't
   even trust the .olean files (i.e., trust 0).
 
-- [`tests/bench`](https://github.com/leanprover/lean4/tree/master/tests/bench/): contains performance tests.
+- `tests/bench`: contains performance tests.
 
-- [`tests/plugin`](https://github.com/leanprover/lean4/tree/master/tests/plugin/): tests that compiled Lean code can be loaded into
+- `tests/plugin`: tests that compiled Lean code can be loaded into
   `lean` via the `--plugin` command line option.
-
-## Writing Good Tests
-
-Every test file should contain:
-* an initial `/-! -/` module docstring summarizing the test's purpose
-* a module docstring for each test section that describes what is tested
-  and, if not 100% clear, why that is the desirable behavior
-
-At the time of writing, most tests do not follow these new guidelines yet.
-For an example of a conforming test, see [`tests/lean/1971.lean`](https://github.com/leanprover/lean4/tree/master/tests/lean/1971.lean).
-
-## Fixing Tests
-
-When the Lean source code or the standard library are modified, some of the
-tests break because the produced output is slightly different, and we have
-to reflect the changes in the `.lean.expected.out` files.
-We should not blindly copy the new produced output since we may accidentally
-miss a bug introduced by recent changes.
-The test suite contains commands that allow us to see what changed in a convenient way.
-First, we must install [meld](http://meldmerge.org/). On Ubuntu, we can do it by simply executing
-
-```
-sudo apt-get install meld
-```
-
-Now, suppose `bad_class.lean` test is broken. We can see the problem by going to [`tests/lean`](https://github.com/leanprover/lean4/tree/master/tests/lean) directory and
-executing
-
-```
-./test_single.sh -i bad_class.lean
-```
-
-When the `-i` option is provided, `meld` is automatically invoked
-whenever there is discrepancy between the produced and expected
-outputs. `meld` can also be used to repair the problems.
-
-In Emacs, we can also execute `M-x lean4-diff-test-file` to check/diff the file of the current buffer.
-To mass-copy all `.produced.out` files to the respective `.expected.out` file, use `tests/lean/copy-produced`.

doc/elaborators.md

@@ -1,8 +0,0 @@
-## Elaborators
-
-TODO. See [Lean Together 2021: Metaprogramming in Lean
-4](https://youtu.be/hxQ1vvhYN_U) for an overview as well [the
-continuation](https://youtu.be/vy4JWIiiXSY) about tactic programming.
-For more information on antiquotations, see also §4.1 of [Beyond
-Notations: Hygienic Macro Expansion for Theorem Proving
-Languages](https://arxiv.org/pdf/2001.10490.pdf#page=11).

doc/examples.md

@@ -1,9 +0,0 @@
-Examples
-========
-
-- [Palindromes](examples/palindromes.lean.md)
-- [Binary Search Trees](examples/bintree.lean.md)
-- [A Certified Type Checker](examples/tc.lean.md)
-- [The Well-Typed Interpreter](examples/interp.lean.md)
-- [Dependent de Bruijn Indices](examples/deBruijn.lean.md)
-- [Parametric Higher-Order Abstract Syntax](examples/phoas.lean.md)

doc/examples/Certora2022/ex1.lean

@@ -1,22 +0,0 @@
-/- "Hello world" -/
-
-#eval "hello" ++ " " ++ "world"
--- "hello world"
-
-#check true
--- Bool
-
-def x := 10
-
-#eval x + 2
--- 12
-
-def double (x : Int) := 2*x
-
-#eval double 3
--- 6
-#check double
--- Int → Int
-example : double 4 = 8 := rfl
-
-

doc/examples/Certora2022/ex10.lean

@@ -1,19 +0,0 @@
-/- Dependent pattern matching -/
-
-inductive Vector (α : Type u) : Nat → Type u
-  | nil : Vector α 0
-  | cons : α → Vector α n → Vector α (n+1)
-
-infix:67 "::" => Vector.cons
-
-def Vector.zip : Vector α n → Vector β n → Vector (α × β) n
-  | nil, nil => nil
-  | a::as, b::bs => (a, b) :: zip as bs
-
-#print Vector.zip
-/-
-def Vector.zip.{u_1, u_2} : {α : Type u_1} → {n : Nat} → {β : Type u_2} → Vector α n → Vector β n → Vector (α × β) n :=
-fun {α} {n} {β} x x_1 =>
-  Vector.brecOn (motive := fun {n} x => {β : Type u_2} → Vector β n → Vector (α × β) n) x
-    ...
--/

doc/examples/Certora2022/ex11.lean

@@ -1,22 +0,0 @@
-/- Structures -/
-
-structure Point where
-  x : Int := 0
-  y : Int := 0
-  deriving Repr
-
-#eval Point.x (Point.mk 10 20)
--- 10
-
-#eval { x := 10, y := 20 : Point }
-
-def p : Point := { y := 20 }
-
-#eval p.x
-#eval p.y
-#eval { p with x := 5 }
--- { x := 5, y := 20 }
-
-structure Point3D extends Point where
-  z : Int
-

doc/examples/Certora2022/ex12.lean

@@ -1,28 +0,0 @@
-/- Type classes -/
-namespace Example
-
-class ToString (α : Type u) where
-  toString : α → String
-
-#check @ToString.toString
--- {α : Type u_1} → [self : ToString α] → α → String
-
-instance : ToString String where
-  toString s := s
-
-instance : ToString Bool where
-  toString b := if b then "true" else "false"
-
-#eval ToString.toString "hello"
-export ToString (toString)
-#eval toString true
--- "true"
--- #eval toString (true, "hello") -- Error
-
-instance [ToString α] [ToString β] : ToString (α × β) where
-  toString p := "(" ++ toString p.1 ++ ", " ++ toString p.2 ++ ")"
-
-#eval toString (true, "hello")
--- "(true, hello)"
-
-end Example

doc/examples/Certora2022/ex13.lean

@@ -1,44 +0,0 @@
-/- Type classes are heavily used in Lean -/
-namespace Example
-
-class Mul (α : Type u) where
-  mul : α → α → α
-
-infixl:70 " * " => Mul.mul
-
-def double [Mul α] (a : α) := a * a
-
-class Semigroup (α : Type u) extends Mul α where
-  mul_assoc : ∀ a b c : α, (a * b) * c = a * (b * c)
-
-instance : Semigroup Nat where
-  mul := Nat.mul
-  mul_assoc := Nat.mul_assoc
-
-#eval double 5
-
-class Functor (f : Type u → Type v) : Type (max (u+1) v) where
-  map : (α → β) → f α → f β
-
-infixr:100 " <$> " => Functor.map
-
-class LawfulFunctor (f : Type u → Type v) [Functor f] : Prop where
-  id_map   (x : f α) : id <$> x = x
-  comp_map (g : α → β) (h : β → γ) (x : f α) :(h ∘ g) <$> x = h <$> g <$> x
-
-end Example
-
-/-
-`Deriving instances automatically`
-
-We have seen `deriving Repr` in a few examples.
-It is an instance generator.
-Lean comes equipped with generators for the following classes.
-`Repr`, `Inhabited`, `BEq`, `DecidableEq`,
-`Hashable`, `Ord`, `FromToJson`, `SizeOf`
--/
-
-inductive Tree (α : Type u) where
-  | leaf (val : α)
-  | node (left right : Tree α)
-  deriving DecidableEq, Ord, Inhabited, Repr

doc/examples/Certora2022/ex14.lean

@@ -1,31 +0,0 @@
-/- Tactics -/
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq
-  apply And.intro
-  exact hp
-  apply And.intro
-  exact hq
-  exact hp
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq; apply And.intro hp; exact And.intro hq hp
-
-/- Structuring proofs -/
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq
-  apply And.intro
-  case left => exact hp
-  case right =>
-    apply And.intro
-    case left => exact hq
-    case right => exact hp
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq
-  apply And.intro
-  . exact hp
-  . apply And.intro
-    . exact hq
-    . exact hp

doc/examples/Certora2022/ex15.lean

@@ -1,19 +0,0 @@
-/- intro tactic variants -/
-
-example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro h
-  match h with
-  | Exists.intro w (And.intro hp hq) => exact Exists.intro w (And.intro hq hp)
-
-example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro (Exists.intro _ (And.intro hp hq))
-  exact Exists.intro _ (And.intro hq hp)
-
-example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro ⟨_, hp, hq⟩
-  exact ⟨_, hq, hp⟩
-
-example (α : Type) (p q : α → Prop) : (∃ x, p x ∨ q x) → ∃ x, q x ∨ p x := by
-  intro
-    | ⟨_, .inl h⟩ => exact ⟨_, .inr h⟩
-    | ⟨_, .inr h⟩ => exact ⟨_, .inl h⟩

doc/examples/Certora2022/ex16.lean

@@ -1,12 +0,0 @@
-/- Inaccessible names -/
-
-example : ∀ x y : Nat, x = y → y = x := by
-  intros
-  apply Eq.symm
-  assumption
-
-example : ∀ x y : Nat, x = y → y = x := by
-  intros
-  apply Eq.symm
-  rename_i a b hab
-  exact hab

doc/examples/Certora2022/ex17.lean

@@ -1,19 +0,0 @@
-/- More tactics -/
-
-example (p q : Nat → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro h
-  cases h with
-  | intro x hpq =>
-    cases hpq with
-    | intro hp hq =>
-      exists x
-
-example : p ∧ q → q ∧ p := by
-  intro p
-  cases p
-  constructor <;> assumption
-
-example : p ∧ ¬ p → q := by
-  intro h
-  cases h
-  contradiction

doc/examples/Certora2022/ex18.lean

@@ -1,20 +0,0 @@
-/- Structuring proofs (cont.) -/
-
-example : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by
-  intro h
-  have hp : p := h.left
-  have hqr : q ∨ r := h.right
-  show (p ∧ q) ∨ (p ∧ r)
-  cases hqr with
-  | inl hq => exact Or.inl ⟨hp, hq⟩
-  | inr hr => exact Or.inr ⟨hp, hr⟩
-
-example : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by
-  intro ⟨hp, hqr⟩
-  cases hqr with
-  | inl hq =>
-    have := And.intro hp hq
-    apply Or.inl; exact this
-  | inr hr =>
-    have := And.intro hp hr
-    apply Or.inr; exact this

doc/examples/Certora2022/ex19.lean

@@ -1,10 +0,0 @@
-/- Tactic combinators -/
-
-example : p → q → r → p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by
-  intros
-  repeat (any_goals constructor)
-  all_goals assumption
-
-example : p → q → r → p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by
-  intros
-  repeat (any_goals (first | assumption | constructor))

doc/examples/Certora2022/ex2.lean

@@ -1,14 +0,0 @@
-/- First-class functions -/
-
-def twice (f : Nat → Nat) (a : Nat) :=
-  f (f a)
-
-#check twice
--- (Nat → Nat) → Nat → Nat
-
-#eval twice (fun x => x + 2) 10
-
-theorem twice_add_2 (a : Nat) : twice (fun x => x + 2) a = a + 4 := rfl
-
--- `(· + 2)` is syntax sugar for `(fun x => x + 2)`.
-#eval twice (· + 2) 10

doc/examples/Certora2022/ex20.lean

@@ -1,22 +0,0 @@
-/- Rewriting -/
-
-example (f : Nat → Nat) (k : Nat) (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by
-  rw [h₂] -- replace k with 0
-  rw [h₁] -- replace f 0 with 0
-
-example (f : Nat → Nat) (k : Nat) (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by
-  rw [h₂, h₁]
-
-example (f : Nat → Nat) (a b : Nat) (h₁ : a = b) (h₂ : f a = 0) : f b = 0 := by
-  rw [← h₁, h₂]
-
-example (f : Nat → Nat) (a : Nat) (h : 0 + a = 0) : f a = f 0 := by
-  rw [Nat.zero_add] at h
-  rw [h]
-
-def Tuple (α : Type) (n : Nat) :=
-  { as : List α // as.length = n }
-
-example (n : Nat) (h : n = 0) (t : Tuple α n) : Tuple α 0 := by
-  rw [h] at t
-  exact t

doc/examples/Certora2022/ex21.lean

@@ -1,21 +0,0 @@
-/- Simplifier -/
-
-example (p : Nat → Prop) : (x + 0) * (0 + y * 1 + z * 0) = x * y := by
-  simp
-
-example (p : Nat → Prop) (h : p (x * y)) : p ((x + 0) * (0 + y * 1 + z * 0)) := by
-  simp; assumption
-
-example (p : Nat → Prop) (h : p ((x + 0) * (0 + y * 1 + z * 0))) : p (x * y) := by
-  simp at h; assumption
-
-def f (m n : Nat) : Nat :=
-  m + n + m
-
-example (h : n = 1) (h' : 0 = m) : (f m n) = n := by
-  simp [h, ←h', f]
-
-example (p : Nat → Prop) (h₁ : x + 0 = x') (h₂ : y + 0 = y')
-        : x + y + 0 = x' + y' := by
-  simp at *
-  simp [*]

doc/examples/Certora2022/ex22.lean

@@ -1,13 +0,0 @@
-/- Simplifier -/
-
-def mk_symm (xs : List α) :=
-  xs ++ xs.reverse
-
-@[simp] theorem reverse_mk_symm : (mk_symm xs).reverse = mk_symm xs := by
-  simp [mk_symm]
-
-theorem tst : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by
-  simp
-
-#print tst
--- Lean reverse_mk_symm, and List.reverse_append

doc/examples/Certora2022/ex23.lean

@@ -1,26 +0,0 @@
-/- split tactic -/
-
-def f (x y z : Nat) : Nat :=
-  match x, y, z with
-  | 5, _, _ => y
-  | _, 5, _ => y
-  | _, _, 5 => y
-  | _, _, _ => 1
-
-example : x ≠ 5 → y ≠ 5 → z ≠ 5 → z = w → f x y w = 1 := by
-  intros
-  simp [f]
-  split
-  . contradiction
-  . contradiction
-  . contradiction
-  . rfl
-
-def g (xs ys : List Nat) : Nat :=
-  match xs, ys with
-  | [a, b], _ => a+b+1
-  | _, [b, c] => b+1
-  | _, _      => 1
-
-example (xs ys : List Nat) (h : g xs ys = 0) : False := by
-  unfold g at h; split at h <;> simp_arith at h

doc/examples/Certora2022/ex24.lean

@@ -1,9 +0,0 @@
-/- induction tactic -/
-
-example (as : List α) (a : α) : (as.concat a).length = as.length + 1 := by
-  induction as with
-  | nil => rfl
-  | cons _ xs ih => simp [List.concat, ih]
-
-example (as : List α) (a : α) : (as.concat a).length = as.length + 1 := by
-  induction as <;> simp! [*]

doc/examples/Certora2022/ex3.lean

@@ -1,59 +0,0 @@
-/- Enumerated types -/
-
-inductive Weekday where
-  | sunday | monday | tuesday | wednesday
-  | thursday | friday | saturday
-
-#check Weekday.sunday
--- Weekday
-
-open Weekday
-#check sunday
-
-def natOfWeekday (d : Weekday) : Nat :=
-  match d with
-  | sunday    => 1
-  | monday    => 2
-  | tuesday   => 3
-  | wednesday => 4
-  | thursday  => 5
-  | friday    => 6
-  | saturday  => 7
-
-def Weekday.next (d : Weekday) : Weekday :=
-  match d with
-  | sunday    => monday
-  | monday    => tuesday
-  | tuesday   => wednesday
-  | wednesday => thursday
-  | thursday  => friday
-  | friday    => saturday
-  | saturday  => sunday
-
-def Weekday.previous : Weekday → Weekday
-  | sunday    => saturday
-  | monday    => sunday
-  | tuesday   => monday
-  | wednesday => tuesday
-  | thursday  => wednesday
-  | friday    => thursday
-  | saturday  => friday
-
-/- Proving theorems using tactics -/
-
-theorem Weekday.next_previous (d : Weekday) : d.next.previous = d :=
-  match d with
-  | sunday    => rfl
-  | monday    => rfl
-  | tuesday   => rfl
-  | wednesday => rfl
-  | thursday  => rfl
-  | friday    => rfl
-  | saturday  => rfl
-
-theorem Weekday.next_previous' (d : Weekday) : d.next.previous = d := by -- switch to tactic mode
-  cases d -- Creates 7 goals
-  rfl; rfl; rfl; rfl; rfl; rfl; rfl
-
-theorem Weekday.next_previous'' (d : Weekday) : d.next.previous = d := by
-  cases d <;> rfl

doc/examples/Certora2022/ex4.lean

@@ -1,20 +0,0 @@
-/- What is the type of Nat? -/
-
-#check 0
--- Nat
-#check Nat
--- Type
-#check Type
--- Type 1
-#check Type 1
--- Type 2
-#check Eq.refl 2
--- 2 = 2
-#check 2 = 2
--- Prop
-#check Prop
--- Type
-
-example : Prop = Sort 0   := rfl
-example : Type = Sort 1   := rfl
-example : Type 1 = Sort 2 := rfl

doc/examples/Certora2022/ex5.lean

@@ -1,21 +0,0 @@
-/- Implicit arguments and universe polymorphism -/
-
-def f (α β : Sort u) (a : α) (b : β) : α := a
-
-#eval f Nat String 1 "hello"
--- 1
-
-def g {α β : Sort u} (a : α) (b : β) : α := a
-
-#eval g 1 "hello"
-
-def h (a : α) (b : β) : α := a
-
-#check g
--- ?m.1 → ?m.2 → ?m.1
-#check @g
--- {α β : Sort u} → α → β → α
-#check @h
--- {α : Sort u_1} → {β : Sort u_2} → α → β → α
-#check g (α := Nat) (β := String)
--- Nat → String → Nat

doc/examples/Certora2022/ex6.lean

@@ -1,14 +0,0 @@
-/- Inductive Types -/
-
-inductive Tree (β : Type v) where
-  | leaf
-  | node (left : Tree β) (key : Nat) (value : β) (right : Tree β)
-  deriving Repr
-
-#eval Tree.node .leaf 10 true .leaf
--- Tree.node Tree.leaf 10 true Tree.leaf
-
-inductive Vector (α : Type u) : Nat → Type u
-  | nil : Vector α 0
-  | cons : α → Vector α n → Vector α (n+1)
-

doc/examples/Certora2022/ex7.lean

@@ -1,25 +0,0 @@
-/- Recursive functions -/
-
-#print Nat -- Nat is an inductive datatype
-
-def fib (n : Nat) : Nat :=
-  match n with
-  | 0 => 1
-  | 1 => 1
-  | n+2 => fib (n+1) + fib n
-
-example : fib 5 = 8 := rfl
-
-example : fib (n+2) = fib (n+1) + fib n := rfl
-
-#print fib
-/-
-def fib : Nat → Nat :=
-fun n =>
-  Nat.brecOn n fun n f =>
-    (match (motive := (n : Nat) → Nat.below n → Nat) n with
-      | 0 => fun x => 1
-      | 1 => fun x => 1
-      | Nat.succ (Nat.succ n) => fun x => x.fst.fst + x.fst.snd.fst.fst)
-      f
--/

doc/examples/Certora2022/ex8.lean

@@ -1,25 +0,0 @@
-/- Well-founded recursion -/
-
-def ack : Nat → Nat → Nat
-  | 0,   y   => y+1
-  | x+1, 0   => ack x 1
-  | x+1, y+1 => ack x (ack (x+1) y)
-termination_by x y => (x, y)
-
-def sum (a : Array Int) : Int :=
-  let rec go (i : Nat) :=
-     if _ : i < a.size then
-        a[i] + go (i+1)
-     else
-        0
-  termination_by a.size - i
-  go 0
-
-set_option pp.proofs true
-#print sum.go
-/-
-def sum.go : Array Int → Nat → Int :=
-fun a =>
-  WellFounded.fix (sum.go.proof_1 a) fun i a_1 =>
-    if h : i < Array.size a then Array.getOp a i + a_1 (i + 1) (sum.go.proof_2 a i h) else 0
--/

doc/examples/Certora2022/ex9.lean

@@ -1,44 +0,0 @@
-/- Mutual recursion -/
-
-inductive Term where
- | const : String → Term
- | app   : String → List Term → Term
-
-namespace Term
-mutual
- def numConsts : Term → Nat
-   | const _ => 1
-   | app _ cs => numConstsLst cs
-
- def numConstsLst : List Term → Nat
-   | [] => 0
-   | c :: cs => numConsts c + numConstsLst cs
-end
-
-mutual
-  def replaceConst (a b : String) : Term → Term
-   | const c => if a = c then const b else const c
-   | app f cs => app f (replaceConstLst a b cs)
-
-  def replaceConstLst (a b : String) : List Term → List Term
-   | [] => []
-   | c :: cs => replaceConst a b c :: replaceConstLst a b cs
-end
-
-/- Mutual recursion in theorems -/
-
-mutual
-  theorem numConsts_replaceConst (a b : String) (e : Term)
-            : numConsts (replaceConst a b e) = numConsts e := by
-    match e with
-    | const c => simp [replaceConst]; split <;> simp [numConsts]
-    | app f cs => simp [replaceConst, numConsts, numConsts_replaceConstLst a b cs]
-
-  theorem numConsts_replaceConstLst (a b : String) (es : List Term)
-            : numConstsLst (replaceConstLst a b es) = numConstsLst es := by
-    match es with
-    | [] => simp [replaceConstLst, numConstsLst]
-    | c :: cs =>
-      simp [replaceConstLst, numConstsLst, numConsts_replaceConst a b c,
-            numConsts_replaceConstLst a b cs]
-end

doc/examples/ICERM2022/ctor.lean

@@ -1,45 +0,0 @@
-import Lean
-
-open Lean Meta
-
-def ctor (mvarId : MVarId) (idx : Nat) : MetaM (List MVarId) := do
-  /- Set `MetaM` context using `mvarId` -/
-  mvarId.withContext do
-    /- Fail if the metavariable is already assigned. -/
-    mvarId.checkNotAssigned `ctor
-    /- Retrieve the target type, instantiateMVars, and use `whnf`. -/
-    let target ← mvarId.getType'
-    let .const declName us := target.getAppFn
-      | throwTacticEx `ctor mvarId "target is not an inductive datatype"
-    let .inductInfo { ctors, .. } ← getConstInfo declName
-      | throwTacticEx `ctor mvarId "target is not an inductive datatype"
-    if idx = 0 then
-      throwTacticEx `ctor mvarId "invalid index, it must be > 0"
-    else if h : idx - 1 < ctors.length then
-      mvarId.apply (.const ctors[idx - 1] us)
-    else
-      throwTacticEx `ctor mvarId "invalid index, inductive datatype has only {ctors.length} constructors"
-
-open Elab Tactic
-
-elab "ctor" idx:num : tactic =>
-  liftMetaTactic (ctor · idx.getNat)
-
-example (p : Prop) : p := by
-  ctor 1 -- Error
-
-example (h : q) : p ∨ q := by
-  ctor 0 -- Error
-  exact h
-
-example (h : q) : p ∨ q := by
-  ctor 3 -- Error
-  exact h
-
-example (h : q) : p ∨ q := by
-  ctor 2
-  exact h
-
-example (h : q) : p ∨ q := by
-  ctor 1
-  exact h -- Error

doc/examples/ICERM2022/meta.lean

@@ -1,82 +0,0 @@
-import Lean
-
-open Lean Meta
-
-def ex1 (declName : Name) : MetaM Unit := do
-  let info ← getConstInfo declName
-  IO.println s!"{declName} : {← ppExpr info.type}"
-  if let some val := info.value? then
-    IO.println s!"{declName} : {← ppExpr val}"
-
-#eval ex1 ``Nat
-
-def ex2 (declName : Name) : MetaM Unit := do
-  let info ← getConstInfo declName
-  trace[Meta.debug] "{declName} : {info.type}"
-  if let some val := info.value? then
-    trace[Meta.debug] "{declName} : {val}"
-
-#eval ex2 ``Add.add
-
-set_option trace.Meta.debug true in
-#eval ex2 ``Add.add
-
-def ex3 (declName : Name) : MetaM Unit := do
-  let info ← getConstInfo declName
-  forallTelescope info.type fun xs type => do
-    trace[Meta.debug] "hypotheses : {xs}"
-    trace[Meta.debug] "resultType : {type}"
-    for x in xs do
-      trace[Meta.debug] "{x} : {← inferType x}"
-
-def myMin [LT α] [DecidableRel (α := α) (·<·)] (a b : α) : α :=
-  if a < b then
-    a
-  else
-    b
-
-set_option trace.Meta.debug true in
-#eval ex3 ``myMin
-
-def ex4 : MetaM Unit := do
-  let nat := mkConst ``Nat
-  withLocalDeclD `a nat fun a =>
-  withLocalDeclD `b nat fun b => do
-    let e ← mkAppM ``HAdd.hAdd #[a, b]
-    trace[Meta.debug] "{e} : {← inferType e}"
-    let e ← mkAdd a (mkNatLit 5)
-    trace[Meta.debug] "added 5: {e}"
-    let e ← whnf e
-    trace[Meta.debug] "whnf: {e}"
-    let e ← reduce e
-    trace[Meta.debug] "reduced: {e}"
-    let a_plus_1 ← mkAdd a (mkNatLit 1)
-    let succ_a   := mkApp (mkConst ``Nat.succ) a
-    trace[Meta.debug] "({a_plus_1} =?= {succ_a}) == {← isDefEq a_plus_1 succ_a}"
-    let m ← mkFreshExprMVar nat
-    let m_plus_1 ← mkAdd m (mkNatLit 1)
-    trace[Meta.debug] "m_plus_1: {m_plus_1}"
-    unless (← isDefEq m_plus_1 succ_a) do throwError "isDefEq failed"
-    trace[Meta.debug] "m_plus_1: {m_plus_1}"
-
-set_option trace.Meta.debug true in
-#eval ex4
-
-open Elab Term
-
-def ex5 : TermElabM Unit := do
-  let nat := Lean.mkConst ``Nat
-  withLocalDeclD `a nat fun a => do
-  withLocalDeclD `b nat fun b => do
-    let ab ← mkAppM ``HAdd.hAdd #[a, b]
-    let abStx ← exprToSyntax ab
-    let aStx ← exprToSyntax a
-    let stx ← `(fun x => if x < 10 then $abStx + x else x + $aStx)
-    let e ← elabTerm stx none
-    trace[Meta.debug] "{e} : {← inferType e}"
-    let e := mkApp e (mkNatLit 5)
-    let e ← whnf e
-    trace[Meta.debug] "{e}"
-
-set_option trace.Meta.debug true in
-#eval ex5

doc/examples/ICERM2022/notation.lean

@@ -1,49 +0,0 @@
-import Lean
-
-def f (x y : Nat) := x * y + 1
-
-infixl:65 " *' " => f
-
-#check 2 *' 3
-
-notation "unitTest " x => Prod.mk x ()
-
-#check unitTest 42
-
-notation "parenthesisTest " x => Nat.sub (x)
-#check parenthesisTest 12
-
-def Set (α : Type u) := α → Prop
-def setOf {α : Type} (p : α → Prop) : Set α := p
-notation "{ " x " | " p " }" => setOf (fun x => p)
-
-#check { x | x ≤ 1 }
-
-notation "cdotTest " "(" x ", " y ")" => Prod.map (· + 1) (1 + ·) (x, y)
-
-#check cdotTest (13, 12)
-
-notation "tupleFunctionTest " "(" x ", " y ")"=> Prod.map (Nat.add 1) (Nat.add 2) (x, y)
-
-#check tupleFunctionTest (15, 12)
-
-notation "diag " x => Prod.mk x x
-
-#check diag 12
-
-open Lean Meta PrettyPrinter Delaborator SubExpr in
-@[delab app.Prod.mk] def delabDoubleRhsTest : Delab := do
-   let e ← getExpr
-   let #[_, _, x, y] := e.getAppArgs | failure
-   guard (← isDefEq x y) 
-   let stx ← withAppArg delab
-   `(diag $stx)     
-
-#check diag 3
-#check (3, 3)
-#check (3, 4)
-#check (2+1, 3)
-#check (true, true)
-
-
-

doc/examples/NFM2022/nfm1.lean

@@ -1,22 +0,0 @@
-/- "Hello world" -/
-
-#eval "hello" ++ " " ++ "world"
--- "hello world"
-
-#check true
--- Bool
-
-def x := 10
-
-#eval x + 2
--- 12
-
-def double (x : Int) := 2*x
-
-#eval double 3
--- 6
-#check double
--- Int → Int
-example : double 4 = 8 := rfl
-
-

doc/examples/NFM2022/nfm10.lean

@@ -1,19 +0,0 @@
-/- Dependent pattern matching -/
-
-inductive Vector (α : Type u) : Nat → Type u
-  | nil : Vector α 0
-  | cons : α → Vector α n → Vector α (n+1)
-
-infix:67 "::" => Vector.cons
-
-def Vector.zip : Vector α n → Vector β n → Vector (α × β) n
-  | nil, nil => nil
-  | a::as, b::bs => (a, b) :: zip as bs
-
-#print Vector.zip
-/-
-def Vector.zip.{u_1, u_2} : {α : Type u_1} → {n : Nat} → {β : Type u_2} → Vector α n → Vector β n → Vector (α × β) n :=
-fun {α} {n} {β} x x_1 =>
-  Vector.brecOn (motive := fun {n} x => {β : Type u_2} → Vector β n → Vector (α × β) n) x
-    ...
--/

doc/examples/NFM2022/nfm11.lean

@@ -1,22 +0,0 @@
-/- Structures -/
-
-structure Point where
-  x : Int := 0
-  y : Int := 0
-  deriving Repr
-
-#eval Point.x (Point.mk 10 20)
--- 10
-
-#eval { x := 10, y := 20 : Point }
-
-def p : Point := { y := 20 }
-
-#eval p.x
-#eval p.y
-#eval { p with x := 5 }
--- { x := 5, y := 20 }
-
-structure Point3D extends Point where
-  z : Int
-

doc/examples/NFM2022/nfm12.lean

@@ -1,28 +0,0 @@
-/- Type classes -/
-namespace Example
-
-class ToString (α : Type u) where
-  toString : α → String
-
-#check @ToString.toString
--- {α : Type u_1} → [self : ToString α] → α → String
-
-instance : ToString String where
-  toString s := s
-
-instance : ToString Bool where
-  toString b := if b then "true" else "false"
-
-#eval ToString.toString "hello"
-export ToString (toString)
-#eval toString true
--- "true"
--- #eval toString (true, "hello") -- Error
-
-instance [ToString α] [ToString β] : ToString (α × β) where
-  toString p := "(" ++ toString p.1 ++ ", " ++ toString p.2 ++ ")"
-
-#eval toString (true, "hello")
--- "(true, hello)"
-
-end Example

doc/examples/NFM2022/nfm13.lean

@@ -1,44 +0,0 @@
-/- Type classes are heavily used in Lean -/
-namespace Example
-
-class Mul (α : Type u) where
-  mul : α → α → α
-
-infixl:70 " * " => Mul.mul
-
-def double [Mul α] (a : α) := a * a
-
-class Semigroup (α : Type u) extends Mul α where
-  mul_assoc : ∀ a b c : α, (a * b) * c = a * (b * c)
-
-instance : Semigroup Nat where
-  mul := Nat.mul
-  mul_assoc := Nat.mul_assoc
-
-#eval double 5
-
-class Functor (f : Type u → Type v) : Type (max (u+1) v) where
-  map : (α → β) → f α → f β
-
-infixr:100 " <$> " => Functor.map
-
-class LawfulFunctor (f : Type u → Type v) [Functor f] : Prop where
-  id_map   (x : f α) : id <$> x = x
-  comp_map (g : α → β) (h : β → γ) (x : f α) :(h ∘ g) <$> x = h <$> g <$> x
-
-end Example
-
-/-
-`Deriving instances automatically`
-
-We have seen `deriving Repr` in a few examples.
-It is an instance generator.
-Lean comes equipped with generators for the following classes.
-`Repr`, `Inhabited`, `BEq`, `DecidableEq`,
-`Hashable`, `Ord`, `FromToJson`, `SizeOf`
--/
-
-inductive Tree (α : Type u) where
-  | leaf (val : α)
-  | node (left right : Tree α)
-  deriving DecidableEq, Ord, Inhabited, Repr

doc/examples/NFM2022/nfm14.lean

@@ -1,31 +0,0 @@
-/- Tactics -/
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq
-  apply And.intro
-  exact hp
-  apply And.intro
-  exact hq
-  exact hp
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq; apply And.intro hp; exact And.intro hq hp
-
-/- Structuring proofs -/
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq
-  apply And.intro
-  case left => exact hp
-  case right =>
-    apply And.intro
-    case left => exact hq
-    case right => exact hp
-
-example : p → q → p ∧ q ∧ p := by
-  intro hp hq
-  apply And.intro
-  . exact hp
-  . apply And.intro
-    . exact hq
-    . exact hp

doc/examples/NFM2022/nfm15.lean

@@ -1,19 +0,0 @@
-/- intro tactic variants -/
-
-example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro h
-  match h with
-  | Exists.intro w (And.intro hp hq) => exact Exists.intro w (And.intro hq hp)
-
-example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro (Exists.intro _ (And.intro hp hq))
-  exact Exists.intro _ (And.intro hq hp)
-
-example (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro ⟨_, hp, hq⟩
-  exact ⟨_, hq, hp⟩
-
-example (α : Type) (p q : α → Prop) : (∃ x, p x ∨ q x) → ∃ x, q x ∨ p x := by
-  intro
-    | ⟨_, .inl h⟩ => exact ⟨_, .inr h⟩
-    | ⟨_, .inr h⟩ => exact ⟨_, .inl h⟩

doc/examples/NFM2022/nfm16.lean

@@ -1,12 +0,0 @@
-/- Inaccessible names -/
-
-example : ∀ x y : Nat, x = y → y = x := by
-  intros
-  apply Eq.symm
-  assumption
-
-example : ∀ x y : Nat, x = y → y = x := by
-  intros
-  apply Eq.symm
-  rename_i a b hab
-  exact hab

doc/examples/NFM2022/nfm17.lean

@@ -1,19 +0,0 @@
-/- More tactics -/
-
-example (p q : Nat → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by
-  intro h
-  cases h with
-  | intro x hpq =>
-    cases hpq with
-    | intro hp hq =>
-      exists x
-
-example : p ∧ q → q ∧ p := by
-  intro p
-  cases p
-  constructor <;> assumption
-
-example : p ∧ ¬ p → q := by
-  intro h
-  cases h
-  contradiction

doc/examples/NFM2022/nfm18.lean

@@ -1,20 +0,0 @@
-/- Structuring proofs (cont.) -/
-
-example : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by
-  intro h
-  have hp : p := h.left
-  have hqr : q ∨ r := h.right
-  show (p ∧ q) ∨ (p ∧ r)
-  cases hqr with
-  | inl hq => exact Or.inl ⟨hp, hq⟩
-  | inr hr => exact Or.inr ⟨hp, hr⟩
-
-example : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by
-  intro ⟨hp, hqr⟩
-  cases hqr with
-  | inl hq =>
-    have := And.intro hp hq
-    apply Or.inl; exact this
-  | inr hr =>
-    have := And.intro hp hr
-    apply Or.inr; exact this

doc/examples/NFM2022/nfm19.lean

@@ -1,10 +0,0 @@
-/- Tactic combinators -/
-
-example : p → q → r → p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by
-  intros
-  repeat (any_goals constructor)
-  all_goals assumption
-
-example : p → q → r → p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by
-  intros
-  repeat (any_goals (first | assumption | constructor))

doc/examples/NFM2022/nfm2.lean

@@ -1,14 +0,0 @@
-/- First-class functions -/
-
-def twice (f : Nat → Nat) (a : Nat) :=
-  f (f a)
-
-#check twice
--- (Nat → Nat) → Nat → Nat
-
-#eval twice (fun x => x + 2) 10
-
-theorem twice_add_2 (a : Nat) : twice (fun x => x + 2) a = a + 4 := rfl
-
--- `(· + 2)` is syntax sugar for `(fun x => x + 2)`.
-#eval twice (· + 2) 10

doc/examples/NFM2022/nfm20.lean

@@ -1,22 +0,0 @@
-/- Rewriting -/
-
-example (f : Nat → Nat) (k : Nat) (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by
-  rw [h₂] -- replace k with 0
-  rw [h₁] -- replace f 0 with 0
-
-example (f : Nat → Nat) (k : Nat) (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by
-  rw [h₂, h₁]
-
-example (f : Nat → Nat) (a b : Nat) (h₁ : a = b) (h₂ : f a = 0) : f b = 0 := by
-  rw [← h₁, h₂]
-
-example (f : Nat → Nat) (a : Nat) (h : 0 + a = 0) : f a = f 0 := by
-  rw [Nat.zero_add] at h
-  rw [h]
-
-def Tuple (α : Type) (n : Nat) :=
-  { as : List α // as.length = n }
-
-example (n : Nat) (h : n = 0) (t : Tuple α n) : Tuple α 0 := by
-  rw [h] at t
-  exact t

doc/examples/NFM2022/nfm21.lean

@@ -1,21 +0,0 @@
-/- Simplifier -/
-
-example (p : Nat → Prop) : (x + 0) * (0 + y * 1 + z * 0) = x * y := by
-  simp
-
-example (p : Nat → Prop) (h : p (x * y)) : p ((x + 0) * (0 + y * 1 + z * 0)) := by
-  simp; assumption
-
-example (p : Nat → Prop) (h : p ((x + 0) * (0 + y * 1 + z * 0))) : p (x * y) := by
-  simp at h; assumption
-
-def f (m n : Nat) : Nat :=
-  m + n + m
-
-example (h : n = 1) (h' : 0 = m) : (f m n) = n := by
-  simp [h, ←h', f]
-
-example (p : Nat → Prop) (h₁ : x + 0 = x') (h₂ : y + 0 = y')
-        : x + y + 0 = x' + y' := by
-  simp at *
-  simp [*]

doc/examples/NFM2022/nfm22.lean

@@ -1,13 +0,0 @@
-/- Simplifier -/
-
-def mk_symm (xs : List α) :=
-  xs ++ xs.reverse
-
-@[simp] theorem reverse_mk_symm : (mk_symm xs).reverse = mk_symm xs := by
-  simp [mk_symm]
-
-theorem tst : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by
-  simp
-
-#print tst
--- Lean reverse_mk_symm, and List.reverse_append

doc/examples/NFM2022/nfm23.lean

@@ -1,26 +0,0 @@
-/- split tactic -/
-
-def f (x y z : Nat) : Nat :=
-  match x, y, z with
-  | 5, _, _ => y
-  | _, 5, _ => y
-  | _, _, 5 => y
-  | _, _, _ => 1
-
-example : x ≠ 5 → y ≠ 5 → z ≠ 5 → z = w → f x y w = 1 := by
-  intros
-  simp [f]
-  split
-  . contradiction
-  . contradiction
-  . contradiction
-  . rfl
-
-def g (xs ys : List Nat) : Nat :=
-  match xs, ys with
-  | [a, b], _ => a+b+1
-  | _, [b, c] => b+1
-  | _, _      => 1
-
-example (xs ys : List Nat) (h : g xs ys = 0) : False := by
-  unfold g at h; split at h <;> simp_arith at h

doc/examples/NFM2022/nfm24.lean

@@ -1,9 +0,0 @@
-/- induction tactic -/
-
-example (as : List α) (a : α) : (as.concat a).length = as.length + 1 := by
-  induction as with
-  | nil => rfl
-  | cons x xs ih => simp [List.concat, ih]
-
-example (as : List α) (a : α) : (as.concat a).length = as.length + 1 := by
-  induction as <;> simp! [*]