chore: update stage0

Without this change, we would not inline anything inside
let x_42 := casesOn x_3 fun .. => ... here ...

.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,45 +0,0 @@
----
-name: Bug report
-about: Create a bug report
-title: ''
-labels: bug
-assignees: ''
-
----
-
-### Prerequisites
-
-* [ ] Put an X between the brackets on this line if you have done all of the following:
-    * 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 mathlib4 or std4.
-
-### Description
-
-[Clear and concise description of the issue]
-
-### Context
-
-[Broader context that the issue occured 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 `#eval Lean.versionString` or of `lean --version` in the folder that the issue occured in]
-[OS version]
-
-### 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,14 +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.
-* 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.
-
----
-
-Closes #0000 (`RFC` or `bug` issue number fixed by this PR, if any)

.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@v3
-    - name: actionlint
-      uses: raven-actions/actionlint@v1
-      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/changelog.yml

@@ -0,0 +1,33 @@
+name: add PR to changelog
+
+on:
+  # needs read/write GH token, do *not* execute arbitrary code from PR
+  pull_request_target:
+    types: [closed]
+
+jobs:
+  update-changelog:
+    if: |
+      github.event.pull_request.merged == true &&
+      contains(github.event.pull_request.labels.*.name, 'changelog') &&
+      github.base_ref == 'master'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+        with:
+          # needs sufficiently elevated token to override branch protection rules
+          token: ${{ secrets.PUSH_NIGHTLY_TOKEN }}
+      - name: Update changelog
+        run: |
+          set -euxo pipefail
+          escaped_link=$(sed -e 's/[\/&]/\\&/g' <<'EOF'
+          [${{ github.event.pull_request.title}}](${{ github.event.pull_request.html_url }})
+          EOF
+          )
+          # insert link below first dashes line (https://stackoverflow.com/a/9453461/161659)
+          sed -i "0,/^---*/s/^---*/\0\n\n* $escaped_link./" RELEASES.md
+          # commit as github-actions bot (https://github.com/orgs/community/discussions/26560#discussioncomment-3252339)
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git config user.name "github-actions[bot]"
+          git commit -i RELEASES.md -m "doc: update changelog"
+          git push

.github/workflows/check-prelude.yml

@@ -1,26 +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
-      - 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 -name '*.lean' -print0)
-          if [ -n "$failed_files" ]; then
-            echo -e "The following files should use 'prelude':\n$failed_files"
-            exit 1
-          fi

.github/workflows/ci.yml

@@ -6,8 +6,8 @@ on:
     tags:
       - '*'
   pull_request:
-    types: [opened, synchronize, reopened, labeled]
-  merge_group:
+    branches:
+      - master
   schedule:
     - cron: '0 7 * * *'  # 8AM CET/11PM PT
 
@@ -16,242 +16,103 @@ concurrency:
   cancel-in-progress: true
 
 jobs:
-
-  # This job determines various settings for the following CI runs; see the `outputs` for details
-  configure:
+  set-nightly:
     runs-on: ubuntu-latest
     outputs:
-      # Should we run only a quick CI? Yes on a pull request without the full-ci label
-      quick: ${{ steps.set-quick.outputs.quick }}
-      # 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: Run quick CI?
-        id: set-quick
-        env:
-          quick: ${{
-            github.event_name == 'pull_request' && !contains( github.event.pull_request.labels.*.name, 'full-ci')
-           }}
-        run: |
-          echo "quick=${{env.quick}}" >> "$GITHUB_OUTPUT"
-
-      - name: Configure build matrix
-        id: set-matrix
-        uses: actions/github-script@v7
-        with:
-          script: |
-            const quick = ${{ steps.set-quick.outputs.quick }};
-            console.log(`quick: ${quick}`)
-            let matrix = [
-              {
-                // portable release build: use channel with older glibc (2.27)
-                "name": "Linux LLVM",
-                "os": "ubuntu-latest",
-                "release": false,
-                "quick": false,
-                "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/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": "ubuntu-latest",
-                "release": true,
-                "quick": 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/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": "ubuntu-latest",
-                "check-stage3": true,
-                "test-speedcenter": true,
-                "quick": false,
-              },
-              {
-                "name": "Linux Debug",
-                "os": "ubuntu-latest",
-                "quick": false,
-                "CMAKE_OPTIONS": "-DCMAKE_BUILD_TYPE=Debug",
-                // exclude seriously slow tests
-                "CTEST_OPTIONS": "-E 'interactivetest|leanpkgtest|laketest|benchtest'"
-              },
-              {
-                "name": "Linux fsanitize",
-                "os": "ubuntu-latest",
-                "quick": false,
-                // 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 seriously slow/problematic tests (laketests crash)
-                "CTEST_OPTIONS": "-E 'interactivetest|leanpkgtest|laketest|benchtest'"
-              },
-              {
-                "name": "macOS",
-                "os": "macos-latest",
-                "release": true,
-                "quick": false,
-                "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-latest",
-                "release": true,
-                "quick": false,
-                "cross": true,
-                "cross_target": "aarch64-apple-darwin",
-                "shell": "bash -euxo pipefail {0}",
-                "CMAKE_OPTIONS": "-DUSE_GMP=OFF -DLEAN_INSTALL_SUFFIX=-darwin_aarch64",
-                "llvm-url": "https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-aarch64-apple-darwin.tar.zst 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-aarch64-* lean-llvm-x86_64-*",
-                "binary-check": "otool -L",
-                "tar": "gtar" // https://github.com/actions/runner-images/issues/2619
-              },
-              {
-                "name": "Windows",
-                "os": "windows-2022",
-                "release": true,
-                "quick": false,
-                "shell": "msys2 {0}",
-                "CMAKE_OPTIONS": "-G \"Unix Makefiles\" -DUSE_GMP=OFF",
-                // 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": "ubuntu-latest",
-                "CMAKE_OPTIONS": "-DUSE_GMP=OFF -DLEAN_INSTALL_SUFFIX=-linux_aarch64",
-                "release": true,
-                "quick": false,
-                "cross": true,
-                "cross_target": "aarch64-unknown-linux-gnu",
-                "shell": "nix-shell --arg pkgsDist \"import (fetchTarball \\\"channel:nixos-19.03\\\") {{ localSystem.config = \\\"aarch64-unknown-linux-gnu\\\"; }}\" --run \"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 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-aarch64-* lean-llvm-x86_64-*"
-              },
-              {
-                "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",
-                "cmultilib": true,
-                "release": true,
-                "quick": false,
-                "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",
-                "wasm": true,
-                "cmultilib": true,
-                "release": true,
-                "quick": false,
-                "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\""
-              }
-            ];
-            console.log(`matrix:\n${JSON.stringify(matrix, null, 2)}`)
-            if (quick) {
-              return matrix.filter((job) => job.quick)
-            } else {
-              return matrix
-            }
-
       - name: Checkout
         uses: actions/checkout@v3
         # don't schedule nightlies on forks
         if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4'
       - name: Set Nightly
         if: github.event_name == 'schedule' && github.repository == 'leanprover/lean4'
-        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
-
   build:
-    needs: [configure]
+    needs: set-nightly
     if: github.event_name != 'schedule' || github.repository == 'leanprover/lean4'
-    strategy:
-      matrix:
-        include: ${{fromJson(needs.configure.outputs.matrix)}}
-      # complete all jobs
-      fail-fast: false
     runs-on: ${{ matrix.os }}
     defaults:
       run:
         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/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|leanlaketest_git'
+          - name: Linux
+            os: ubuntu-latest
+            check-stage3: true
+            test-speedcenter: true
+          - name: Linux Debug
+            os: ubuntu-latest
+            CMAKE_OPTIONS: -DCMAKE_BUILD_TYPE=Debug
+            # exclude seriously slow tests
+            CTEST_OPTIONS: -E 'interactivetest|leanpkgtest|laketest'
+          - 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 seriously slow/problematic tests (laketests crash)
+            CTEST_OPTIONS: -E 'interactivetest|leanpkgtest|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/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-latest
+            release: true
+            cross: true
+            shell: bash -euxo pipefail {0}
+            CMAKE_OPTIONS: -DCMAKE_OSX_DEPLOYMENT_TARGET=10.15 -DUSE_GMP=OFF -DLEAN_INSTALL_SUFFIX=-darwin_aarch64
+            llvm-url: https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-aarch64-apple-darwin.tar.zst https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-x86_64-apple-darwin.tar.zst
+            prepare-llvm: EXTRA_FLAGS=--target=aarch64-apple-darwin ../script/prepare-llvm-macos.sh lean-llvm-aarch64-* lean-llvm-x86_64-*
+            binary-check: otool -L
+            tar: gtar  # https://github.com/actions/runner-images/issues/2619
+          - 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/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: ubuntu-latest
+            CMAKE_OPTIONS: -DCMAKE_PREFIX_PATH=$GMP -DLEAN_INSTALL_SUFFIX=-linux_aarch64
+            release: true
+            cross: true
+            shell: nix-shell --arg pkgsDist "import (fetchTarball \"channel:nixos-19.03\") {{ localSystem.config = \"aarch64-unknown-linux-gnu\"; }}" --run "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 https://github.com/leanprover/lean-llvm/releases/download/15.0.1/lean-llvm-aarch64-linux-gnu.tar.zst
+            prepare-llvm: EXTRA_FLAGS=--target=aarch64-unknown-linux-gnu ../script/prepare-llvm-linux.sh lean-llvm-aarch64-* lean-llvm-x86_64-*
+      # complete all jobs
+      fail-fast: false
     name: ${{ matrix.name }}
     env:
       # must be inside workspace
@@ -264,19 +125,16 @@ jobs:
       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@v3
         with:
           submodules: true
-          # 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: Install Nix
         uses: cachix/install-nix-action@v18
         with:
           install_url: https://releases.nixos.org/nix/nix-2.12.0/install
-        if: matrix.os == 'ubuntu-latest' && !matrix.cmultilib
+        if: matrix.os == 'ubuntu-latest'
       - name: Install MSYS2
         uses: msys2/setup-msys2@v2
         with:
@@ -288,17 +146,6 @@ jobs:
         run: |
           brew install ccache tree zstd coreutils gmp
         if: matrix.os == 'macos-latest'
-      - name: Setup emsdk
-        uses: mymindstorm/setup-emsdk@v12
-        with:
-          version: 3.1.44
-          actions-cache-folder: emsdk
-        if: matrix.wasm
-      - name: Install 32bit c libs
-        run: |
-          sudo apt-get update
-          sudo apt-get install -y gcc-multilib g++-multilib ccache
-        if: matrix.cmultilib
       - name: Cache
         uses: actions/cache@v3
         with:
@@ -323,29 +170,14 @@ jobs:
           mkdir build
           cd build
           ulimit -c unlimited # coredumps
-          # 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
+          OPTIONS=()
           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 }})
+          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 .. ${{ matrix.CMAKE_OPTIONS }} ${OPTIONS[@]+"${OPTIONS[@]}"} -DLEAN_INSTALL_PREFIX=$PWD/..
@@ -356,13 +188,13 @@ jobs:
       - 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|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
+          if [[ '${{ startsWith(github.ref, 'refs/tags/') && matrix.release }}' == true || -n '${{ needs.set-nightly.outputs.nightly }}' ]]; then
             ${{ matrix.tar || 'tar' }} cf - $dir | zstd -T0 --no-progress -19 -o pack/$dir.tar.zst
             zip -rq pack/$dir.zip $dir
           else
@@ -382,23 +214,23 @@ jobs:
           cd build/stage1
           ulimit -c unlimited # coredumps
           # exclude nonreproducible test
-          ctest -j4 --output-on-failure ${{ matrix.CTEST_OPTIONS }} < /dev/null
-        if: (matrix.wasm || !matrix.cross) && needs.configure.outputs.quick == 'false'
+          ctest -j4 --output-on-failure -E leanlaketest_git ${{ matrix.CTEST_OPTIONS }} < /dev/null
+        if: ${{ !matrix.cross }}
       - name: Check Test Binary
         run: ${{ matrix.binary-check }} tests/compiler/534.lean.out
-        if: ${{ !matrix.cross && needs.configure.outputs.quick == 'false' }}
+        if: ${{ !matrix.cross }}
       - name: Build Stage 2
         run: |
           cd build
           ulimit -c unlimited # coredumps
           make -j4 stage2
-        if: matrix.test-speedcenter
+        if: matrix.build-stage2 || matrix.check-stage3
       - name: Check Stage 3
         run: |
           cd build
           ulimit -c unlimited # coredumps
           make -j4 check-stage3
-        if: matrix.test-speedcenter
+        if: matrix.check-stage3
       - name: Test Speedcenter Benchmarks
         run: |
           echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
@@ -410,53 +242,31 @@ jobs:
         run: |
           cd build
           ulimit -c unlimited # coredumps
-          # clean rebuild in case of Makefile changes
-          make update-stage0 && rm -rf ./stage* && make -j4
-        if: matrix.name == 'Linux' && needs.configure.outputs.quick == 'false'
+          make update-stage0 && make -j4
+        if: matrix.name == 'Linux'
       - name: CCache stats
         run: ccache -s
       - name: Show stacktrace for coredumps
-        if: ${{ failure() && matrix.os == 'ubuntu-latest' }}
+        if: ${{ failure() }} && matrix.os == 'ubuntu-latest'
         run: |
           for c in coredumps/*; do
             progbin="$(file $c | sed "s/.*execfn: '\([^']*\)'.*/\1/")"
             echo bt | $GDB/bin/gdb -q $progbin $c || true
           done
-      # has not been used in a long while, would need to be adapted to new
-      # shared libs
-      #- name: Upload coredumps
-      #  uses: actions/upload-artifact@v3
-      #  if: ${{ failure() && matrix.os == 'ubuntu-latest' }}
-      #  with:
-      #    name: coredumps-${{ matrix.name }}
-      #    path: |
-      #      ./coredumps
-      #      ./build/stage0/bin/lean
-      #      ./build/stage0/lib/lean/libleanshared.so
-      #      ./build/stage1/bin/lean
-      #      ./build/stage1/lib/lean/libleanshared.so
-      #      ./build/stage2/bin/lean
-      #      ./build/stage2/lib/lean/libleanshared.so
+      - name: Upload coredumps
+        uses: actions/upload-artifact@v3
+        if: ${{ failure() }} && matrix.os == 'ubuntu-latest'
+        with:
+          name: coredumps-${{ matrix.name }}
+          path: |
+            ./coredumps
+            ./build/stage0/bin/lean
+            ./build/stage0/lib/lean/libleanshared.so
+            ./build/stage1/bin/lean
+            ./build/stage1/lib/lean/libleanshared.so
+            ./build/stage2/bin/lean
+            ./build/stage2/lib/lean/libleanshared.so
 
-  # 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
-    if: ${{ always() }}
-    steps:
-    - if: contains(needs.*.result, 'failure') ||  contains(needs.*.result, 'cancelled')
-      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/')
     runs-on: ubuntu-latest
@@ -473,11 +283,9 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_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
@@ -493,16 +301,15 @@ jobs:
         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@v1
         with:
@@ -510,7 +317,7 @@ jobs:
           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 }}

.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 . -type d \( -path "./tests" -o -path "./doc" -o -path "./src/lake/examples" -o -path "./src/lake/tests" -o -path "./build" -o -path "./nix" \) -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/labels-from-comments.yml

@@ -1,43 +0,0 @@
-# This workflow allows any user to add one of the `awaiting-review`, `awaiting-author`, or `WIP` labels,
-# by commenting on the PR or issue.
-# Other labels from this set are removed automatically at the same time.
-
-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'))
-    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');
-
-          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'] });
-          }

.github/workflows/nix-ci.yml

@@ -6,7 +6,8 @@ on:
     tags:
       - '*'
   pull_request:
-  merge_group:
+    branches:
+      - master
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
@@ -17,7 +18,7 @@ jobs:
     runs-on: ${{ matrix.os }}
     defaults:
       run:
-        shell: nix run .#ciShell -- bash -euxo pipefail {0}
+        shell: nix -v --experimental-features "nix-command flakes" run .#ciShell -- bash -euxo pipefail {0}
     strategy:
       matrix:
         include:
@@ -29,13 +30,18 @@ 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@v3
+      - name: Install Nix
+        uses: cachix/install-nix-action@v18
         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 }}
+          # https://github.com/NixOS/nix/issues/6572
+          install_url: https://releases.nixos.org/nix/nix-2.7.0/install
+          extra_nix_config: |
+            extra-sandbox-paths = /nix/var/cache/ccache
+            substituters = file://${{ github.workspace }}/nix-store-cache-copy?priority=10&trusted=true https://cache.nixos.org
       - name: Set Up Nix Cache
         uses: actions/cache@v3
         with:
@@ -49,13 +55,8 @@ jobs:
         run: |
           # Nix seems to mutate the cache, so make a copy
           cp -r nix-store-cache nix-store-cache-copy || true
-      - 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 -euxo pipefail {0}
         run: |
           sudo mkdir -m0770 -p /nix/var/cache/ccache
           sudo chown -R $USER /nix/var/cache/ccache
@@ -68,9 +69,16 @@ jobs:
           restore-keys: |
             ${{ matrix.name }}-nix-ccache
       - name: Further Set Up CCache Cache
+        shell: bash -euxo pipefail {0}
         run: |
           sudo chown -R root:nixbld /nix/var/cache
           sudo chmod -R 770 /nix/var/cache
+      - name: Install Cachix
+        uses: cachix/cachix-action@v12
+        with:
+          name: lean4
+          authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
+          skipPush: true  # we push specific outputs only
       - name: Build
         run: |
           nix build $NIX_BUILD_ARGS .#cacheRoots -o push-build
@@ -81,44 +89,21 @@ jobs:
         run: |
           nix build $NIX_BUILD_ARGS --update-input lean --no-write-lock-file ./doc#{lean-mdbook,leanInk,alectryon,test,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'
-      - name: Check manual for broken links
-        id: lychee
-        uses: lycheeverse/lychee-action@v1.9.0
-        with:
-          fail: false  # report errors but do not block CI on temporary failures
-          # gmplib.org consistently times out from GH actions
-          # the GitHub token is to avoid rate limiting
-          args: --base './dist' --no-progress --github-token ${{ secrets.GITHUB_TOKEN }} --exclude 'gmplib.org' './dist/**/*.html'
+      - name: Push to Cachix
+        run: |
+          [ -z "${{ secrets.CACHIX_AUTH_TOKEN }}" ] || cachix push -j4 lean4 ./push-* || true
       - 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@v2.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"
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: ./result
+          destination_dir: ./doc
+        if: matrix.name == 'Nix Linux' && github.ref == 'refs/heads/master' && github.event_name == 'push'
       - name: Fixup CCache Cache
         run: |
           sudo chown -R $USER /nix/var/cache

.github/workflows/pr-release.yml

@@ -1,339 +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@v2 # 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@v1
-        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@v6
-        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@v1.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"
-
-            MATHLIB_REMOTE_TAGS="$(git ls-remote https://github.com/leanprover-community/mathlib4.git nightly-testing-"$MOST_RECENT_NIGHTLY")"
-
-            if [[ -n "$MATHLIB_REMOTE_TAGS" ]]; then
-              echo "... and Mathlib has a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              MESSAGE=""
-            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
-
-            STD_REMOTE_TAGS="$(git ls-remote https://github.com/leanprover/std4.git nightly-testing-"$MOST_RECENT_NIGHTLY")"
-
-            if [[ -n "$STD_REMOTE_TAGS" ]]; then
-              echo "... and Std has a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              MESSAGE=""
-            else
-              echo "... but Std does not yet have a 'nightly-testing-$MOST_RECENT_NIGHTLY' tag."
-              MESSAGE="- ❗ Std 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\`, Std 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
-
-            MESSAGE="- ❗ Std/Mathlib CI will not be attempted unless your PR branches off the \`nightly-with-mathlib\` branch. Try \`git rebase $MERGE_BASE_SHA --onto $NIGHTLY_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 -L -s -H "Authorization: token ${{ secrets.MATHLIB4_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-mathlib4-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_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_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_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@v6
-        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 Std branch using this toolchain.
-      # Std 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 Std fails.
-      - name: Cleanup workspace
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        run: |
-          sudo rm -rf ./*
-
-      # Checkout the Std repository with all branches
-      - name: Checkout Std repository
-        if: steps.workflow-info.outputs.pullRequestNumber != '' && steps.ready.outputs.mathlib_ready == 'true'
-        uses: actions/checkout@v3
-        with:
-          repository: leanprover/std4
-          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_std_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 Std. 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 Std `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@v3
-        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: 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 std from git \"https:\/\/github.com\/leanprover\/std4\" @ \".\+\"/require std from git \"https:\/\/github.com\/leanprover\/std4\" @ \"nightly-testing-${MOST_RECENT_NIGHTLY}\"/" lakefile.lean
-            git add lakefile.lean
-            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 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
-            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@v6
+        with:
+          github-token: ${{ secrets.GITHUB_TOKEN }}
+          script: |
+            const { data: commits } = await github.rest.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.rest.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/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@v8
-        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@v3
-      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@v3
-      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,10 +2,7 @@
 \#*
 .#*
 *.lock
-.lake
-lake-manifest.json
 build
-!/src/lake/Lake/Build
 GPATH
 GRTAGS
 GSYMS
@@ -28,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

.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,17 +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()
-
 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
@@ -46,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
@@ -55,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
@@ -65,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

CODEOWNERS

@@ -1,22 +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/ @Kha @semorrison
-/RELEASES.md @semorrison
-/src/Init/IO.lean @joehendrix
-/src/kernel/ @leodemoura
-/src/lake/ @tydeu
-/src/Lean/Compiler/ @leodemoura
-/src/Lean/Data/Lsp/ @mhuisi
-/src/Lean/Elab/Deriving/ @semorrison
-/src/Lean/Elab/Tactic/ @semorrison
-/src/Lean/Meta/Tactic/ @leodemoura
-/src/Lean/Parser/ @Kha
-/src/Lean/PrettyPrinter/ @Kha
-/src/Lean/PrettyPrinter/Delaborator/ @kmill
-/src/Lean/Server/ @mhuisi
-/src/Lean/Widget/ @Vtec234
-/src/runtime/io.cpp @joehendrix

CONTRIBUTING.md

@@ -1,79 +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:
-----
-
-**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).

README.md

@@ -1,20 +1,22 @@
-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/)
+- [Quickstart](https://github.com/leanprover/lean4/blob/master/doc/quickstart.md)
+- [Walkthrough installation video](https://www.youtube.com/watch?v=yZo6k48L0VY)
+- [Quick tour video](https://youtu.be/zyXtbb_eYbY)
+- [Homepage](https://leanprover.github.io)
+- [Theorem Proving Tutorial](https://leanprover.github.io/theorem_proving_in_lean4/)
+- [Functional Programming in Lean](https://leanprover.github.io/functional_programming_in_lean/) **first chapter is available!**
+- [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)
+- [Examples](https://leanprover.github.io/lean4/doc/examples.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 +24,4 @@ Please read our [Contribution Guidelines](CONTRIBUTING.md) first.
 
 # Building from Source
 
-See [Building Lean](https://lean-lang.org/lean4/doc/make/index.html).
+See [Building Lean](https://leanprover.github.io/lean4/doc/make/index.html).

RELEASES.md

@@ -1,595 +1,15 @@
-# Lean 4 releases
-
-We intend to provide regular "minor version" releases of the Lean language at approximately monthly intervals.
-There is not yet a strong guarantee of backwards compatibility between versions,
-only an expectation that breaking changes will be documented in this file.
-
-This file contains work-in-progress notes for the upcoming release, as well as previous stable releases.
-Please check the [releases](https://github.com/leanprover/lean4/releases) page for the current status
-of each version.
-
-v4.7.0 (development in progress)
+Unreleased
 ---------
 
-* When the `pp.proofs` is false, now omitted proofs use `⋯` rather than `_`,
-  which gives a more helpful error message when copied from the Infoview.
-  The `pp.proofs.threshold` option lets small proofs always be pretty printed.
-  [#3241](https://github.com/leanprover/lean4/pull/3241).
-
-* `pp.proofs.withType` is now set to false by default to reduce noise in the info view.
-
-* New `simp` (and `dsimp`) configuration option: `zetaDelta`. It is `false` by default.
-  The `zeta` option is still `true` by default, but their meaning has changed.
-  - When `zeta := true`, `simp` and `dsimp` reduce terms of the form
-    `let x := val; e[x]` into `e[val]`.
-  - When `zetaDelta := true`, `simp` and `dsimp` will expand let-variables in
-    the context. For example, suppose the context contains `x := val`. Then,
-    any occurrence of `x` is replaced with `val`.
-
-  See issue [#2682](https://github.com/leanprover/lean4/pull/2682) for additional details. Here are some examples:
-  ```
-  example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
-    intro x
-    simp
-    /-
-    New goal:
-    h : z = 9; x := 5 |- x + 4 = z
-    -/
-    rw [h]
-
-  example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
-    intro x
-    -- Using both `zeta` and `zetaDelta`.
-    simp (config := { zetaDelta := true })
-    /-
-    New goal:
-    h : z = 9; x := 5 |- 9 = z
-    -/
-    rw [h]
-
-  example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
-    intro x
-    simp [x] -- asks `simp` to unfold `x`
-    /-
-    New goal:
-    h : z = 9; x := 5 |- 9 = z
-    -/
-    rw [h]
-
-  example (h : z = 9) : let x := 5; let y := 4; x + y = z := by
-    intro x
-    simp (config := { zetaDelta := true, zeta := false })
-    /-
-    New goal:
-    h : z = 9; x := 5 |- let y := 4; 5 + y = z
-    -/
-    rw [h]
-  ```
-
-* When adding new local theorems to `simp`, the system assumes that the function application arguments
-  have been annotated with `no_index`. This modification, which addresses issue [#2670](https://github.com/leanprover/lean4/issues/2670),
-  restores the Lean 3 behavior that users expect. With this modification, the following examples are now operational:
-  ```
-  example {α β : Type} {f : α × β → β → β} (h : ∀ p : α × β, f p p.2 = p.2)
-    (a : α) (b : β) : f (a, b) b = b := by
-    simp [h]
-
-  example {α β : Type} {f : α × β → β → β}
-    (a : α) (b : β) (h : f (a,b) (a,b).2 = (a,b).2) : f (a, b) b = b := by
-    simp [h]
-  ```
-  In both cases, `h` is applicable because `simp` does not index f-arguments anymore when adding `h` to the `simp`-set.
-  It's important to note, however, that global theorems continue to be indexed in the usual manner.
-
-* Improved the error messages produced by the `decide` tactic. [#3422](https://github.com/leanprover/lean4/pull/3422)
-
-Breaking changes:
-* `Lean.withTraceNode` and variants got a stronger `MonadAlwaysExcept` assumption to
-  fix trace trees not being built on elaboration runtime exceptions. Instances for most elaboration
-  monads built on `EIO Exception` should be synthesized automatically.
-
-v4.6.0
----------
-
-* Add custom simplification procedures (aka `simproc`s) to `simp`. Simprocs can be triggered by the simplifier on a specified term-pattern. Here is an small example:
-```lean
-import Lean.Meta.Tactic.Simp.BuiltinSimprocs.Nat
-
-def foo (x : Nat) : Nat :=
-  x + 10
-
-/--
-The `simproc` `reduceFoo` is invoked on terms that match the pattern `foo _`.
--/
-simproc reduceFoo (foo _) :=
-  /- A term of type `Expr → SimpM Step -/
-  fun e => do
-    /-
-    The `Step` type has three constructors: `.done`, `.visit`, `.continue`.
-    * The constructor `.done` instructs `simp` that the result does
-      not need to be simplied further.
-    * The constructor `.visit` instructs `simp` to visit the resulting expression.
-    * The constructor `.continue` instructs `simp` to try other simplification procedures.
-
-    All three constructors take a `Result`. The `.continue` contructor may also take `none`.
-    `Result` has two fields `expr` (the new expression), and `proof?` (an optional proof).
-     If the new expression is definitionally equal to the input one, then `proof?` can be omitted or set to `none`.
-    -/
-    /- `simp` uses matching modulo reducibility. So, we ensure the term is a `foo`-application. -/
-    unless e.isAppOfArity ``foo 1 do
-      return .continue
-    /- `Nat.fromExpr?` tries to convert an expression into a `Nat` value -/
-    let some n ← Nat.fromExpr? e.appArg!
-      | return .continue
-    return .done { expr := Lean.mkNatLit (n+10) }
-```
-We disable simprocs support by using the command `set_option simprocs false`. This command is particularly useful when porting files to v4.6.0.
-Simprocs can be scoped, manually added to `simp` commands, and suppressed using `-`. They are also supported by `simp?`. `simp only` does not execute any `simproc`. Here are some examples for the `simproc` defined above.
-```lean
-example : x + foo 2 = 12 + x := by
-  set_option simprocs false in
-    /- This `simp` command does not make progress since `simproc`s are disabled. -/
-    fail_if_success simp
-  simp_arith
-
-example : x + foo 2 = 12 + x := by
-  /- `simp only` must not use the default simproc set. -/
-  fail_if_success simp only
-  simp_arith
-
-example : x + foo 2 = 12 + x := by
-  /-
-  `simp only` does not use the default simproc set,
-  but we can provide simprocs as arguments. -/
-  simp only [reduceFoo]
-  simp_arith
-
-example : x + foo 2 = 12 + x := by
-  /- We can use `-` to disable `simproc`s. -/
-  fail_if_success simp [-reduceFoo]
-  simp_arith
-```
-The command `register_simp_attr <id>` now creates a `simp` **and** a `simproc` set with the name `<id>`. The following command instructs Lean to insert the `reduceFoo` simplification procedure into the set `my_simp`. If no set is specified, Lean uses the default `simp` set.
-```lean
-simproc [my_simp] reduceFoo (foo _) := ...
-```
-
-* The syntax of the `termination_by` and `decreasing_by` termination hints is overhauled:
-
-  * They are now placed directly after the function they apply to, instead of
-    after the whole `mutual` block.
-  * Therefore, the function name no longer has to be mentioned in the hint.
-  * If the function has a `where` clause, the `termination_by` and
-    `decreasing_by` for that function come before the `where`. The
-    functions in the `where` clause can have their own termination hints, each
-    following the corresponding definition.
-  * The `termination_by` clause can only bind “extra parameters”, that are not
-    already bound by the function header, but are bound in a lambda (`:= fun x
-    y z =>`) or in patterns (`| x, n + 1 => …`). These extra parameters used to
-    be understood as a suffix of the function parameters; now it is a prefix.
-
-  Migration guide: In simple cases just remove the function name, and any
-  variables already bound at the header.
-  ```diff
-   def foo : Nat → Nat → Nat := …
-  -termination_by foo a b => a - b
-  +termination_by a b => a - b
-  ```
-  or
-  ```diff
-   def foo : Nat → Nat → Nat := …
-  -termination_by _ a b => a - b
-  +termination_by a b => a - b
-  ```
-
-  If the parameters are bound in the function header (before the `:`), remove them as well:
-  ```diff
-   def foo (a b : Nat) : Nat := …
-  -termination_by foo a b => a - b
-  +termination_by a - b
-  ```
-
-  Else, if there are multiple extra parameters, make sure to refer to the right
-  ones; the bound variables are interpreted from left to right, no longer from
-  right to left:
-  ```diff
-   def foo : Nat → Nat → Nat → Nat
-     | a, b, c => …
-  -termination_by foo b c => b
-  +termination_by a b => b
-  ```
-
-  In the case of a `mutual` block, place the termination arguments (without the
-  function name) next to the function definition:
-  ```diff
-  -mutual
-  -def foo : Nat → Nat → Nat := …
-  -def bar : Nat → Nat := …
-  -end
-  -termination_by
-  -  foo a b => a - b
-  -  bar a => a
-  +mutual
-  +def foo : Nat → Nat → Nat := …
-  +termination_by a b => a - b
-  +def bar : Nat → Nat := …
-  +termination_by a => a
-  +end
-  ```
-
-  Similarly, if you have (mutual) recursion through `where` or `let rec`, the
-  termination hints are now placed directly after the function they apply to:
-  ```diff
-  -def foo (a b : Nat) : Nat := …
-  -  where bar (x : Nat) : Nat := …
-  -termination_by
-  -  foo a b => a - b
-  -  bar x => x
-  +def foo (a b : Nat) : Nat := …
-  +termination_by a - b
-  +  where
-  +    bar (x : Nat) : Nat := …
-  +    termination_by x
-
-  -def foo (a b : Nat) : Nat :=
-  -  let rec bar (x : Nat) :  Nat := …
-  -  …
-  -termination_by
-  -  foo a b => a - b
-  -  bar x => x
-  +def foo (a b : Nat) : Nat :=
-  +  let rec bar (x : Nat) : Nat := …
-  +    termination_by x
-  +  …
-  +termination_by a - b
-  ```
-
-  In cases where a single `decreasing_by` clause applied to multiple mutually
-  recursive functions before, the tactic now has to be duplicated.
-
-* The semantics of `decreasing_by` changed; the tactic is applied to all
-  termination proof goals together, not individually.
-
-  This helps when writing termination proofs interactively, as one can focus
-  each subgoal individually, for example using `·`. Previously, the given
-  tactic script had to work for _all_ goals, and one had to resort to tactic
-  combinators like `first`:
-
-  ```diff
-   def foo (n : Nat) := … foo e1 … foo e2 …
-  -decreasing_by
-  -simp_wf
-  -first | apply something_about_e1; …
-  -      | apply something_about_e2; …
-  +decreasing_by
-  +all_goals simp_wf
-  +· apply something_about_e1; …
-  +· apply something_about_e2; …
-  ```
-
-  To obtain the old behaviour of applying a tactic to each goal individually,
-  use `all_goals`:
-  ```diff
-   def foo (n : Nat) := …
-  -decreasing_by some_tactic
-  +decreasing_by all_goals some_tactic
-  ```
-
-  In the case of mutual recursion each `decreasing_by` now applies to just its
-  function. If some functions in a recursive group do not have their own
-  `decreasing_by`, the default `decreasing_tactic` is used. If the same tactic
-  ought to be applied to multiple functions, the `decreasing_by` clause has to
-  be repeated at each of these functions.
-
-* Modify `InfoTree.context` to facilitate augmenting it with partial contexts while elaborating a command. This breaks backwards compatibility with all downstream projects that traverse the `InfoTree` manually instead of going through the functions in `InfoUtils.lean`, as well as those manually creating and saving `InfoTree`s. See [PR #3159](https://github.com/leanprover/lean4/pull/3159) for how to migrate your code.
-
-* Add language server support for [call hierarchy requests](https://www.youtube.com/watch?v=r5LA7ivUb2c) ([PR #3082](https://github.com/leanprover/lean4/pull/3082)). The change to the .ilean format in this PR means that projects must be fully rebuilt once in order to generate .ilean files with the new format before features like "find references" work correctly again.
-
-* Structure instances with multiple sources (for example `{a, b, c with x := 0}`) now have their fields filled from these sources
-  in strict left-to-right order. Furthermore, the structure instance elaborator now aggressively use sources to fill in subobject
-  fields, which prevents unnecessary eta expansion of the sources,
-  and hence greatly reduces the reliance on costly structure eta reduction. This has a large impact on mathlib,
-  reducing total CPU instructions by 3% and enabling impactful refactors like leanprover-community/mathlib4#8386
-  which reduces the build time by almost 20%.
-  See PR [#2478](https://github.com/leanprover/lean4/pull/2478) and RFC [#2451](https://github.com/leanprover/lean4/issues/2451).
-
-* Add pretty printer settings to omit deeply nested terms (`pp.deepTerms false` and `pp.deepTerms.threshold`) ([PR #3201](https://github.com/leanprover/lean4/pull/3201))
-
-* Add pretty printer options `pp.numeralTypes` and `pp.natLit`.
-  When `pp.numeralTypes` is true, then natural number literals, integer literals, and rational number literals
-  are pretty printed with type ascriptions, such as `(2 : Rat)`, `(-2 : Rat)`, and `(-2 / 3 : Rat)`.
-  When `pp.natLit` is true, then raw natural number literals are pretty printed as `nat_lit 2`.
-  [PR #2933](https://github.com/leanprover/lean4/pull/2933) and [RFC #3021](https://github.com/leanprover/lean4/issues/3021).
-
-Lake updates:
-* improved platform information & control [#3226](https://github.com/leanprover/lean4/pull/3226)
-* `lake update` from unsupported manifest versions [#3149](https://github.com/leanprover/lean4/pull/3149)
-
-Other improvements:
-* make `intro` be aware of `let_fun` [#3115](https://github.com/leanprover/lean4/pull/3115)
-* produce simpler proof terms in `rw` [#3121](https://github.com/leanprover/lean4/pull/3121)
-* fuse nested `mkCongrArg` calls in proofs generated by `simp` [#3203](https://github.com/leanprover/lean4/pull/3203)
-* `induction using` followed by a general term [#3188](https://github.com/leanprover/lean4/pull/3188)
-* allow generalization in `let` [#3060](https://github.com/leanprover/lean4/pull/3060, fixing [#3065](https://github.com/leanprover/lean4/issues/3065)
-* reducing out-of-bounds `swap!` should return `a`, not `default`` [#3197](https://github.com/leanprover/lean4/pull/3197), fixing [#3196](https://github.com/leanprover/lean4/issues/3196)
-* derive `BEq` on structure with `Prop`-fields [#3191](https://github.com/leanprover/lean4/pull/3191), fixing [#3140](https://github.com/leanprover/lean4/issues/3140)
-* refine through more `casesOnApp`/`matcherApp` [#3176](https://github.com/leanprover/lean4/pull/3176), fixing [#3175](https://github.com/leanprover/lean4/pull/3175)
-* do not strip dotted components from lean module names [#2994](https://github.com/leanprover/lean4/pull/2994), fixing [#2999](https://github.com/leanprover/lean4/issues/2999)
-* fix `deriving` only deriving the first declaration for some handlers [#3058](https://github.com/leanprover/lean4/pull/3058), fixing [#3057](https://github.com/leanprover/lean4/issues/3057)
-* do not instantiate metavariables in kabstract/rw for disallowed occurrences [#2539](https://github.com/leanprover/lean4/pull/2539), fixing [#2538](https://github.com/leanprover/lean4/issues/2538)
-* hover info for `cases h : ...` [#3084](https://github.com/leanprover/lean4/pull/3084)
-
-v4.5.0
----------
-
-* Modify the lexical syntax of string literals to have string gaps, which are escape sequences of the form `"\" newline whitespace*`.
-  These have the interpetation of an empty string and allow a string to flow across multiple lines without introducing additional whitespace.
-  The following is equivalent to `"this is a string"`.
-  ```lean
-  "this is \
-     a string"
-  ```
-  [PR #2821](https://github.com/leanprover/lean4/pull/2821) and [RFC #2838](https://github.com/leanprover/lean4/issues/2838).
-
-* Add raw string literal syntax. For example, `r"\n"` is equivalent to `"\\n"`, with no escape processing.
-  To include double quote characters in a raw string one can add sufficiently many `#` characters before and after
-  the bounding `"`s, as in `r#"the "the" is in quotes"#` for `"the \"the\" is in quotes"`.
-  [PR #2929](https://github.com/leanprover/lean4/pull/2929) and [issue #1422](https://github.com/leanprover/lean4/issues/1422).
-
-* The low-level `termination_by'` clause is no longer supported.
-
-  Migration guide: Use `termination_by` instead, e.g.:
-  ```diff
-  -termination_by' measure (fun ⟨i, _⟩ => as.size - i)
-  +termination_by i _ => as.size - i
-  ```
-
-  If the well-founded relation you want to use is not the one that the
-  `WellFoundedRelation` type class would infer for your termination argument,
-  you can use `WellFounded.wrap` from the std libarary to explicitly give one:
-  ```diff
-  -termination_by' ⟨r, hwf⟩
-  +termination_by x => hwf.wrap x
-  ```
-
-* Support snippet edits in LSP `TextEdit`s. See `Lean.Lsp.SnippetString` for more details.
-
-* Deprecations and changes in the widget API.
-  - `Widget.UserWidgetDefinition` is deprecated in favour of `Widget.Module`. The annotation `@[widget]` is deprecated in favour of `@[widget_module]`. To migrate a definition of type `UserWidgetDefinition`, remove the `name` field and replace the type with `Widget.Module`. Removing the `name` results in a title bar no longer being drawn above your panel widget. To add it back, draw it as part of the component using `<details open=true><summary class='mv2 pointer'>{name}</summary>{rest_of_widget}</details>`. See an example migration [here](https://github.com/leanprover/std4/pull/475/files#diff-857376079661a0c28a53b7ff84701afabbdf529836a6944d106c5294f0e68109R43-R83).
-  - The new command `show_panel_widgets` allows displaying always-on and locally-on panel widgets.
-  - `RpcEncodable` widget props can now be stored in the infotree.
-  - See [RFC 2963](https://github.com/leanprover/lean4/issues/2963) for more details and motivation.
-
-* If no usable lexicographic order can be found automatically for a termination proof, explain why.
-  See [feat: GuessLex: if no measure is found, explain why](https://github.com/leanprover/lean4/pull/2960).
-
-* Option to print [inferred termination argument](https://github.com/leanprover/lean4/pull/3012).
-  With `set_option showInferredTerminationBy true` you will get messages like
-  ```
-  Inferred termination argument:
-  termination_by
-  ackermann n m => (sizeOf n, sizeOf m)
-  ```
-  for automatically generated `termination_by` clauses.
-
-* More detailed error messages for [invalid mutual blocks](https://github.com/leanprover/lean4/pull/2949).
-
-* [Multiple](https://github.com/leanprover/lean4/pull/2923) [improvements](https://github.com/leanprover/lean4/pull/2969) to the output of `simp?` and `simp_all?`.
-
-* Tactics with `withLocation *` [no longer fail](https://github.com/leanprover/lean4/pull/2917) if they close the main goal.
-
-* Implementation of a `test_extern` command for writing tests for `@[extern]` and `@[implemented_by]` functions.
-  Usage is
-  ```
-  import Lean.Util.TestExtern
-
-  test_extern Nat.add 17 37
-  ```
-  The head symbol must be the constant with the `@[extern]` or `@[implemented_by]` attribute. The return type must have a `DecidableEq` instance.
-
-Bug fixes for
-[#2853](https://github.com/leanprover/lean4/issues/2853), [#2953](https://github.com/leanprover/lean4/issues/2953), [#2966](https://github.com/leanprover/lean4/issues/2966),
-[#2971](https://github.com/leanprover/lean4/issues/2971), [#2990](https://github.com/leanprover/lean4/issues/2990), [#3094](https://github.com/leanprover/lean4/issues/3094).
-
-Bug fix for [eager evaluation of default value](https://github.com/leanprover/lean4/pull/3043) in `Option.getD`.
-Avoid [panic in `leanPosToLspPos`](https://github.com/leanprover/lean4/pull/3071) when file source is unavailable.
-Improve [short-circuiting behavior](https://github.com/leanprover/lean4/pull/2972) for `List.all` and `List.any`.
-
-Several Lake bug fixes: [#3036](https://github.com/leanprover/lean4/issues/3036), [#3064](https://github.com/leanprover/lean4/issues/3064), [#3069](https://github.com/leanprover/lean4/issues/3069).
-
-v4.4.0
----------
-
-* Lake and the language server now support per-package server options using the `moreServerOptions` config field, as well as options that apply to both the language server and `lean` using the `leanOptions` config field. Setting either of these fields instead of `moreServerArgs` ensures that viewing files from a dependency uses the options for that dependency. Additionally, `moreServerArgs` is being deprecated in favor of the `moreGlobalServerArgs` field. See PR [#2858](https://github.com/leanprover/lean4/pull/2858).
-
-  A Lakefile with the following deprecated package declaration:
-  ```lean
-  def moreServerArgs := #[
-    "-Dpp.unicode.fun=true"
-  ]
-  def moreLeanArgs := moreServerArgs
-
-  package SomePackage where
-    moreServerArgs := moreServerArgs
-    moreLeanArgs := moreLeanArgs
-  ```
-
-  ... can be updated to the following package declaration to use per-package options:
-  ```lean
-  package SomePackage where
-    leanOptions := #[⟨`pp.unicode.fun, true⟩]
-  ```
-* [Rename request handler](https://github.com/leanprover/lean4/pull/2462).
-* [Import auto-completion](https://github.com/leanprover/lean4/pull/2904).
-* [`pp.beta`` to apply beta reduction when pretty printing](https://github.com/leanprover/lean4/pull/2864).
-* [Embed and check githash in .olean](https://github.com/leanprover/lean4/pull/2766).
-* [Guess lexicographic order for well-founded recursion](https://github.com/leanprover/lean4/pull/2874).
-* [Allow trailing comma in tuples, lists, and tactics](https://github.com/leanprover/lean4/pull/2643).
-
-Bug fixes for [#2628](https://github.com/leanprover/lean4/issues/2628), [#2883](https://github.com/leanprover/lean4/issues/2883),
-[#2810](https://github.com/leanprover/lean4/issues/2810), [#2925](https://github.com/leanprover/lean4/issues/2925), and [#2914](https://github.com/leanprover/lean4/issues/2914).
-
-**Lake:**
-
-* `lake init .` and a bare `lake init` and will now use the current directory as the package name. [#2890](https://github.com/leanprover/lean4/pull/2890)
-* `lake new` and `lake init` will now produce errors on invalid package names such as `..`, `foo/bar`, `Init`, `Lean`, `Lake`, and `Main`. See issue [#2637](https://github.com/leanprover/lean4/issues/2637) and PR [#2890](https://github.com/leanprover/lean4/pull/2890).
-* `lean_lib` no longer converts its name to upper camel case (e.g., `lean_lib bar` will include modules named `bar.*` rather than `Bar.*`). See issue [#2567](https://github.com/leanprover/lean4/issues/2567) and PR [#2889](https://github.com/leanprover/lean4/pull/2889).
-* Lean and Lake now properly support non-identifier library names (e.g., `lake new 123-hello` and `import «123Hello»` now work correctly). See issue [#2865](https://github.com/leanprover/lean4/issues/2865) and PR [#2889](https://github.com/leanprover/lean4/pull/2888).
-* Lake now filters the environment extensions loaded from a compiled configuration (`lakefile.olean`) to include only those relevant to Lake's workspace loading process. This resolves segmentation faults caused by environment extension type mismatches (e.g., when defining custom elaborators via `elab` in configurations). See issue [#2632](https://github.com/leanprover/lean4/issues/2632) and PR [#2896](https://github.com/leanprover/lean4/pull/2896).
-* Cloud releases will now properly be re-unpacked if the build directory is removed. See PR [#2928](https://github.com/leanprover/lean4/pull/2928).
-* Lake's `math` template has been simplified. See PR [#2930](https://github.com/leanprover/lean4/pull/2930).
-* `lake exe <target>` now parses `target` like a build target (as the help text states it should) rather than as a basic name. For example, `lake exe @mathlib/runLinter` should now work. See PR [#2932](https://github.com/leanprover/lean4/pull/2932).
-* `lake new foo.bar [std]` now generates executables named `foo-bar` and `lake new foo.bar exe` properly creates `foo/bar.lean`. See PR [#2932](https://github.com/leanprover/lean4/pull/2932).
-* Later packages and libraries in the dependency tree are now preferred over earlier ones. That is, the later ones "shadow" the earlier ones. Such an ordering is more consistent with how declarations generally work in programming languages. This will break any package that relied on the previous ordering. See issue [#2548](https://github.com/leanprover/lean4/issues/2548) and PR [#2937](https://github.com/leanprover/lean4/pull/2937).
-* Executable roots are no longer mistakenly treated as importable. They will no longer be picked up by `findModule?`. See PR [#2937](https://github.com/leanprover/lean4/pull/2937).
-
-v4.3.0
----------
-
-* `simp [f]` does not unfold partial applications of `f` anymore. See issue [#2042](https://github.com/leanprover/lean4/issues/2042).
-  To fix proofs affected by this change, use `unfold f` or `simp (config := { unfoldPartialApp := true }) [f]`.
-* By default, `simp` will no longer try to use Decidable instances to rewrite terms. In particular, not all decidable goals will be closed by `simp`, and the `decide` tactic may be useful in such cases. The `decide` simp configuration option can be used to locally restore the old `simp` behavior, as in `simp (config := {decide := true})`; this includes using Decidable instances to verify side goals such as numeric inequalities.
-
-* Many bug fixes:
-  * [Add left/right actions to term tree coercion elaborator and make `^`` a right action](https://github.com/leanprover/lean4/pull/2778)
-  * [Fix for #2775, don't catch max recursion depth errors](https://github.com/leanprover/lean4/pull/2790)
-  * [Reduction of `Decidable` instances very slow when using `cases` tactic](https://github.com/leanprover/lean4/issues/2552)
-  * [`simp` not rewriting in binder](https://github.com/leanprover/lean4/issues/1926)
-  * [`simp` unfolding `let` even with `zeta := false` option](https://github.com/leanprover/lean4/issues/2669)
-  * [`simp` (with beta/zeta disabled) and discrimination trees](https://github.com/leanprover/lean4/issues/2281)
-  * [unknown free variable introduced by `rw ... at h`](https://github.com/leanprover/lean4/issues/2711)
-  * [`dsimp` doesn't use `rfl` theorems which consist of an unapplied constant](https://github.com/leanprover/lean4/issues/2685)
-  * [`dsimp` does not close reflexive equality goals if they are wrapped in metadata](https://github.com/leanprover/lean4/issues/2514)
-  * [`rw [h]` uses `h` from the environment in preference to `h` from the local context](https://github.com/leanprover/lean4/issues/2729)
-  * [missing `withAssignableSyntheticOpaque` for `assumption` tactic](https://github.com/leanprover/lean4/issues/2361)
-  * [ignoring default value for field warning](https://github.com/leanprover/lean4/issues/2178)
-* [Cancel outstanding tasks on document edit in the language server](https://github.com/leanprover/lean4/pull/2648).
-* [Remove unnecessary `%` operations in `Fin.mod` and `Fin.div`](https://github.com/leanprover/lean4/pull/2688)
-* [Avoid `DecidableEq` in `Array.mem`](https://github.com/leanprover/lean4/pull/2774)
-* [Ensure `USize.size` unifies with `?m + 1`](https://github.com/leanprover/lean4/issues/1926)
-* [Improve compatibility with emacs eglot client](https://github.com/leanprover/lean4/pull/2721)
-
-**Lake:**
-
-* [Sensible defaults for `lake new MyProject math`](https://github.com/leanprover/lean4/pull/2770)
-* Changed `postUpdate?` configuration option to a `post_update` declaration. See the `post_update` syntax docstring for more information on the new syntax.
-* [A manifest is automatically created on workspace load if one does not exists.](https://github.com/leanprover/lean4/pull/2680).
-* The `:=` syntax for configuration declarations (i.e., `package`, `lean_lib`, and `lean_exe`) has been deprecated. For example, `package foo := {...}` is deprecated.
-* [support for overriding package URLs via `LAKE_PKG_URL_MAP`](https://github.com/leanprover/lean4/pull/2709)
-* Moved the default build directory (e.g., `build`), default packages directory (e.g., `lake-packages`), and the compiled configuration (e.g., `lakefile.olean`) into a new dedicated directory for Lake outputs, `.lake`. The cloud release build archives are also stored here, fixing [#2713](https://github.com/leanprover/lean4/issues/2713).
-* Update manifest format to version 7 (see [lean4#2801](https://github.com/leanprover/lean4/pull/2801) for details on the changes).
-* Deprecate the `manifestFile` field of a package configuration.
-* There is now a more rigorous check on `lakefile.olean` compatibility (see [#2842](https://github.com/leanprover/lean4/pull/2842) for more details).
-
-v4.2.0
----------
-
-* [isDefEq cache for terms not containing metavariables.](https://github.com/leanprover/lean4/pull/2644).
-* Make [`Environment.mk`](https://github.com/leanprover/lean4/pull/2604) and [`Environment.add`](https://github.com/leanprover/lean4/pull/2642) private, and add [`replay`](https://github.com/leanprover/lean4/pull/2617) as a safer alternative.
-* `IO.Process.output` no longer inherits the standard input of the caller.
-* [Do not inhibit caching](https://github.com/leanprover/lean4/pull/2612) of default-level `match` reduction.
-* [List the valid case tags](https://github.com/leanprover/lean4/pull/2629) when the user writes an invalid one.
-* The derive handler for `DecidableEq` [now handles](https://github.com/leanprover/lean4/pull/2591) mutual inductive types.
-* [Show path of failed import in Lake](https://github.com/leanprover/lean4/pull/2616).
-* [Fix linker warnings on macOS](https://github.com/leanprover/lean4/pull/2598).
-* **Lake:** Add `postUpdate?` package configuration option. Used by a package to specify some code which should be run after a successful `lake update` of the package or one of its downstream dependencies. ([lake#185](https://github.com/leanprover/lake/issues/185))
-* Improvements to Lake startup time ([#2572](https://github.com/leanprover/lean4/pull/2572), [#2573](https://github.com/leanprover/lean4/pull/2573))
-* `refine e` now replaces the main goal with metavariables which were created during elaboration of `e` and no longer captures pre-existing metavariables that occur in `e` ([#2502](https://github.com/leanprover/lean4/pull/2502)).
-  * This is accomplished via changes to `withCollectingNewGoalsFrom`, which also affects `elabTermWithHoles`, `refine'`, `calc` (tactic), and `specialize`. Likewise, all of these now only include newly-created metavariables in their output.
-  * Previously, both newly-created and pre-existing metavariables occurring in `e` were returned inconsistently in different edge cases, causing duplicated goals in the infoview (issue [#2495](https://github.com/leanprover/lean4/issues/2495)), erroneously closed goals (issue [#2434](https://github.com/leanprover/lean4/issues/2434)), and unintuitive behavior due to `refine e` capturing previously-created goals appearing unexpectedly in `e` (no issue; see PR).
-
-v4.1.0
----------
-
-* The error positioning on missing tokens has been [improved](https://github.com/leanprover/lean4/pull/2393). In particular, this should make it easier to spot errors in incomplete tactic proofs.
-
-* After elaborating a configuration file, Lake will now cache the configuration to a `lakefile.olean`. Subsequent runs of Lake will import this OLean instead of elaborating the configuration file. This provides a significant performance improvement (benchmarks indicate that using the OLean cuts Lake's startup time in half), but there are some important details to keep in mind:
-  + Lake will regenerate this OLean after each modification to the `lakefile.lean` or `lean-toolchain`. You can also force a reconfigure by passing the new `--reconfigure` / `-R` option to `lake`.
-  + Lake configuration options (i.e., `-K`) will be fixed at the moment of elaboration. Setting these options when `lake` is using the cached configuration will have no effect. To change options, run `lake` with `-R` / `--reconfigure`.
-  + **The `lakefile.olean` is a local configuration and should not be committed to Git. Therefore, existing Lake packages need to add it to their `.gitignore`.**
-
-* The signature of `Lake.buildO` has changed, `args` has been split into `weakArgs` and `traceArgs`. `traceArgs` are included in the input trace and `weakArgs` are not. See Lake's [FFI example](src/lake/examples/ffi/lib/lakefile.lean) for a demonstration of how to adapt to this change.
-
-* The signatures of `Lean.importModules`, `Lean.Elab.headerToImports`, and `Lean.Elab.parseImports`
-  have [changed](https://github.com/leanprover/lean4/pull/2480) from taking `List Import` to `Array Import`.
-
-* There is now [an `occs` field](https://github.com/leanprover/lean4/pull/2470)
-  in the configuration object for the `rewrite` tactic,
-  allowing control of which occurrences of a pattern should be rewritten.
-  This was previously a separate argument for `Lean.MVarId.rewrite`,
-  and this has been removed in favour of an additional field of `Rewrite.Config`.
-  It was not previously accessible from user tactics.
-
-v4.0.0
----------
-
-* [`Lean.Meta.getConst?` has been renamed](https://github.com/leanprover/lean4/pull/2454).
-  We have renamed `getConst?` to `getUnfoldableConst?` (and `getConstNoEx?` to `getUnfoldableConstNoEx?`).
-  These were not intended to be part of the public API, but downstream projects had been using them
-  (sometimes expecting different behaviour) incorrectly instead of `Lean.getConstInfo`.
-
-* [`dsimp` / `simp` / `simp_all` now fail by default if they make no progress](https://github.com/leanprover/lean4/pull/2336).
-
-  This can be overridden with the `(config := { failIfUnchanged := false })` option.
-  This change was made to ease manual use of `simp` (with complicated goals it can be hard to tell if it was effective)
-  and to allow easier flow control in tactics internally using `simp`.
-  See the [summary discussion](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/simp.20fails.20if.20no.20progress/near/380153295)
-  on zulip for more details.
-
-* [`simp_all` now preserves order of hypotheses](https://github.com/leanprover/lean4/pull/2334).
-
-  In order to support the `failIfUnchanged` configuration option for `dsimp` / `simp` / `simp_all`
-  the way `simp_all` replaces hypotheses has changed.
-  In particular it is now more likely to preserve the order of hypotheses.
-  See [`simp_all` reorders hypotheses unnecessarily](https://github.com/leanprover/lean4/pull/2334).
-  (Previously all non-dependent propositional hypotheses were reverted and reintroduced.
-  Now only such hypotheses which were changed, or which come after a changed hypothesis,
-  are reverted and reintroduced.
-  This has the effect of preserving the ordering amongst the non-dependent propositional hypotheses,
-  but now any dependent or non-propositional hypotheses retain their position amongst the unchanged
-  non-dependent propositional hypotheses.)
-  This may affect proofs that use `rename_i`, `case ... =>`, or `next ... =>`.
-
-* [New `have this` implementation](https://github.com/leanprover/lean4/pull/2247).
-
-  `this` is now a regular identifier again that is implicitly introduced by anonymous `have :=` for the remainder of the tactic block. It used to be a keyword that was visible in all scopes and led to unexpected behavior when explicitly used as a binder name.
-
-* [Show typeclass and tactic names in profile output](https://github.com/leanprover/lean4/pull/2170).
-
-* [Make `calc` require the sequence of relation/proof-s to have the same indentation](https://github.com/leanprover/lean4/pull/1844),
-  and [add `calc` alternative syntax allowing underscores `_` in the first relation](https://github.com/leanprover/lean4/pull/1844).
-
-  The flexible indentation in `calc` was often used to align the relation symbols:
-  ```lean
-  example (x y : Nat) : (x + y) * (x + y) = x * x + y * x + x * y + y * y :=
-    calc
-        (x + y) * (x + y) = (x + y) * x + (x + y) * y       := by rw [Nat.mul_add]
-                        -- improper indentation
-                        _ = x * x + y * x + (x + y) * y     := by rw [Nat.add_mul]
-                        _ = x * x + y * x + (x * y + y * y) := by rw [Nat.add_mul]
-                        _ = x * x + y * x + x * y + y * y   := by rw [←Nat.add_assoc]
-  ```
-
-  This is no longer legal.  The new syntax puts the first term right after the `calc` and each step has the same indentation:
-  ```lean
-  example (x y : Nat) : (x + y) * (x + y) = x * x + y * x + x * y + y * y :=
-    calc (x + y) * (x + y)
-      _ = (x + y) * x + (x + y) * y       := by rw [Nat.mul_add]
-      _ = x * x + y * x + (x + y) * y     := by rw [Nat.add_mul]
-      _ = x * x + y * x + (x * y + y * y) := by rw [Nat.add_mul]
-      _ = x * x + y * x + x * y + y * y   := by rw [←Nat.add_assoc]
-  ```
-
-
-* Update Lake to latest prerelease.
-
 * [Make go-to-definition on a typeclass projection application go to the instance(s)](https://github.com/leanprover/lean4/pull/1767).
 
 * [Include timings in trace messages when `profiler` is true](https://github.com/leanprover/lean4/pull/1995).
 
 * [Pretty-print signatures in hover and `#check <ident>`](https://github.com/leanprover/lean4/pull/1943).
 
-* [Introduce parser memoization to avoid exponential behavior](https://github.com/leanprover/lean4/pull/1799).
+* [Update Lake to latest prerelease](https://github.com/leanprover/lean4/pull/1879).
+
+* [Introduce parser memoization to avoid exponentional behavior](https://github.com/leanprover/lean4/pull/1799).
 
 * [feat: allow `doSeq` in `let x <- e | seq`](https://github.com/leanprover/lean4/pull/1809).
 
@@ -629,7 +49,7 @@ v4.0.0
 
 * New [code generator](https://github.com/leanprover/lean4/tree/master/src/Lean/Compiler/LCNF) project has started.
 
-* Remove description argument from `register_simp_attr`. [PR #1566](https://github.com/leanprover/lean4/pull/1566).
+* Remove description argument frome `register_simp_attr`. [PR #1566](https://github.com/leanprover/lean4/pull/1566).
 
 * [Additional concurrency primitives](https://github.com/leanprover/lean4/pull/1555).
 
@@ -1149,7 +569,7 @@ v4.0.0-m5 (07 August 2022)
   `Foo : {Foo : Type u} → List Foo → Type`.
 
 
-* Fix syntax highlighting for recursive declarations. Example
+* Fix syntax hightlighting for recursive declarations. Example
   ```lean
   inductive List (α : Type u) where
     | nil : List α  -- `List` is not highlighted as a variable anymore
@@ -1202,7 +622,7 @@ v4.0.0-m5 (07 August 2022)
     ...
   ```
 
-* Remove support for `{}` annotation from inductive datatype constructors. This annotation was barely used, and we can control the binder information for parameter bindings using the new inductive family indices to parameter promotion. Example: the following declaration using `{}`
+* Remove support for `{}` annotation from inductive datatype contructors. This annotation was barely used, and we can control the binder information for parameter bindings using the new inductive family indices to parameter promotion. Example: the following declaration using `{}`
   ```lean
   inductive LE' (n : Nat) : Nat → Prop where
     | refl {} : LE' n n -- Want `n` to be explicit
@@ -1367,7 +787,7 @@ v4.0.0-m4 (23 March 2022)
 
   initialize my_ext : SimpExtension ← registerSimpAttr `my_simp "my own simp attribute"
   ```
-  If you don't need to access `my_ext`, you can also use the macro
+  If you don't neet to acces `my_ext`, you can also use the macro
   ```lean
   import Lean
 
@@ -1458,7 +878,7 @@ For example, given `f : Nat → Nat` and `g : Nat → Nat`, `f.comp g` is now no
 
 * Various improvements to go-to-definition & find-all-references accuracy.
 
-* Auto generated congruence lemmas with support for casts on proofs and `Decidable` instances (see [wishlist](https://github.com/leanprover/lean4/issues/988)).
+* Auto generated congruence lemmas with support for casts on proofs and `Decidable` instances (see [whishlist](https://github.com/leanprover/lean4/issues/988)).
 
 * Rename option `autoBoundImplicitLocal` => `autoImplicit`.
 

doc/SUMMARY.md

@@ -85,6 +85,7 @@
   - [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)
 - [Bootstrapping](./dev/bootstrap.md)
 - [Testing](./dev/testing.md)
 - [Debugging](./dev/debugging.md)

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/declarations.md

@@ -60,7 +60,7 @@ a b c : Nat
 
 Here ``a b c : Nat`` indicates the local context, and the second ``Nat`` indicates the expected type of the result.
 
-A *context* is sometimes called a *telescope*, but the latter is used more generally to include a sequence of declarations occurring relative to a given context. For example, relative to the context ``(a₁ : α₁) (a₂ : α₂) ... (aₙ : αₙ)``, the types ``βᵢ`` in a telescope ``(b₁ : β₁) (b₂ : β₂) ... (bₙ : βₙ)`` can refer to ``a₁, ..., aₙ``. Thus a context can be viewed as a telescope relative to the empty context.
+A *context* is sometimes called a *telescope*, but the latter is used more generally to include a sequence of declarations occuring relative to a given context. For example, relative to the context ``(a₁ : α₁) (a₂ : α₂) ... (aₙ : αₙ)``, the types ``βᵢ`` in a telescope ``(b₁ : β₁) (b₂ : β₂) ... (bₙ : βₙ)`` can refer to ``a₁, ..., aₙ``. Thus a context can be viewed as a telescope relative to the empty context.
 
 Telescopes are often used to describe a list of arguments, or parameters, to a declaration. In such cases, it is often notationally convenient to let ``(a : α)`` stand for a telescope rather than just a single argument. In general, the annotations described in [Implicit Arguments](expressions.md#implicit_arguments) can be used to mark arguments as implicit.
 
@@ -76,7 +76,7 @@ Lean provides ways of adding new objects to the environment. The following provi
 * ``theorem c : p := v`` : similar to ``def``, but intended to be used when ``p`` is a proposition.
 * ``opaque c : α (:= v)?`` : declares a opaque constant named ``c`` of type ``α``, the optional value `v` is must have type `α`
   and can be viewed as a certificate that ``α`` is not an empty type. If the value is not provided, Lean tries to find one
-  using a procedure based on type class resolution. The value `v` is hidden from the type checker. You can assume that
+  using a proceture based on type class resolution. The value `v` is hidden from the type checker. You can assume that
   Lean "forgets" `v` after type checking this kind of declaration.
 
 It is sometimes useful to be able to simulate a definition or theorem without naming it or adding it to the environment.
@@ -483,43 +483,7 @@ def baz : Char → Nat
 | _   => 3
 ```
 
-The case where patterns are matched against an argument whose type is an inductive family is known as *dependent pattern matching*. This is more complicated, because the type of the function being defined can impose constraints on the patterns that are matched. In this case, the equation compiler will detect inconsistent cases and rule them out.
-
-```lean
-universe u
-
-inductive Vector (α : Type u) : Nat → Type u
-  | nil  : Vector α 0
-  | cons : α → Vector α n → Vector α (n+1)
-
-namespace Vector
-
-def head : Vector α (n+1) → α
-  | cons h t => h
-
-def tail : Vector α (n+1) → Vector α n
-  | cons h t => t
-
-def map (f : α → β → γ) : Vector α n → Vector β n → Vector γ n
-  | nil, nil => nil
-  | cons a va, cons b vb => cons (f a b) (map f va vb)
-
-end Vector
-```
-
-.. _recursive_functions:
-
-Recursive functions
-===================
-
-Lean must ensure that a recursive function terminates, for which there are two strategies: _structural recursion_, in which all recursive calls are made on smaller parts of the input data, and _well-founded recursion_, in which recursive calls are justified by showing that arguments to recursive calls are smaller according to some other measure.
-
-Structural recursion
---------------------
-
-If the definition of a function contains recursive calls, Lean first tries to interpret the definition as a structural recursion. In order for that to succeed, the recursive arguments must be subterms of the corresponding arguments on the left-hand side.
-
-The function is then defined using a *course of values* recursion, using automatically generated functions ``below`` and ``brec`` in the namespace corresponding to the inductive type of the recursive argument. In this case the defining equations hold definitionally, possibly with additional case splits.
+If any of the terms ``tᵢ`` in the template above contain a recursive call to ``foo``, the equation compiler tries to interpret the definition as a structural recursion. In order for that to succeed, the recursive arguments must be subterms of the corresponding arguments on the left-hand side. The function is then defined using a *course of values* recursion, using automatically generated functions ``below`` and ``brec`` in the namespace corresponding to the inductive type of the recursive argument. In this case the defining equations hold definitionally, possibly with additional case splits.
 
 ```lean
 namespace Hide
@@ -540,12 +504,7 @@ example : append [(1 : Nat), 2, 3] [4, 5] = [1, 2, 3, 4, 5] => rfl
 end Hide
 ```
 
-Well-founded recursion
----------------------
-
-If structural recursion fails, the equation compiler falls back on well-founded recursion. It tries to infer an instance of ``SizeOf`` for the type of each argument, and then tries to find a permutation of the arguments such that each recursive call is decreasing under the lexicographic order with respect to ``sizeOf`` measures.  Lean uses information in the local context, so you can often provide the relevant proof manually using ``have`` in the body of the definition.
-
-In the case of well-founded recursion, the equation used to declare the function holds only propositionally, but not definitionally, and can be accessed using ``unfold``, ``simp`` and ``rewrite`` with the function name (for example ``unfold foo`` or ``simp [foo]``, where ``foo`` is the function defined with well-founded recursion).
+If structural recursion fails, the equation compiler falls back on well-founded recursion. It tries to infer an instance of ``SizeOf`` for the type of each argument, and then show that each recursive call is decreasing under the lexicographic order of the arguments with respect to ``sizeOf`` measure. If it fails, the error message provides information as to the goal that Lean tried to prove. Lean uses information in the local context, so you can often provide the relevant proof manually using ``have`` in the body of the definition. In this case of well-founded recursion, the defining equations hold only propositionally, and can be accessed using ``simp`` and ``rewrite`` with the name ``foo``.
 
 ```lean
 namespace Hide
@@ -569,53 +528,9 @@ by rw [div]; rfl
 end Hide
 ```
 
-If Lean cannot find a permutation of the arguments for which all recursive calls are decreasing, it will print a table that contains, for every recursive call, which arguments Lean could prove to be decreasing. For example, a function with three recursive calls and four parameters might cause the following message to be printed
-
-```
-example.lean:37:0-43:31: error: Could not find a decreasing measure.
-The arguments relate at each recursive call as follows:
-(<, ≤, =: relation proved, ? all proofs failed, _: no proof attempted)
-           x1 x2 x3 x4
-1) 39:6-27  =  =  _  =
-2) 40:6-25  =  ?  _  <
-3) 41:6-25  <  _  _  _
-Please use `termination_by` to specify a decreasing measure.
-```
-
-This table should be read as follows:
-
- * In the first recursive call, in line 39, arguments 1, 2 and 4 are equal to the function's parameters.
- * The second recursive call, in line 40, has an equal first argument, a smaller fourth argument, and nothing could be inferred for the second argument.
- * The third recursive call, in line 41, has a decreasing first argument.
- * No other proofs were attempted, either because the parameter has a type without a non-trivial ``WellFounded`` instance (parameter 3), or because it is already clear that no decreasing measure can be found.
-
-
-Lean will print the termination argument it found if ``set_option showInferredTerminationBy true`` is set.
-
-If Lean does not find the termination argument, or if you want to be explicit, you can append a `termination_by` clause to the function definition, after the function's body, but before the `where` clause if present. It is of the form
-```
-termination_by e
-```
-where ``e`` is an expression that depends on the parameters of the function and should be decreasing at each recursive call. The type of `e` should be an instance of the class ``WellFoundedRelation``, which determines how to compare two values of that type.
-
-If ``f`` has parameters “after the ``:``” (for example when defining functions via patterns using `|`), then these can be brought into scope using the syntax
-```
-termination_by a₁ … aₙ => e
-```
-
-By default, Lean uses the tactic ``decreasing_tactic`` when proving that an argument is decreasing; see its documentation for how to globally extend it. You can also choose to use a different tactic for a given function definition with the clause
-```
-decreasing_by <tac>
-```
-which should come after ``termination_by`, if present.
-
-
 Note that recursive definitions can in general require nested recursions, that is, recursion on different arguments of ``foo`` in the template above. The equation compiler handles this by abstracting later arguments, and recursively defining higher-order functions to meet the specification.
 
-Mutual recursion
-----------------
-
-The equation compiler also allows mutual recursive definitions, with a syntax similar to that of [Mutual and Nested Inductive Definitions](#mutual-and-nested-inductive-definitions). Mutual definitions are always compiled using well-founded recursion, and so once again the defining equations hold only propositionally.
+The equation compiler also allows mutual recursive definitions, with a syntax similar to that of [Mutual and Nested Inductive Definitions](#mutual-and-nested-inductive-definitions). They are compiled using well-founded recursion, and so once again the defining equations hold only propositionally.
 
 ```lean
 mutual
@@ -672,31 +587,29 @@ def num_consts_lst : List Term → Nat
 end
 ```
 
-In a set of mutually recursive function, either all or no functions must have an explicit termination argument (``termination_by``). A change of the default termination tactic (``decreasing_by``) only affects the proofs about the recursive calls of that function, not the other functions in the group.
+The case where patterns are matched against an argument whose type is an inductive family is known as *dependent pattern matching*. This is more complicated, because the type of the function being defined can impose constraints on the patterns that are matched. In this case, the equation compiler will detect inconsistent cases and rule them out.
 
-```
-mutual
-theorem even_of_odd_succ : ∀ n, Odd (n + 1) → Even n
-| _, odd_succ n h => h
-termination_by n h => h
-decreasing_by decreasing_tactic
+```lean
+universe u
 
-theorem odd_of_even_succ : ∀ n, Even (n + 1) → Odd n
-| _, even_succ n h => h
-termination_by n h => h
-end
-```
+inductive Vector (α : Type u) : Nat → Type u
+| nil  : Vector α 0
+| cons : α → Vector α n → Vector α (n+1)
 
-Another way to express mutual recursion is using local function definitions in ``where`` or ``let rec`` clauses: these can be mutually recursive with each other and their containing function:
+namespace Vector
 
-```
-theorem even_of_odd_succ : ∀ n, Odd (n + 1) → Even n
-  | _, odd_succ n h => h
-termination_by n h => h
-  where
-    theorem odd_of_even_succ : ∀ n, Even (n + 1) → Odd n
-      | _, even_succ n h => h
-    termination_by n h => h
+def head {α : Type} : Vector α (n+1) → α
+| cons h t => h
+
+def tail {α : Type} : Vector α (n+1) → Vector α n
+| cons h t => t
+
+def map {α β γ : Type} (f : α → β → γ) :
+  ∀ {n}, Vector α n → Vector β n → Vector γ n
+| 0,   nil,       nil       => nil
+| n+1, cons a va, cons b vb => cons (f a b) (map f va vb)
+
+end Vector
 ```
 
 .. _match_expressions:

doc/dev/bootstrap.md

@@ -65,36 +65,9 @@ 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 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/nomeata/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 preferrable, but should you need
-to do it locally, you can use `make update-stage0` in `build/release`, to
-update `stage0` from `stage1`, `make -C stageN update-stage0` to update from
-another stage, or `nix run .#update-stage0-commit` to update using nix.
-
-Updates to `stage0` should be their own commits in the Git history. So should
-you have to include the stage0 update in your PR (rather than using above
-automation after merging changes), commit your work before running `make
-update-stage0`, commit the updated `stage0` compiler code with the commit
-message:
-```
-chore: update stage0
-```
-and coordinate with the admins to not squash your PR.
+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
 

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/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.
@@ -121,4 +119,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/index.md

@@ -1,6 +1,6 @@
 # Development Workflow
 
-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.
+If you want to make changes to Lean itself, start by [building Lean](../make/index.html) 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).
 
 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).
@@ -30,14 +30,20 @@ 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
@@ -51,32 +57,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,6 +1,6 @@
 # Documentation
 
-The Lean `doc` folder contains the [Lean Manual](https://lean-lang.org/lean4/doc/) and is
+The Lean `doc` folder contains the [Lean Manual](https://leanprover.github.io/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
@@ -83,7 +83,7 @@ Then run the following:
     ```
 
 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/.
+it should look like https://leanprover.github.io/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.

doc/dev/testing.md

@@ -5,6 +5,7 @@ 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 +17,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,9 +24,6 @@ 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
@@ -41,17 +33,17 @@ information is displayed. This option will show all test output.
 
 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 +53,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,33 +70,23 @@ 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
@@ -119,7 +101,7 @@ First, we must install [meld](http://meldmerge.org/). On Ubuntu, we can do it by
 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
+Now, suppose `bad_class.lean` test is broken. We can see the problem by going to `test/lean` directory and
 executing
 
 ```
@@ -132,3 +114,8 @@ 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/examples/bintree.lean

@@ -5,7 +5,7 @@ If the type of keys can be totally ordered -- that is, it supports a well-behave
 then maps can be implemented with binary search trees (BSTs). Insert and lookup operations on BSTs take time
 proportional to the height of the tree. If the tree is balanced, the operations therefore take logarithmic time.
 
-This example is based on a similar example found in the ["Software Foundations"](https://softwarefoundations.cis.upenn.edu/vfa-current/SearchTree.html)
+This example is based on a similar example found in the ["Sofware Foundations"](https://softwarefoundations.cis.upenn.edu/vfa-current/SearchTree.html)
 book (volume 3).
 -/
 
@@ -81,9 +81,9 @@ def Tree.toList (t : Tree β) : List (Nat × β) :=
       |>.toList
 
 /-!
-The implementation of `Tree.toList` is inefficient because of how it uses the `++` operator.
+The implemention of `Tree.toList` is inefficient because of how it uses the `++` operator.
 On a balanced tree its running time is linearithmic, because it does a linear number of
-concatenations at each level of the tree. On an unbalanced tree it's quadratic time.
+concatentations at each level of the tree. On an unbalanced tree it's quadratic time.
 Here's a tail-recursive implementation than runs in linear time, regardless of whether the tree is balanced:
 -/
 def Tree.toListTR (t : Tree β) : List (Nat × β) :=
@@ -114,9 +114,9 @@ concatenating all goals produced by `tac'`. In this theorem, we use it to apply
 
 The `simp` parameters `toListTR.go` and `toList` instruct the simplifier to try to reduce
 and/or apply auto generated equation theorems for these two functions.
-The parameter `*` instructs the simplifier to use any equation in a goal as rewriting rules.
+The parameter `*` intructs the simplifier to use any equation in a goal as rewriting rules.
 In this particular case, `simp` uses the induction hypotheses as rewriting rules.
-Finally, the parameter `List.append_assoc` instructs the simplifier to use the
+Finally, the parameter `List.append_assoc` intructs the simplifier to use the
 `List.append_assoc` theorem as a rewriting rule.
 -/
 theorem Tree.toList_eq_toListTR (t : Tree β)
@@ -186,7 +186,7 @@ local macro "have_eq " lhs:term:max rhs:term:max : tactic =>
 The `by_cases' e` is just the regular `by_cases` followed by `simp` using all
 hypotheses in the current goal as rewriting rules.
 Recall that the `by_cases` tactic creates two goals. One where we have `h : e` and
-another one containing `h : ¬ e`. The simplifier uses the `h` to rewrite `e` to `True`
+another one containing `h : ¬ e`. The simplier uses the `h` to rewrite `e` to `True`
 in the first subgoal, and `e` to `False` in the second. This is particularly
 useful if `e` is the condition of an `if`-statement.
 -/
@@ -282,7 +282,7 @@ theorem BinTree.find_insert_of_ne (b : BinTree β) (h : k ≠ k') (v : β)
   let ⟨t, h⟩ := b; simp
   induction t with simp
   | leaf =>
-    intros
+    split <;> simp <;> split <;> simp
     have_eq k k'
     contradiction
   | node left key value right ihl ihr =>

doc/examples/deBruijn.lean

@@ -152,7 +152,7 @@ We prove all cases but the one for `plus` using `simp [*]`. This tactic instruct
 use hypotheses such as `a = b` as rewriting/simplications rules.
 We use the `split` to break the nested `match` expression in the `plus` case into two cases.
 The local variables `iha` and `ihb` are the induction hypotheses for `a` and `b`.
-The modifier `←` in a term simplifier argument instructs the term simplifier to use the equation as a rewriting rule in
+The modifier `←` in a term simplifier argument instructs the term simplier to use the equation as a rewriting rule in
 the "reverse direction". That is, given `h : a = b`, `← h` instructs the term simplifier to rewrite `b` subterms to `a`.
 -/
 theorem Term.constFold_sound (e : Term ctx ty) : e.constFold.denote env = e.denote env := by

doc/examples/interp.lean

@@ -83,7 +83,7 @@ In practice, this means we use `stop` to refer to the most recently defined vari
 
 A value `Expr.val` carries a concrete representation of an integer.
 
-A lambda `Expr.lam` creates a function. In the scope of a function of type `Ty.fn a ty`, there is a
+A lambda `Expr.lam` creates a function. In the scope of a function ot type `Ty.fn a ty`, there is a
 new local variable of type `a`.
 
 A function application `Expr.app` produces a value of type `ty` given a function from `a` to `ty` and a value of type `a`.
@@ -139,7 +139,7 @@ def add : Expr ctx (Ty.fn Ty.int (Ty.fn Ty.int Ty.int)) :=
 More interestingly, a factorial function fact (e.g. `fun x => if (x == 0) then 1 else (fact (x-1) * x)`), can be written as.
 Note that this is a recursive (non-terminating) definition. For every input value, the interpreter terminates, but the
 definition itself is non-terminating. We use two tricks to make sure Lean accepts it. First, we use the auxiliary constructor
-`Expr.delay` to delay its unfolding. Second, we add the annotation `decreasing_by sorry` which can be viewed as
+`Expr.delay` to delay its unfolding. Second, we add the annotation `decreasing_by sorry` which can be viwed as
 "trust me, this recursive definition makes sense". Recall that `sorry` is an unsound axiom in Lean.
 -/
 

doc/examples/palindromes.lean

@@ -82,7 +82,7 @@ theorem List.palindrome_ind (motive : List α → Prop)
     have ih := palindrome_ind motive h₁ h₂ h₃ (a₂::as').dropLast
     have : [a₁] ++ (a₂::as').dropLast ++ [(a₂::as').last (by simp)] = a₁::a₂::as' := by simp
     this ▸ h₃ _ _ _ ih
-termination_by as.length
+termination_by _ as => as.length
 
 /-!
 We use our new induction principle to prove that if `as.reverse = as`, then `Palindrome as` holds.

doc/examples/phoas.lean

@@ -228,7 +228,7 @@ We prove all cases but the one for `plus` using `simp [*]`. This tactic instruct
 use hypotheses such as `a = b` as rewriting/simplications rules.
 We use the `split` to break the nested `match` expression in the `plus` case into two cases.
 The local variables `iha` and `ihb` are the induction hypotheses for `a` and `b`.
-The modifier `←` in a term simplifier argument instructs the term simplifier to use the equation as a rewriting rule in
+The modifier `←` in a term simplifier argument instructs the term simplier to use the equation as a rewriting rule in
 the "reverse direction. That is, given `h : a = b`, `← h` instructs the term simplifier to rewrite `b` subterms to `a`.
 -/
 theorem constFold_sound (e : Term' Ty.denote ty) : denote (constFold e) = denote e := by

doc/examples/tc.lean

@@ -38,7 +38,7 @@ theorem HasType.det (h₁ : HasType e t₁) (h₂ : HasType e t₂) : t₁ = t
   cases h₁ <;> cases h₂ <;> rfl
 
 /-!
-The inductive type `Maybe p` has two constructors: `found a h` and `unknown`.
+The inductive type `Maybe p` has two contructors: `found a h` and `unknown`.
 The former contains an element `a : α` and a proof that `a` satisfies the predicate `p`.
 The constructor `unknown` is used to encode "failure".
 -/

doc/examples/widgets.lean

@@ -15,8 +15,9 @@ sections of a Lean document. User widgets are rendered in the Lean infoview.
 To try it out, simply type in the following code and place your cursor over the `#widget` command.
 -/
 
-@[widget_module]
-def helloWidget : Widget.Module where
+@[widget]
+def helloWidget : UserWidgetDefinition where
+  name := "Hello"
   javascript := "
     import * as React from 'react';
     export default function(props) {
@@ -24,7 +25,7 @@ def helloWidget : Widget.Module where
       return React.createElement('p', {}, name + '!')
     }"
 
-#widget helloWidget
+#widget helloWidget .null
 
 /-!
 If you want to dive into a full sample right away, check out
@@ -55,11 +56,7 @@ to the React component. In our first invocation of `#widget`, we set it to `.nul
 happens when you type in:
 -/
 
-structure HelloWidgetProps where
-  name? : Option String := none
-  deriving Server.RpcEncodable
-
-#widget helloWidget with { name? := "<your name here>" : HelloWidgetProps }
+#widget helloWidget (Json.mkObj [("name", "<your name here>")])
 
 /-!
 💡 NOTE: The RPC system presented below does not depend on JavaScript. However the primary use case
@@ -114,8 +111,8 @@ def getType (params : GetTypeParams) : RequestM (RequestTask CodeWithInfos) :=
   withWaitFindSnapAtPos params.pos fun snap => do
     runTermElabM snap do
       let name ← resolveGlobalConstNoOverloadCore params.name
-      let c ← try getConstInfo name
-        catch _ => throwThe RequestError ⟨.invalidParams, s!"no constant named '{name}'"⟩
+      let some c ← Meta.getConst? name
+        | throwThe RequestError ⟨.invalidParams, s!"no constant named '{name}'"⟩
       Widget.ppExprTagged c.type
 
 /-!
@@ -135,8 +132,9 @@ on this we either display an `InteractiveCode` with the type, `mapRpcError` the
 to turn it into a readable message, or show a `Loading..` message, respectively.
 -/
 
-@[widget_module]
-def checkWidget : Widget.Module where
+@[widget]
+def checkWidget : UserWidgetDefinition where
+  name := "#check as a service"
   javascript := "
 import * as React from 'react';
 const e = React.createElement;
@@ -162,7 +160,7 @@ export default function(props) {
 Finally we can try out the widget.
 -/
 
-#widget checkWidget
+#widget checkWidget .null
 
 /-!
 ![`#check` as a service](../images/widgets_caas.png)
@@ -195,8 +193,9 @@ interact with the text editor.
 You can see the full API for this [here](https://github.com/leanprover/vscode-lean4/blob/master/lean4-infoview-api/src/infoviewApi.ts#L52)
 -/
 
-@[widget_module]
-def insertTextWidget : Widget.Module where
+@[widget]
+def insertTextWidget : UserWidgetDefinition where
+  name := "textInserter"
   javascript := "
 import * as React from 'react';
 const e = React.createElement;
@@ -214,4 +213,4 @@ export default function(props) {
 
 /-! Finally, we can try this out: -/
 
-#widget insertTextWidget
+#widget insertTextWidget .null

doc/expressions.md

@@ -406,7 +406,7 @@ The reduction relation is transitive, which is to say, is ``s`` reduces to ``s'`
 
 This last fact reflects the intuition that once we have proved a proposition ``p``, we only care that is has been proved; the proof does nothing more than witness the fact that ``p`` is true.
 
-Definitional equality is a strong notion of equality of values. Lean's logical foundations sanction treating definitionally equal terms as being the same when checking that a term is well-typed and/or that it has a given type.
+Definitional equality is a strong notion of equalty of values. Lean's logical foundations sanction treating definitionally equal terms as being the same when checking that a term is well-typed and/or that it has a given type.
 
 The reduction relation is believed to be strongly normalizing, which is to say, every sequence of reductions applied to a term will eventually terminate. The property guarantees that Lean's type-checking algorithm terminates, at least in principle. The consistency of Lean and its soundness with respect to set-theoretic semantics do not depend on either of these properties.
 

doc/faq.md

@@ -7,6 +7,15 @@ Lean is a new open source theorem prover being developed at Microsoft Research.
 It is a research project that aims to bridge the gap between interactive and automated theorem proving.
 Lean can be also used as a programming language. Actually, some Lean features are implemented in Lean itself.
 
+### Are pull requests welcome?
+
+In the past, we accepted most pull requests. This practice produced hard to maintain code, performance problems, and bugs.
+It takes time to review a pull request and make sure it is correct, useful and is not in conflict with our plans.
+Small bug fixes (few lines of code) are always welcome. Any other kind of unrequested pull request is not.
+Thus, before implementing a feature or modifying the system, please ask whether the change is welcome or not.
+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.
+
 ### Should I use Lean?
 
 Lean is under heavy development, and we are constantly trying new
@@ -27,7 +36,7 @@ It is a good place to interact with other Lean users.
 ### Should I use Lean to teach a course?
 
 Lean has been used to teach courses on logic, type theory and programming languages at CMU and the University of Washington.
-The lecture notes for the CMU course [Logic and Proof](https://lean-lang.org/logic_and_proof) are available online,
+The lecture notes for the CMU course [Logic and Proof](https://leanprover.github.io/logic_and_proof) are available online,
 but they are for Lean 3.
 If you decide to teach a course using Lean, we suggest you prepare all material before the beginning of the course, and
 make sure that Lean attends all your needs. You should not expect we will fix bugs and/or add features needed for your course.
@@ -47,7 +56,7 @@ We expect similar independent checkers will be built for Lean 4.
 
 We use [GitHub](https://github.com/leanprover/lean4/issues) to track bugs and new features.
 Bug reports are always welcome, but nitpicking issues are not (e.g., the error message is confusing).
-See also our [contribution guidelines](https://github.com/leanprover/lean4/blob/master/CONTRIBUTING.md).
+See also our [contribution guidelines](../CONTRIBUTING.md).
 
 ### Is it Lean, LEAN, or L∃∀N?
 

doc/flake.lock

@@ -69,16 +69,15 @@
     "leanInk": {
       "flake": false,
       "locked": {
-        "lastModified": 1704976501,
-        "narHash": "sha256-FSBUsbX0HxakSnYRYzRBDN2YKmH9EkA0q9p7TSPEJTI=",
-        "owner": "leanprover",
+        "lastModified": 1666154782,
+        "narHash": "sha256-0ELqEca6jZT4BW/mqkDD+uYuxW5QlZUFlNwZkvugsg8=",
+        "owner": "digama0",
         "repo": "LeanInk",
-        "rev": "51821e3c2c032c88e4b2956483899d373ec090c4",
+        "rev": "12a2aec9b5f4aa84e84fb01a9af1da00d8aaff4e",
         "type": "github"
       },
       "original": {
         "owner": "leanprover",
-        "ref": "refs/pull/57/merge",
         "repo": "LeanInk",
         "type": "github"
       }

doc/flake.nix

@@ -4,15 +4,15 @@
   inputs.lean.url = path:../.;
   inputs.flake-utils.follows = "lean/flake-utils";
   inputs.mdBook = {
-    url = "github:leanprover/mdBook";
+    url = github:leanprover/mdBook;
     flake = false;
   };
   inputs.alectryon = {
-    url = "github:Kha/alectryon/typeid";
+    url = github:Kha/alectryon/typeid;
     flake = false;
   };
   inputs.leanInk = {
-    url = "github:leanprover/LeanInk/refs/pull/57/merge";
+    url = github:leanprover/LeanInk;
     flake = false;
   };
 
@@ -27,7 +27,7 @@
         src = inputs.mdBook;
         cargoDeps = drv.cargoDeps.overrideAttrs (_: {
           inherit src;
-          outputHash = "sha256-1YlPS6cqgxE4fjy9G8pWrpP27YrrbCDnfeyIsX81ZNw=";
+          outputHash = "sha256-mhTWHs/bsmm3FH59SkUxBTl5lEH2Rlz/aF9CuBTu1TE=";
         });
         doCheck = false;
       });

doc/fplean.md

@@ -1,7 +1,7 @@
 Functional Programming in Lean
 =======================
 
-The goal of [this book](https://lean-lang.org/functional_programming_in_lean/) is to be an accessible introduction to using Lean 4 as a programming language.
+The goal of [this book](https://leanprover.github.io/functional_programming_in_lean/) is to be an accessible introduction to using Lean 4 as a programming language.
 It should be useful both to people who want to use Lean as a general-purpose programming language and to mathematicians who want to develop larger-scale proof automation but do not have a background in functional programming.
 It does not assume any background with functional programming, though it's probably not a good first book on programming in general.
 New content will be added once per month until it's done.

doc/functions.md

@@ -32,8 +32,8 @@ def fact x :=
 
 #eval fact 100
 ```
-By default, Lean only accepts total functions.
-The `partial` keyword may be used to define a recursive function without a termination proof; `partial` functions compute in compiled programs, but are opaque in proofs and during type checking.
+By default, Lean only accepts total functions. The `partial` keyword should be used when Lean cannot
+establish that a function always terminates.
 ```lean
 partial def g (x : Nat) (p : Nat -> Bool) : Nat :=
   if p x then

doc/inductive.md

@@ -1,3 +1,3 @@
 # Inductive Types
 
-[Theorem Proving in Lean](https://lean-lang.org/theorem_proving_in_lean4/inductive_types.html) has a chapter about inductive datatypes.
+[Theorem Proving in Lean](https://leanprover.github.io/theorem_proving_in_lean4/inductive_types.html) has a chapter about inductive datatypes.

doc/latex/lstlean.tex

@@ -4,7 +4,7 @@
 
 \lstdefinelanguage{lean} {
 
-% Anything between $ becomes LaTeX math mode
+% Anything betweeen $ becomes LaTeX math mode
 mathescape=false,
 % Comments may or not include Latex commands
 texcl=false,
@@ -201,7 +201,6 @@ literate=
 
 {ₙ}{{\ensuremath{_n}}}1
 {ₘ}{{\ensuremath{_m}}}1
-{ₚ}{{\ensuremath{_p}}}1
 {↑}{{\ensuremath{\uparrow}}}1
 {↓}{{\ensuremath{\downarrow}}}1
 
@@ -265,7 +264,7 @@ columns=[l]fullflexible,
 % Style for (listings') identifiers
 identifierstyle={\ttfamily\color{black}},
 % Note : highlighting of Coq identifiers is done through a new
-% delimiter definition through an lstset at the beginning of the
+% delimiter definition through an lstset at the begining of the
 % document. Don't know how to do better.
 
 % Style for declaration keywords

doc/lean3changes.md

@@ -85,7 +85,7 @@ def id5 : {α : Type} → α → α :=
 
 ## Sugar for simple functions
 
-In Lean 3, we can create simple functions from infix operators by using parentheses. For example, `(+1)` is sugar for `fun x, x + 1`. In Lean 4, we generalize this notation using `·` as a placeholder. Here are a few examples:
+In Lean 3, we can create simple functions from infix operators by using parentheses. For example, `(+1)` is sugar for `fun x, x + 1`. In Lean 4, we generalize this notation using `·` As a placeholder. Here are a few examples:
 
 ```lean
 # namespace ex3
@@ -196,8 +196,6 @@ example (f : Nat → Nat) (a b c : Nat) : f (a + b + c) = f (a + (b + c)) :=
   congrArg f (Nat.add_assoc ..)
 ```
 
-In Lean 4, writing `f(x)` in place of `f x` is no longer allowed, you must use whitespace between the function and its arguments (e.g., `f (x)`).
-
 ## Dependent function types
 
 Given `α : Type` and `β : α → Type`, `(x : α) → β x` denotes the type of functions `f` with the property that,

doc/lexical_structure.md

@@ -8,7 +8,7 @@ A Lean program consists of a stream of UTF-8 tokens where each token
 is one of the following:
 
 ```
-   token: symbol | command | ident | string | raw_string | char | numeral |
+   token: symbol | command | ident | string | char | numeral |
         : decimal | doc_comment | mod_doc_comment | field_notation
 ```
 
@@ -79,35 +79,15 @@ special characters:
 [Unicode table](https://unicode-table.com/en/) so "\xA9 Copyright 2021" is "© Copyright 2021".
 - `\uHHHH` puts the character represented by the 4 digit hexadecimal into the string, so the following
 string "\u65e5\u672c" will become "日本" which means "Japan".
-- `\` followed by a newline and then any amount of whitespace is a "gap" that is equivalent to the empty string,
-useful for letting a string literal span across multiple lines. Gaps spanning multiple lines can be confusing,
-so the parser raises an error if the trailing whitespace contains any newlines.
 
 So the complete syntax is:
 
 ```
    string       : '"' string_item '"'
-   string_item  : string_char | char_escape | string_gap
-   string_char  : [^"\\]
-   char_escape  : "\" ("\" | '"' | "'" | "n" | "t" | "x" hex_char{2} | "u" hex_char{4})
+   string_item  : string_char | string_escape
+   string_char  : [^\\]
+   string_escape: "\" ("\" | '"' | "'" | "n" | "t" | "x" hex_char{2} | "u" hex_char{4} )
    hex_char     : [0-9a-fA-F]
-   string_gap   : "\" newline whitespace*
-```
-
-Raw String Literals
-===================
-
-Raw string literals are string literals without any escape character processing.
-They begin with `r##...#"` (with zero or more `#` characters) and end with `"#...##` (with the same number of `#` characters).
-The contents of a raw string literal may contain `"##..#` so long as the number of `#` characters
-is less than the number of `#` characters used to begin the raw string literal.
-
-```
-   raw_string          : raw_string_aux(0) | raw_string_aux(1) | raw_string_aux(2) | ...
-   raw_string_aux(n)   : 'r' '#'{n} '"' raw_string_item '"' '#'{n}
-   raw_string_item(n)  : raw_string_char | raw_string_quote(n)
-   raw_string_char     : [^"]
-   raw_string_quote(n) : '"' '#'{0..n-1}
 ```
 
 Char Literals
@@ -116,9 +96,7 @@ Char Literals
 Char literals are enclosed by single quotes (``'``).
 
 ```
-   char      : "'" char_item "'"
-   char_item : char_char | char_escape
-   char_char : [^'\\]
+   char: "'" string_item "'"
 ```
 
 Numeric Literals

doc/macro_overview.md

@@ -1,7 +1,7 @@
 
 # Macro Overview
 
-The official paper describing the mechanics behind Lean 4's macro system can be
+The offical paper describing the mechanics behind Lean 4's macro system can be
 found in [Beyond Notations: Hygienic Macro Expansion for Theorem Proving
 Languages](https://arxiv.org/abs/2001.10490) by Sebastian Ullrich and Leonardo
 de Moura, and the accompanying repo with example code can be found in the
@@ -257,7 +257,7 @@ pretty printed output.
 ## Syntax expansions with `macro_rules`, and how it desugars.
 
 `macro_rules` lets you declare expansions for a given `Syntax` element using a
-syntax similar to a `match` statement. The left-hand side of a match arm is a
+syntax simlar to a `match` statement. The left-hand side of a match arm is a
 quotation (with a leading `<cat>|` for categories other than `term` and
 `command`) in which users can specify the pattern they'd like to write an
 expansion for. The right-hand side returns a syntax quotation which is the

doc/make/index.md

@@ -10,9 +10,12 @@ Platform-Specific Setup
 
 - [Linux (Ubuntu)](ubuntu.md)
 - [Windows (msys2)](msys2.md)
+- [Windows (Visual Studio)](msvc.md)
 - [Windows (WSL)](wsl.md)
 - [macOS (homebrew)](osx-10.9.md)
 - Linux/macOS/WSL via [Nix](https://nixos.org/nix/): Call `nix-shell` in the project root. That's it.
+- There is also an [**experimental** setup based purely on Nix](nix.md) that works fundamentally differently from the
+  make/CMake setup described on this page.
 
 Generic Build Instructions
 --------------------------

doc/make/nix.md

@@ -0,0 +1,110 @@
+# Building with Nix
+
+While [Nix](https://nixos.org/nix/) can be used to quickly open a shell with all dependencies for the [standard setup](index.md) installed, the user-facing [Nix Setup](../setup.md#nix-setup) can also be used to work *on* Lean.
+
+## Setup
+
+Follow the setup in the link above; to open the Lean shell inside a Lean checkout, you can also use
+```bash
+# in the Lean root directory
+$ nix-shell -A nix
+```
+
+On top of the local and remote Nix cache, we do still rely on CCache as well to make C/C++ build steps incremental, which are atomic steps from Nix's point of view.
+To enable CCache, add the following line to the config file mentioned in the setup:
+```bash
+extra-sandbox-paths = /nix/var/cache/ccache
+```
+Then set up that directory as follows:
+```bash
+sudo mkdir -m0770 -p /nix/var/cache/ccache
+# macOS standard chown doesn't support --reference
+nix shell .#nixpkgs.coreutils -c sudo chown --reference=/nix/store /nix/var/cache/ccache
+```
+
+## Basic Build Commands
+
+From the Lean root directory inside the Lean shell:
+```bash
+nix build .#stage1  # build this stage's stdlib & executable
+nix build .#stage1.test  # run all tests
+nix run .#stage1.update-stage0  # update ./stage0 from this stage
+nix run .#stage1.update-stage0-commit  # ...and commit the results
+```
+The `stage1.` part in each command is optional:
+```bash
+nix build .#test  # run tests for stage 1
+nix build .  # build stage 1
+nix build  # ditto
+```
+
+## Build Process Description
+
+The Nix build process conceptually works the same as described in [Lean Build Pipeline](index.md#lean-build-pipeline).
+However, there are two important differences in practice apart from the standard Nix properties (hermeneutic, reproducible builds stored in a global hash-indexed store etc.):
+* Only files tracked by git (using `git add` or at least `git add --intent-to-add`) are compiled.
+This is actually a general property of Nix flakes, and has the benefit of making it basically impossible to forget to commit a file (at least in `src/`).
+* Only files reachable from `src/Lean.lean` are compiled.
+This is because modules are discovered not from a directory listing anymore but by recursively compiling all dependencies of that top module.
+
+## Editor Integration
+
+As in the standard Nix setup.
+After adding `src/` as an LSP workspace, it should automatically fall back to using stage 0 in there.
+
+Note that the UX of `{emacs,vscode}-dev` is quite different from the Make-based setup regarding the compilation of dependencies:
+there is no mutable directory incrementally filled by the build that we could point the editor at for .olean files.
+Instead, `emacs-dev` will gather the individual dependency outputs from the Nix store when checking a file -- and build them on the fly when necessary.
+However, it will only ever load changes saved to disk, not ones opened in other buffers.
+
+The absence of a mutable output directory also means that the Lean server will not automatically pick up `.ilean` metadata from newly compiled files.
+Instead, you can run `nix run .#link-ilean` to symlink the `.ilean` tree of the stdlib state at that point in time to `src/build/lib`, where the server should automatically find them.
+
+## Other Fun Stuff to Do with Nix
+
+Open Emacs with Lean set up from an arbitrary commit (without even cloning Lean beforehand... if your Nix is new enough):
+```bash
+nix run github:leanprover/lean4/7e4edeb#emacs-package
+```
+
+Open a shell with `lean` and `LEAN_PATH` set up for compiling a specific module (this is exactly what `emacs-dev` is doing internally):
+```bash
+nix develop .#mods.\"Lean.Parser.Basic\"
+# alternatively, directly pass a command to execute:
+nix develop .#stage2.mods.\"Init.Control.Basic\" -c bash -c 'lean $src -Dtrace.Elab.command=true'
+```
+
+Not sure what you just broke? Run Lean from (e.g.) the previous commit on a file:
+```bash
+nix run .\?rev=$(git rev-parse @^) scratch.lean
+```
+
+Work on two adjacent stages at the same time without the need for repeatedly updating and reverting `stage0/`:
+```bash
+# open an editor that will use only committed changes (so first commit them when changing files)
+nix run .#HEAD-as-stage1.emacs-dev&
+# open a second editor that will use those commited changes as stage 0
+# (so don't commit changes done here until you are done and ran a final `update-stage0-commit`)
+nix run .#HEAD-as-stage0.emacs-dev&
+```
+To run `nix build` on the second stage outside of the second editor, use
+```bash
+nix build .#stage0-from-input --override-input lean-stage0 .\?rev=$(git rev-parse HEAD)
+```
+This setup will inadvertently change your `flake.lock` file, which you can revert when you are done.
+
+...more surely to come...
+
+## Debugging
+
+Since Nix copies all source files before compilation, you will need to map debug symbols back to the original path using `set substitute-path` in GDB.
+For example, for a build on Linux with the Nix sandbox activated:
+```bash
+(gdb) f
+#1  0x0000000000d23a4f in lean_inc (o=0x1) at /build/source/build/include/lean/lean.h:562
+562	/build/source/build/include/lean/lean.h: No such file or directory.
+(gdb) set substitute-path /build/source/build src
+(gdb) f
+#1  0x0000000000d23a4f in lean_inc (o=0x1) at /build/source/build/include/lean/lean.h:562
+562	static inline void lean_inc(lean_object * o) { if (!lean_is_scalar(o)) lean_inc_ref(o); }
+```

doc/metaprogramming-arith.md

@@ -60,7 +60,7 @@ While parsing `a * (b + c)`, `(b + c)` is assigned a precedence `60` by the addi
 the right argument to have precedence **at least** 71. Thus, this parse is invalid. In contrast, `(a * b) + c` assigns
 a precedence of `70` to `(a * b)`. This is compatible with addition which expects the left argument to have precedence
 **at least `60` ** (`70` is greater than `60`). Thus, the string `a * b + c` is parsed as `(a * b) + c`.
-For more details, please look at the [Lean manual on syntax extensions](./notation.md#notations-and-precedence).
+For more details, please look at the [Lean manual on syntax extensions](../syntax.md#notations-and-precedence).
 
 To go from strings into `Arith`, we define a macro to
 translate the syntax category `arith` into an `Arith` inductive value that

doc/monads/applicatives.lean

@@ -212,7 +212,7 @@ so you get a nice zipped list like this:
 -- [(1, 4), (2, 5), (3, 6)]
 /-!
 
-And of course, as you would expect, there is an `unzip` also:
+And of couse, as you would expect, there is an `unzip` also:
 
 -/
 #eval List.unzip (List.zip [1, 2, 3] [4, 5, 6])
@@ -286,7 +286,7 @@ But you will need to understand full Monads before this will make sense.
 Diving a bit deeper, (you can skip this and jump to the [Applicative
 Laws](laws.lean.md#what-are-the-applicative-laws) if don't want to dive into this implementation detail right
 now). But, if you write a simple `Option` example `(.*.) <$> some 4 <*> some 5` that produces `some 20`
-using `Seq.seq` you will see something interesting:
+using `Seq.seq` you will see somthing interesting:
 
 -/
 #eval Seq.seq ((.*.) <$> some 4) (fun (_ : Unit) => some 5) -- some 20

doc/monads/except.lean

@@ -33,7 +33,7 @@ convert the pure non-monadic value `x / y` into the required `Except` object.  S
 
 Now this return typing would get tedious if you had to include it everywhere that you call this
 function, however, Lean type inference can clean this up. For example, you can define a test
-function that calls the `divide` function and you don't need to say anything here about the fact that
+function can calls the `divide` function and you don't need to say anything here about the fact that
 it might throw an error, because that is inferred:
 -/
 def test := divide 5 0

doc/monads/readers.lean

@@ -113,7 +113,7 @@ the monadic container type.
 to write `(readerFunc3 args).run env` and this is a bit ugly, so Lean provides an infix operator
 `|>` that eliminates those parentheses so you can write `readerFunc3 args |>.run env` and then you can
 chain multiple monadic actions like this `m1 args1 |>.run args2 |>.run args3` and this is the
-recommended style.  You will see this pattern used heavily in Lean code.
+recommended style.  You will see this patten used heavily in Lean code.
 
 The `let env ← read` expression in `readerFunc1` unwraps the environment from the `ReaderM` so we
 can use it. Each type of monad might provide one or more extra functions like this, functions that

doc/quickstart.md

@@ -1,18 +1,51 @@
 # Quickstart
 
-These instructions will walk you through setting up Lean 4 together with VS Code as an editor for Lean 4.
-See [Setup](./setup.md) for supported platforms and other ways to set up Lean 4.
+These instructions will walk you through setting up Lean using the "basic" setup and VS Code as the editor.
+See [Setup](./setup.md) for other ways, supported platforms, and more details on setting up Lean.
+
+See quick [walkthrough demo video](https://www.youtube.com/watch?v=yZo6k48L0VY).
 
 1. Install [VS Code](https://code.visualstudio.com/).
 
-1. Launch VS Code and install the `lean4` extension by clicking on the "Extensions" sidebar entry and searching for "lean4".
+1. Launch VS Code and install the `lean4` extension.
 
     ![installing the vscode-lean4 extension](images/code-ext.png)
 
-1. Open the Lean 4 setup guide by creating a new text file using "File > New Text File" (`Ctrl+N`), clicking on the ∀-symbol in the top right and selecting "Documentation… > Setup: Show Setup Guide".
+1. Create a new file using "File > New Text File" (`Ctrl+N`). Click the `Select a language` prompt, type in `lean4`, and hit ENTER.  You should see the following popup:
+    ![elan](images/install_elan.png)
 
-    ![show setup guide](images/show-setup-guide.png)
+    Click the "Install Lean using Elan" button. You should see some progress output like this:
 
-1. Follow the Lean 4 setup guide. It will walk you through learning resources for Lean 4, teach you how to set up Lean's dependencies on your platform, install Lean 4 for you at the click of a button and help you set up your first project.
+    ```
+    info: syncing channel updates for 'nightly'
+    info: latest update on nightly, lean version nightly-2021-12-05
+    info: downloading component 'lean'
+    ```
 
-    ![setup guide](images/setup_guide.png)
+1. While it is installing, you can paste the following Lean program into the new file:
+
+    ```lean
+    #eval Lean.versionString
+    ```
+
+    When the installation has finished, the Lean Language Server should start automatically and you should get syntax-highlighting and a "Lean Infoview" popping up on the right.  You will see the output of the `#eval` statement when
+    you place your cursor at the end of the statement.
+
+    ![successful setup](images/code-success.png)
+
+You are set up!
+
+## Create a Lean Project
+
+You can now create a Lean project in a new folder. Run `lake init foo` from "View > Terminal" to create a package, followed by `lake build` to get an executable version of your Lean program.
+On Linux/macOS, you first have to follow the instructions printed by the Lean installation or log out and in again for the Lean executables to be available in you terminal.
+
+Note: Packages **have** to be opened using "File > Open Folder..." for imports to work.
+Saved changes are visible in other files after running "Lean 4: Refresh File Dependencies" (`Ctrl+Shift+X`).
+
+## Troubleshooting
+
+**The InfoView says "Waiting for Lean server to start..." forever.**
+
+Check that the VS Code Terminal is not showing some installation errors from `elan`.
+If that doesn't work, try also running the VS Code command `Developer: Reload Window`.

doc/semantic_highlighting.md

@@ -4,7 +4,7 @@ Semantic Highlighting
 The Lean language server provides semantic highlighting information to editors. In order to benefit from this in VSCode, you may need to activate the "Editor > Semantic Highlighting" option in the preferences (this is translates to `"editor.semanticHighlighting.enabled": true,`
 in `settings.json`). The default option here is to let your color theme decides whether it activates semantic highlighting (the default themes Dark+ and Light+ do activate it for instance).
 
-However this may be insufficient if your color theme does not distinguish enough syntax categories or distinguishes them very subtly. For instance the default Light+ theme uses color `#001080` for variables. This is awfully close to `#000000` that is used as the default text color. This makes it very easy to miss an accidental use of [auto bound implicit arguments](https://lean-lang.org/lean4/doc/autobound.html). For instance in
+However this may be insufficient if your color theme does not distinguish enough syntax categories or distinguishes them very subtly. For instance the default Light+ theme uses color `#001080` for variables. This is awfully close to `#000000` that is used as the default text color. This makes it very easy to miss an accidental use of [auto bound implicit arguments](https://leanprover.github.io/lean4/doc/autobound.html). For instance in
 ```lean
 def my_id (n : nat) := n
 ```

doc/setup.md

@@ -2,7 +2,7 @@
 
 ### Tier 1
 
-Platforms built & tested by our CI, available as binary releases via elan (see below)
+Platforms built & tested by our CI, available as nightly & stable releases via elan (see above)
 
 * x86-64 Linux with glibc 2.27+
 * x86-64 macOS 10.15+
@@ -10,15 +10,13 @@ Platforms built & tested by our CI, available as binary releases via elan (see b
 
 ### Tier 2
 
-Platforms cross-compiled but not tested by our CI, available as binary releases
+Platforms cross-compiled but not tested by our CI, available as nightly & stable releases
 
 Releases may be silently broken due to the lack of automated testing.
 Issue reports and fixes are welcome.
 
 * aarch64 Linux with glibc 2.27+
-* aarch64 (Apple Silicon) macOS
-* x86 (32-bit) Linux
-* Emscripten Web Assembly
+* aarch64 (M1) macOS
 
 <!--
 ### Tier 3
@@ -28,17 +26,28 @@ Platforms that are known to work from manual testing, but do not come with CI or
 
 # Setting Up Lean
 
-See also the [quickstart](./quickstart.md) instructions for a standard setup with VS Code as the editor.
+There are currently two ways to set up a Lean 4 development environment:
+
+* [basic setup](./setup.md#basic-setup) (Linux/macOS/Windows): uses [`elan`](https://github.com/leanprover/elan) + your preinstalled editor
+* [Nix setup](./setup.md#nix-setup) (Linux/macOS/WSL): uses the [Nix](https://nixos.org/nix/) package manager for installing all dependencies localized to your project
+
+See also the [quickstart](./quickstart.md) instructions for using the basic setup with VS Code as the editor.
+
+## Basic Setup
 
 Release builds for all supported platforms are available at <https://github.com/leanprover/lean4/releases>.
 Instead of downloading these and setting up the paths manually, however, it is recommended to use the Lean version manager [`elan`](https://github.com/leanprover/elan) instead:
 ```sh
 $ elan self update  # in case you haven't updated elan in a while
-# download & activate latest Lean 4 stable release (https://github.com/leanprover/lean4/releases)
+# download & activate latest Lean 4 release (https://github.com/leanprover/lean4/releases)
 $ elan default leanprover/lean4:stable
+# alternatively, use the latest nightly build (https://github.com/leanprover/lean4-nightly/releases)
+$ elan default leanprover/lean4:nightly
+# alternatively, activate Lean 4 in current directory only
+$ elan override set leanprover/lean4:stable
 ```
 
-## `lake`
+### `lake`
 
 Lean 4 comes with a package manager named `lake`.
 Use `lake init foo` to initialize a Lean package `foo` in the current directory, and `lake build` to typecheck and build it as well as all its dependencies. Use `lake help` to learn about further commands.
@@ -50,16 +59,88 @@ Foo.lean       # main file, import via `import Foo`
 Foo/
   A.lean       # further files, import via e.g. `import Foo.A`
   A/...        # further nesting
-.lake/         # `lake` build output directory
+build/         # `lake` build output directory
 ```
 
-After running `lake build` you will see a binary named `./.lake/build/bin/foo` and when you run it you should see the output:
+After running `lake build` you will see a binary named `./build/bin/foo` and when you run it you should see the output:
 ```
 Hello, world!
 ```
 
-## Editing
+### Editing
 
 Lean implements the [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) that can be used for interactive development in [Emacs](https://github.com/leanprover/lean4-mode), [VS Code](https://github.com/leanprover-community/vscode-lean4), and possibly other editors.
 
 Changes must be saved to be visible in other files, which must then be invalidated using an editor command (see links above).
+
+## Nix Setup
+
+The alternative setup based on Nix provides a perfectly reproducible development environment for your project from the Lean version down to the editor and Lean extension.
+However, it is still experimental and subject to change; in particular, it is heavily based on an unreleased version of Nix enabling [Nix Flakes](https://www.tweag.io/blog/2020-05-25-flakes/). The setup has been tested on NixOS, other Linux distributions, and macOS.
+
+After installing (any version of) Nix (<https://nixos.org/download.html>), you can easily open a shell with the particular pre-release version of Nix needed by and tested with our setup (called the "Lean shell" from here on):
+```bash
+$ nix-shell https://github.com/leanprover/lean4/archive/master.tar.gz -A nix
+```
+While this shell is sufficient for executing the steps below, it is recommended to also set the following options in `/etc/nix/nix.conf` (`nix.extraOptions` in NixOS):
+```
+max-jobs = auto  # Allow building multiple derivations in parallel
+keep-outputs = true  # Do not garbage-collect build time-only dependencies (e.g. clang)
+# Allow fetching build results from the Lean Cachix cache
+trusted-substituters = https://lean4.cachix.org/
+trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= lean4.cachix.org-1:mawtxSxcaiWE24xCXXgh3qnvlTkyU7evRRnGeAhD4Wk=
+```
+On a multi-user installation of Nix (the default), you need to restart the Nix daemon afterwards:
+```bash
+sudo pkill nix-daemon
+```
+
+The [Cachix](https://cachix.org/) integration will magically beam any build steps already executed by the CI right onto your machine when calling Nix commands in the shell opened above.
+It can be set up analogously as a cache for your own project.
+
+Note: Your system Nix might print warnings about not knowing some of the settings used by the Lean shell Nix, which can be ignored.
+
+### Basic Commands
+
+From a Lean shell, run
+```bash
+$ nix flake new mypkg -t github:leanprover/lean4
+```
+to create a new Lean package in directory `mypkg` using the latest commit of Lean 4.
+Such packages follow the same directory layout as described in the basic setup above, except for a `lakefile.lean` replaced by a `flake.nix` file set up so you can run Nix commands on it, for example:
+```bash
+$ nix build  # build package and all dependencies
+$ nix build .#executable  # compile `main` definition into executable (after you've added one)
+$ nix run .#emacs-dev  # open a pinned version of Emacs with lean4-mode fully set up
+$ nix run .#emacs-dev MyPackage.lean  # arguments can be passed as well, e.g. the file to open
+$ nix run .#vscode-dev MyPackage.lean  # ditto, using VS Code
+```
+Note that if you rename `MyPackage.lean`, you also have to adjust the `name` attribute in `flake.nix` accordingly.
+Also note that if you turn the package into a Git repository, only tracked files will be visible to Nix.
+
+As in the basic setup, changes need to be saved to be visible in other files, which have then to be invalidated via an editor command.
+
+If you don't want to or cannot start the pinned editor from Nix, e.g. because you're running Lean inside WSL/a container/on a different machine, you can manually point your editor at the `lean` wrapper script the commands above use internally:
+```bash
+$ nix build .#lean-dev -o result-lean-dev
+```
+The resulting `./result-lean-dev/bin/lean` script essentially runs `nix run .#lean` in the current project's root directory when you open a Lean file or use the "refresh dependencies" command such that the correct Lean version for that project is executed.
+This includes selecting the correct stage of Lean (which it will compile on the fly, though without progress output) if you are [working on Lean itself](./make/nix.md#editor-integration).
+
+Package dependencies can be added as further input flakes and passed to the `deps` list of `buildLeanPackage`. Example: <https://github.com/Kha/testpkg2/blob/master/flake.nix#L5>
+
+For hacking, it can be useful to temporarily override an input with a local checkout/different version of a dependency:
+```bash
+$ nix build --override-input somedep path/to/somedep
+```
+
+On a build error, Nix will show the last 10 lines of the output by default. You can pass `-L` to `nix build` to show all lines, or pass the shown `*.drv` path to `nix log` to show the full log after the fact.
+
+Keeping all outputs ever built on a machine alive can accumulate to quite impressive amounts of disk space, so you might want to trigger the Nix GC when `/nix/store/` has grown too large:
+```bash
+nix-collect-garbage
+```
+This will remove everything not reachable from "GC roots" such as the `./result` symlink created by `nix build`.
+
+Note that the package information in `flake.nix` is currently completely independent from `lakefile.lean` used in the basic setup.
+Unifying the two formats is TBD.

doc/syntax_highlight_in_latex.md

@@ -67,9 +67,6 @@ theorem funext {f₁ f₂ : ∀ (x : α), β x} (h : ∀ x, f₁ x = f₂ x) : f
 \end{document}
 ```
 
-If your version of `minted` is v2.7 or newer, but before v3.0,
-you will additionally need to follow the workaround described in https://github.com/gpoore/minted/issues/360.
-
 You can then compile `test.tex` by executing the following command:
 
 ```bash

doc/tactics.md

@@ -224,7 +224,7 @@ example (n : Nat) : (binToChar n).isSome -> n = 0 ∨ n = 1 := by
   next => exact fun _ => Or.inr rfl
   next => intro h; cases h
 
-/- Hypotheses about previous cases can be accessed by assigning them a
+/- Hypotheses about previous cases can be accessesd by assigning them a
    name, like `ne_zero` below. Information about the matched term can also
    be preserved using the `generalizing` tactic: -/
 example (n : Nat) : (n = 0) -> (binToChar n = some '0') := by

doc/tour.md

@@ -15,7 +15,7 @@ The most fundamental pieces of any Lean program are functions organized into nam
 [Functions](./functions.md) perform work on inputs to produce outputs,
 and they are organized under [namespaces](./namespaces.md),
 which are the primary way you group things in Lean.
-They are defined using the `def` command,
+They are defined using the [`def`](./definitions.md) command,
 which give the function a name and define its arguments.
 
 ```lean

doc/tpil.md

@@ -1,5 +1,5 @@
 Theorem Proving in Lean
 =======================
 
-We strongly encourage you to read the book [Theorem Proving in Lean](https://lean-lang.org/theorem_proving_in_lean4/title_page.html).
+We strongly encourage you to read the book [Theorem Proving in Lean](https://leanprover.github.io/theorem_proving_in_lean4/title_page.html).
 Many Lean users consider it to be the Lean Bible.

doc/typeclass.md

@@ -99,11 +99,11 @@ Let us start with the first step of the program above, declaring an appropriate
 
 ```lean
 # namespace Ex
-class Inhabited (a : Sort u) where
+class Inhabited (a : Type u) where
   default : a
 
 #check @Inhabited.default
--- Inhabited.default : {a : Sort u} → [self : Inhabited a] → a
+-- Inhabited.default : {a : Type u} → [self : Inhabited a] → a
 # end Ex
 ```
 Note `Inhabited.default` doesn't have any explicit argument.
@@ -114,7 +114,7 @@ Now we populate the class with some instances:
 
 ```lean
 # namespace Ex
-# class Inhabited (a : Sort _) where
+# class Inhabited (a : Type _) where
 #  default : a
 instance : Inhabited Bool where
   default := true
@@ -138,7 +138,7 @@ instance : Inhabited Prop where
 You can use the command `export` to create the alias `default` for `Inhabited.default`
 ```lean
 # namespace Ex
-# class Inhabited (a : Sort _) where
+# class Inhabited (a : Type _) where
 #  default : a
 # instance : Inhabited Bool where
 #  default := true
@@ -174,7 +174,7 @@ instance [Inhabited a] [Inhabited b] : Inhabited (a × b) where
 With this added to the earlier instance declarations, type class instance can infer, for example, a default element of ``Nat × Bool``:
 ```lean
 # namespace Ex
-# class Inhabited (a : Sort u) where
+# class Inhabited (a : Type u) where
 #  default : a
 # instance : Inhabited Bool where
 #  default := true
@@ -191,14 +191,8 @@ instance [Inhabited a] [Inhabited b] : Inhabited (a × b) where
 ```
 Similarly, we can inhabit type function with suitable constant functions:
 ```lean
-# namespace Ex
-# class Inhabited (a : Sort u) where
-#  default : a
-# opaque default [Inhabited a] : a :=
-#  Inhabited.default
 instance [Inhabited b] : Inhabited (a -> b) where
   default := fun _ => default
-# end Ex
 ```
 As an exercise, try defining default instances for other types, such as `List` and `Sum` types.
 

doc/whatIsLean.md

@@ -36,7 +36,7 @@ Lean has numerous features, including:
 - [Monads](./monads/intro.md)
 - [Extensible syntax](./syntax.md)
 - Hygienic macros
-- [Dependent types](https://lean-lang.org/theorem_proving_in_lean4/dependent_type_theory.html)
-- [Metaprogramming](./macro_overview.md)
+- [Dependent types](https://leanprover.github.io/theorem_proving_in_lean4/dependent_type_theory.html)
+- [Metaprogramming](./metaprogramming.md)
 - Multithreading
 - Verification: you can prove properties of your functions using Lean itself

flake.lock

@@ -18,11 +18,11 @@
     "lean4-mode": {
       "flake": false,
       "locked": {
-        "lastModified": 1676498134,
-        "narHash": "sha256-u3WvyKxOViZG53hkb8wd2/Og6muTecbh+NdflIgVeyk=",
+        "lastModified": 1659020985,
+        "narHash": "sha256-+dRaXB7uvN/weSZiKcfSKWhcdJVNg9Vg8k0pJkDNjpc=",
         "owner": "leanprover",
         "repo": "lean4-mode",
-        "rev": "2c6ef33f476fdf5eb5e4fa4fa023ba8b11372440",
+        "rev": "37d5c99b7b29c80ab78321edd6773200deb0bca6",
         "type": "github"
       },
       "original": {
@@ -101,11 +101,11 @@
     },
     "nixpkgs_2": {
       "locked": {
-        "lastModified": 1686089707,
-        "narHash": "sha256-LTNlJcru2qJ0XhlhG9Acp5KyjB774Pza3tRH0pKIb3o=",
+        "lastModified": 1657208011,
+        "narHash": "sha256-BlIFwopAykvdy1DYayEkj6ZZdkn+cVgPNX98QVLc0jM=",
         "owner": "NixOS",
         "repo": "nixpkgs",
-        "rev": "af21c31b2a1ec5d361ed8050edd0303c31306397",
+        "rev": "2770cc0b1e8faa0e20eb2c6aea64c256a706d4f2",
         "type": "github"
       },
       "original": {

flake.nix

@@ -1,11 +1,11 @@
 {
   description = "Lean interactive theorem prover";
 
-  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
-  inputs.flake-utils.url = "github:numtide/flake-utils";
-  inputs.nix.url = "github:NixOS/nix";
+  inputs.nixpkgs.url = github:NixOS/nixpkgs/nixpkgs-unstable;
+  inputs.flake-utils.url = github:numtide/flake-utils;
+  inputs.nix.url = github:NixOS/nix;
   inputs.lean4-mode = {
-    url = "github:leanprover/lean4-mode";
+    url = github:leanprover/lean4-mode;
     flake = false;
   };
   # used *only* by `stage0-from-input` below
@@ -24,13 +24,13 @@
         # for `vscode-with-extensions`
         config.allowUnfree = true;
       };
-      lean-packages = pkgs.callPackage (./nix/packages.nix) { src = ./.; inherit nix lean4-mode; };
+      lean-packages = pkgs.callPackage (./nix/packages.nix) { inherit nix lean4-mode; };
     in {
       packages = lean-packages // rec {
         debug = lean-packages.override { debug = true; };
         stage0debug = lean-packages.override { stage0debug = true; };
-        asan = lean-packages.override { extraCMakeFlags = [ "-DLEAN_EXTRA_CXX_FLAGS=-fsanitize=address" "-DLEANC_EXTRA_FLAGS=-fsanitize=address" "-DSMALL_ALLOCATOR=OFF" "-DSYMBOLIC=OFF" ]; };
-        asandebug = asan.override { debug = true; };
+        sanitized = lean-packages.override { extraCMakeFlags = [ "-DLEAN_EXTRA_CXX_FLAGS=-fsanitize=address,undefined" "-DLEANC_EXTRA_FLAGS=-fsanitize=address,undefined" "-DSMALL_ALLOCATOR=OFF" "-DSYMBOLIC=OFF" ]; };
+        sandebug = sanitized.override { debug = true; };
         tsan = lean-packages.override {
           extraCMakeFlags = [ "-DLEAN_EXTRA_CXX_FLAGS=-fsanitize=thread" "-DLEANC_EXTRA_FLAGS=-fsanitize=thread" "-DCOMPRESSED_OBJECT_HEADER=OFF" ];
           stage0 = (lean-packages.override {

lean-toolchain

@@ -1 +0,0 @@
-lean4

lean.code-workspace

@@ -1,57 +0,0 @@
-{
-	"folders": [
-		{
-			"path": "."
-		},
-		{
-			"path": "src"
-		},
-		{
-			"path": "tests"
-		}
-	],
-	"settings": {
-		"files.insertFinalNewline": true,
-		"files.trimTrailingWhitespace": true,
-		"cmake.buildDirectory": "${workspaceFolder}/build/release",
-		"cmake.generator": "Unix Makefiles",
-		"[markdown]": {
-			"rewrap.wrappingColumn": 70
-		},
-		"[lean4]": {
-			"editor.rulers": [
-				100
-			]
-		}
-	},
-	"tasks": {
-		"version": "2.0.0",
-		"tasks": [
-			{
-				"label": "build",
-				"type": "shell",
-				"command": "make -C build/release -j$(nproc 2>/dev/null || sysctl -n hw.logicalcpu 2>/dev/null || echo 4)",
-				"problemMatcher": [],
-				"group": {
-					"kind": "build",
-					"isDefault": true
-				}
-			},
-			{
-				"label": "test",
-				"type": "shell",
-				"command": "NPROC=$(nproc 2>/dev/null || sysctl -n hw.logicalcpu 2>/dev/null || echo 4); CTEST_OUTPUT_ON_FAILURE=1 make -C build/release test -j$NPROC ARGS=\"-j$NPROC\"",
-				"problemMatcher": [],
-				"group": {
-					"kind": "test",
-					"isDefault": true
-				}
-			}
-		]
-	},
-	"extensions": {
-		"recommendations": [
-			"leanprover.lean4"
-		]
-	}
-}

nix/bootstrap.nix

@@ -1,5 +1,5 @@
-{ src, debug ? false, stage0debug ? false, extraCMakeFlags ? [],
-  stdenv, lib, cmake, gmp, git, gnumake, bash, buildLeanPackage, writeShellScriptBin, runCommand, symlinkJoin, lndir, perl, gnused, darwin, llvmPackages, linkFarmFromDrvs,
+{ debug ? false, stage0debug ? false, extraCMakeFlags ? [],
+  stdenv, lib, cmake, gmp, gnumake, bash, buildLeanPackage, writeShellScriptBin, runCommand, symlinkJoin, lndir, perl, gnused, darwin, llvmPackages, linkFarmFromDrvs,
   ... } @ args:
 with builtins;
 rec {
@@ -26,7 +26,7 @@ rec {
   lean-bin-tools-unwrapped = buildCMake {
     name = "lean-bin-tools";
     outputs = [ "out" "leanc_src" ];
-    realSrc = sourceByRegex (src + "/src") [ "CMakeLists\.txt" "cmake.*" "bin.*" "include.*" ".*\.in" "Leanc\.lean" ];
+    realSrc = sourceByRegex ../src [ "CMakeLists\.txt" "cmake.*" "bin.*" "include.*" ".*\.in" "Leanc\.lean" ];
     preConfigure = ''
       touch empty.cpp
       sed -i 's/add_subdirectory.*//;s/set(LEAN_OBJS.*/set(LEAN_OBJS empty.cpp)/' CMakeLists.txt
@@ -44,7 +44,7 @@ rec {
   };
   leancpp = buildCMake {
     name = "leancpp";
-    src = src + "/src";
+    src = ../src;
     buildFlags = [ "leancpp" "leanrt" "leanrt_initial-exec" "shell" ];
     installPhase = ''
       mkdir -p $out
@@ -55,17 +55,22 @@ rec {
   };
   stage0 = args.stage0 or (buildCMake {
     name = "lean-stage0";
-    realSrc = src + "/stage0/src";
+    realSrc = ../stage0/src;
     debug = stage0debug;
     cmakeFlags = [ "-DSTAGE=0" ];
     extraCMakeFlags = [];
     preConfigure = ''
-      ln -s ${src + "/stage0/stdlib"} ../stdlib
+      ln -s ${../stage0/stdlib} ../stdlib
     '';
     installPhase = ''
       mkdir -p $out/bin $out/lib/lean
       mv bin/lean $out/bin/
-      mv lib/lean/*.so $out/lib/lean
+      mv lib/lean/libleanshared.* $out/lib/lean
+   '' + lib.optionalString stdenv.isDarwin ''
+      for lib in $(otool -L $out/bin/lean | tail -n +2 | cut -d' ' -f1); do
+        if [[ "$lib" == *lean* ]]; then install_name_tool -change "$lib" "$out/lib/lean/$(basename $lib)" $out/bin/lean; fi
+      done
+      otool -L $out/bin/lean
     '';
     meta.mainProgram = "lean";
   });
@@ -78,13 +83,13 @@ rec {
         # use same stage for retrieving dependencies
         lean-leanDeps = stage0;
         lean-final = self;
-      } ({
-        src = src + "/src";
-        roots = [ { mod = args.name; glob = "andSubmodules"; } ];
-        fullSrc = src;
-        srcPath = "$PWD/src:$PWD/src/lake";
-        inherit debug;
         leanFlags = [ "-DwarningAsError=true" ];
+      } ({
+        src = ../src;
+        roots = [ { mod = args.name; glob = "andSubmodules"; } ];
+        fullSrc = ../.;
+        srcPrefix = "src";
+        inherit debug;
       } // args);
       Init' = build { name = "Init"; deps = []; };
       Lean' = build { name = "Lean"; deps = [ Init' ]; };
@@ -96,56 +101,37 @@ rec {
       inherit (Lean) emacs-dev emacs-package vscode-dev vscode-package;
       Init = attachSharedLib leanshared Init';
       Lean = attachSharedLib leanshared Lean' // { allExternalDeps = [ Init ]; };
-      Lake = build {
-        name = "Lake";
-        src = src + "/src/lake";
-        deps = [ Init Lean ];
-      };
-      Lake-Main = build {
-        name = "Lake.Main";
-        roots = [ "Lake.Main" ];
-        executableName = "lake";
-        deps = [ Lake ];
-        linkFlags = lib.optional stdenv.isLinux "-rdynamic";
-        src = src + "/src/lake";
-      };
-      stdlib = [ Init Lean Lake ];
+      stdlib = [ Init Lean ];
       modDepsFiles = symlinkJoin { name = "modDepsFiles"; paths = map (l: l.modDepsFile) (stdlib ++ [ Leanc ]); };
       depRoots = symlinkJoin { name = "depRoots"; paths = map (l: l.depRoots) stdlib; };
       iTree = symlinkJoin { name = "ileans"; paths = map (l: l.iTree) stdlib; };
+      extlib = stdlib;  # TODO: add Lake
       Leanc = build { name = "Leanc"; src = lean-bin-tools-unwrapped.leanc_src; deps = stdlib; roots = [ "Leanc" ]; };
-      stdlibLinkFlags = "-L${Init.staticLib} -L${Lean.staticLib} -L${Lake.staticLib} -L${leancpp}/lib/lean";
-      libInit_shared = runCommand "libInit_shared" { buildInputs = [ stdenv.cc ]; libName = "libInit_shared${stdenv.hostPlatform.extensions.sharedLibrary}"; } ''
-        mkdir $out
-        LEAN_CC=${stdenv.cc}/bin/cc ${lean-bin-tools-unwrapped}/bin/leanc -shared -Wl,-Bsymbolic \
-          -Wl,--whole-archive -lInit ${leancpp}/lib/libleanrt_initial-exec.a -Wl,--no-whole-archive -lstdc++ -lm ${stdlibLinkFlags} \
-          $(${llvmPackages.libllvm.dev}/bin/llvm-config --ldflags --libs) \
-          -o $out/$libName
-      '';
+      stdlibLinkFlags = "-L${Init.staticLib} -L${Lean.staticLib} -L${leancpp}/lib/lean";
       leanshared = runCommand "leanshared" { buildInputs = [ stdenv.cc ]; libName = "libleanshared${stdenv.hostPlatform.extensions.sharedLibrary}"; } ''
         mkdir $out
-        LEAN_CC=${stdenv.cc}/bin/cc ${lean-bin-tools-unwrapped}/bin/leanc -shared -Wl,-Bsymbolic \
-          ${libInit_shared}/* -Wl,--whole-archive -lLean -lleancpp -Wl,--no-whole-archive -lstdc++ -lm ${stdlibLinkFlags} \
+        LEAN_CC=${stdenv.cc}/bin/cc ${lean-bin-tools-unwrapped}/bin/leanc -shared ${lib.optionalString stdenv.isLinux "-Wl,-Bsymbolic"} \
+          ${if stdenv.isDarwin then "-Wl,-force_load,${Init.staticLib}/libInit.a -Wl,-force_load,${Lean.staticLib}/libLean.a -Wl,-force_load,${leancpp}/lib/lean/libleancpp.a ${leancpp}/lib/libleanrt_initial-exec.a -lc++"
+            else "-Wl,--whole-archive -lInit -lLean -lleancpp ${leancpp}/lib/libleanrt_initial-exec.a -Wl,--no-whole-archive -lstdc++"} -lm ${stdlibLinkFlags} \
           $(${llvmPackages.libllvm.dev}/bin/llvm-config --ldflags --libs) \
           -o $out/$libName
       '';
-      mods = foldl' (mods: pkg: mods // pkg.mods) {} stdlib;
-      print-paths = Lean.makePrintPathsFor [] mods;
+      mods = Init.mods // Lean.mods;
       leanc = writeShellScriptBin "leanc" ''
-        LEAN_CC=${stdenv.cc}/bin/cc ${Leanc.executable}/bin/leanc -I${lean-bin-tools-unwrapped}/include ${stdlibLinkFlags} -L${libInit_shared} -L${leanshared} "$@"
+        LEAN_CC=${stdenv.cc}/bin/cc ${Leanc.executable}/bin/leanc -I${lean-bin-tools-unwrapped}/include ${stdlibLinkFlags} -L${leanshared} "$@"
       '';
       lean = runCommand "lean" { buildInputs = lib.optional stdenv.isDarwin darwin.cctools; } ''
         mkdir -p $out/bin
-        ${leanc}/bin/leanc ${leancpp}/lib/lean.cpp.o ${libInit_shared}/* ${leanshared}/* -o $out/bin/lean
+        ${leanc}/bin/leanc ${leancpp}/lib/lean.cpp.o ${leanshared}/* -o $out/bin/lean
       '';
       # derivation following the directory layout of the "basic" setup, mostly useful for running tests
       lean-all = stdenv.mkDerivation {
         name = "lean-${desc}";
         buildCommand = ''
           mkdir -p $out/bin $out/lib/lean
-          ln -sf ${leancpp}/lib/lean/* ${lib.concatMapStringsSep " " (l: "${l.modRoot}/* ${l.staticLib}/*") (lib.reverseList stdlib)} ${libInit_shared}/* ${leanshared}/* $out/lib/lean/
+          ln -sf ${leancpp}/lib/lean/* ${lib.concatMapStringsSep " " (l: "${l.modRoot}/* ${l.staticLib}/*") (lib.reverseList extlib)} ${leanshared}/* $out/lib/lean/
           # put everything in a single final derivation so `IO.appDir` references work
-          cp ${lean}/bin/lean ${leanc}/bin/leanc ${Lake-Main.executable}/bin/lake $out/bin
+          cp ${lean}/bin/lean ${leanc}/bin/leanc $out/bin
           # NOTE: `lndir` will not override existing `bin/leanc`
           ${lndir}/bin/lndir -silent ${lean-bin-tools-unwrapped} $out
         '';
@@ -154,32 +140,32 @@ rec {
       cacheRoots = linkFarmFromDrvs "cacheRoots" [
         stage0 lean leanc lean-all iTree modDepsFiles depRoots Leanc.src
         # .o files are not a runtime dependency on macOS because of lack of thin archives
-        Lean.oTree Lake.oTree
+        Lean.oTree
       ];
       test = buildCMake {
         name = "lean-test-${desc}";
-        realSrc = lib.sourceByRegex src [ "src.*" "tests.*" ];
-        buildInputs = [ gmp perl git ];
+        realSrc = lib.sourceByRegex ../. [ "src.*" "tests.*" ];
+        buildInputs = [ gmp perl ];
         preConfigure = ''
           cd src
         '';
         extraCMakeFlags = [ "-DLLVM=OFF" ];
         postConfigure = ''
-          patchShebangs ../../tests ../lake
+          patchShebangs ../../tests
           rm -r bin lib include share
           ln -sf ${lean-all}/* .
         '';
         buildPhase = ''
-          ctest --output-on-failure -E 'leancomptest_(doc_example|foreign)' -j$NIX_BUILD_CORES
+          ctest --output-on-failure -E 'leancomptest_(doc_example|foreign)|laketest|leanpkgtest' -j$NIX_BUILD_CORES
         '';
         installPhase = ''
           touch $out
         '';
       };
       update-stage0 =
-        let cTree = symlinkJoin { name = "cs"; paths = [ Init.cTree Lean.cTree ]; }; in
+        let cTree = symlinkJoin { name = "cs"; paths = map (l: l.cTree) stdlib; }; in
         writeShellScriptBin "update-stage0" ''
-          CSRCS=${cTree} CP_C_PARAMS="--dereference --no-preserve=all" ${src + "/script/update-stage0"}
+          CSRCS=${cTree} CP_C_PARAMS="--dereference --no-preserve=all" ${../script/update-stage0}
         '';
       update-stage0-commit = writeShellScriptBin "update-stage0-commit" ''
         set -euo pipefail
@@ -194,11 +180,11 @@ rec {
       '';
       benchmarks =
         let
-          entries = attrNames (readDir (src + "/tests/bench"));
+          entries = attrNames (readDir ../tests/bench);
           leanFiles = map (n: elemAt n 0) (filter (n: n != null) (map (match "(.*)\.lean") entries));
         in lib.genAttrs leanFiles (n: (buildLeanPackage {
           name = n;
-          src = filterSource (e: _: baseNameOf e == "${n}.lean") (src + "/tests/bench");
+          src = filterSource (e: _: baseNameOf e == "${n}.lean") ../tests/bench;
         }).executable);
     };
   stage1 = stage { stage = 1; prevStage = stage0; self = stage1; };

nix/buildLeanPackage.nix

@@ -3,14 +3,14 @@
   runCommand, darwin, mkShell, ... }:
 let lean-final' = lean-final; in
 lib.makeOverridable (
-{ name, src, fullSrc ? src, srcPrefix ? "", srcPath ? "$PWD/${srcPrefix}",
+{ name, src, fullSrc ? src, srcPrefix ? "",
   # Lean dependencies. Each entry should be an output of buildLeanPackage.
   deps ? [ lean.Lean ],
   # Static library dependencies. Each derivation `static` should contain a static library in the directory `${static}`.
   staticLibDeps ? [],
   # Whether to wrap static library inputs in a -Wl,--start-group [...] -Wl,--end-group to ensure dependencies are resolved.
   groupStaticLibs ? false,
-  # Shared library dependencies included at interpretation with --load-dynlib and linked to. Each derivation `shared` should contain a
+  # Shared library dependencies included at interpretation with --load-dynlib and linked to. Each derivation `shared` should contain a 
   # shared library at the path `${shared}/${shared.libName or shared.name}` and a name to link to like `-l${shared.linkName or shared.name}`.
   # These libs are also linked to in packages that depend on this one.
   nativeSharedLibs ? [],
@@ -69,14 +69,12 @@ with builtins; let
     name = "${name}-depRoot";
     inherit deps;
     depRoots = map (drv: drv.LEAN_PATH) deps;
-
-    passAsFile = [ "deps" "depRoots" ];
     buildCommand = ''
       mkdir -p $out
-      for i in $(cat $depRootsPath); do
+      for i in $depRoots; do
         cp -dru --no-preserve=mode $i/. $out
       done
-      for i in $(cat $depsPath); do
+      for i in $deps; do
         cp -drsu --no-preserve=mode $i/. $out
       done
     '';
@@ -88,9 +86,9 @@ with builtins; let
   allNativeSharedLibs =
     lib.unique (lib.flatten (nativeSharedLibs ++ (map (dep: dep.allNativeSharedLibs or []) allExternalDeps)));
 
-  # A flattened list of all static library dependencies: this and every dep module's explicitly provided `staticLibDeps`,
+  # A flattened list of all static library dependencies: this and every dep module's explicitly provided `staticLibDeps`, 
   # plus every dep module itself: `dep.staticLib`
-  allStaticLibDeps =
+  allStaticLibDeps = 
     lib.unique (lib.flatten (staticLibDeps ++ (map (dep: [dep.staticLib] ++ dep.staticLibDeps or []) allExternalDeps)));
 
   pathOfSharedLib = dep: dep.libPath or "${dep}/${dep.libName or dep.name}";
@@ -158,7 +156,7 @@ with builtins; let
     buildCommand = ''
       dir=$(dirname $relpath)
       mkdir -p $dir $out/$dir $ilean/$dir $c/$dir
-      if [ -d $src ]; then cp -r $src/. .; else cp $src $leanPath; fi
+      if [ -d $src ]; then cp -r $src/. $dir/; else cp $src $leanPath; fi
       lean -o $out/$oleanPath -i $ilean/$ileanPath -c $c/$cPath $leanPath $leanFlags $leanPluginFlags $leanLoadDynlibFlags
     '';
   }) // {
@@ -210,6 +208,7 @@ with builtins; let
       loadDynlibPaths = map pathOfSharedLib (loadDynlibsOfDeps deps);
     }}'
   '';
+  makePrintPathsFor = deps: mods: printPaths deps // mapAttrs (_: mod: makePrintPathsFor (deps ++ [mod]) mods) mods;
   expandGlob = g:
     if typeOf g == "string" then [g]
     else if g.glob == "one" then [g.mod]
@@ -249,7 +248,7 @@ in rec {
     ${if stdenv.isDarwin then "-Wl,-force_load,${staticLib}/lib${libName}.a" else "-Wl,--whole-archive ${staticLib}/lib${libName}.a -Wl,--no-whole-archive"} \
     ${lib.concatStringsSep " " (map (d: "${d.sharedLib}/*") deps)}'';
   executable = lib.makeOverridable ({ withSharedStdlib ? true }: let
-      objPaths = map (drv: "${drv}/${drv.oPath}") (attrValues objects) ++ lib.optional withSharedStdlib "${lean-final.libInit_shared}/* ${lean-final.leanshared}/*";
+      objPaths = map (drv: "${drv}/${drv.oPath}") (attrValues objects) ++ lib.optional withSharedStdlib "${lean-final.leanshared}/*";
     in runCommand executableName { buildInputs = [ stdenv.cc leanc ]; } ''
       mkdir -p $out/bin
       leanc ${staticLibLinkWrapper (lib.concatStringsSep " " (objPaths ++ map (d: "${d}/*.a") allStaticLibDeps))} \
@@ -269,7 +268,6 @@ in rec {
     ln -sf ${iTree}/* $dest/build/lib
   '';
 
-  makePrintPathsFor = deps: mods: printPaths deps // mapAttrs (_: mod: makePrintPathsFor (deps ++ [mod]) mods) mods;
   print-paths = makePrintPathsFor [] (mods' // externalModMap);
   # `lean` wrapper that dynamically runs Nix for the actual `lean` executable so the same editor can be
   # used for multiple projects/after upgrading the `lean` input/for editing both stage 1 and the tests
@@ -297,7 +295,7 @@ in rec {
   devShell = mkShell {
     buildInputs = [ nix ];
     shellHook = ''
-      export LEAN_SRC_PATH="${srcPath}"
+      export LEAN_SRC_PATH="$PWD/${srcPrefix}"
     '';
   };
 })

nix/lake-dev.in

@@ -10,7 +10,7 @@ function pebkac() {
 [[ $# -gt 0 ]] || pebkac
 case $1 in
     --version)
-        # minimum version for `lake serve` with fallback
+        # minimum version for `lake server` with fallback
         echo 3.1.0
         ;;
     print-paths)

nix/packages.nix

@@ -1,11 +1,11 @@
-{ src, pkgs, nix, ... } @ args:
+{ pkgs, nix, ... } @ args:
 with pkgs;
 let
   nix-pinned = writeShellScriptBin "nix" ''
     ${nix.packages.${system}.default}/bin/nix --experimental-features 'nix-command flakes' --extra-substituters https://lean4.cachix.org/ --option warn-dirty false "$@"
   '';
   # https://github.com/NixOS/nixpkgs/issues/130963
-  llvmPackages = if stdenv.isDarwin then llvmPackages_11 else llvmPackages_15;
+  llvmPackages = if stdenv.isDarwin then llvmPackages_11 else llvmPackages_14;
   cc = (ccacheWrapper.override rec {
     cc = llvmPackages.clang;
     extraConfig = ''
@@ -29,7 +29,7 @@ let
   stdenv' = if stdenv.isLinux then useGoldLinker stdenv else stdenv;
   lean = callPackage (import ./bootstrap.nix) (args // {
     stdenv = overrideCC stdenv' cc;
-    inherit src buildLeanPackage llvmPackages;
+    inherit buildLeanPackage llvmPackages;
   });
   makeOverridableLeanPackage = f:
     let newF = origArgs: f origArgs // {
@@ -52,10 +52,7 @@ let
     src = args.lean4-mode;
     packageRequires = with pkgs.emacsPackages.melpaPackages; [ dash f flycheck magit-section lsp-mode s ];
     recipe = pkgs.writeText "recipe" ''
-      (lean4-mode
-       :repo "leanprover/lean4-mode"
-       :fetcher github
-       :files ("*.el" "data"))
+      (lean4-mode :repo "leanprover/lean4-mode" :fetcher github)
     '';
   };
   lean-emacs = emacsWithPackages [ lean4-mode ];

nix/templates/pkg/flake.nix

@@ -1,8 +1,8 @@
 {
   description = "My Lean package";
 
-  inputs.lean.url = "github:leanprover/lean4";
-  inputs.flake-utils.url = "github:numtide/flake-utils";
+  inputs.lean.url = github:leanprover/lean4;
+  inputs.flake-utils.url = github:numtide/flake-utils;
 
   outputs = { self, lean, flake-utils }: flake-utils.lib.eachDefaultSystem (system:
     let

script/apply.lean

@@ -1,8 +1,3 @@
-/-
-Copyright (c) 2022 Sebastian Ullrich. All rights reserved.
-Released under Apache 2.0 license as described in the file LICENSE.
-Authors: Sebastian Ullrich
--/
 import Lean.Runtime
 
 abbrev M := ReaderT IO.FS.Stream IO
@@ -21,7 +16,7 @@ def mkTypedefFn (i : Nat) : M Unit := do
   emit s!"typedef obj* (*fn{i})({args}); // NOLINT\n"
   emit s!"#define FN{i}(f) reinterpret_cast<fn{i}>(lean_closure_fun(f))\n"
 
-def genSeq (n : Nat) (f : Nat → String) (sep := ", ") : String :=
+def genSeq (n : Nat) (f : Nat → String) (sep := ", ") : String := 
   List.range n |>.map f |>.intersperse sep |> .join
 
 -- make string: "obj* a1, obj* a2, ..., obj* an"

script/gen_constants_cpp.py

@@ -7,7 +7,7 @@
 # Author: Leonardo de Moura
 #
 # Given a text file containing constants defined in the Lean libraries,
-# this script generates .h and .cpp files for initialing/finalizing these constants
+# this script generates .h and .cpp files for initialing/finalizing theses constants
 # as C++ name objects.
 #
 # This script is used to generate src/library/constants.cpp and src/library/constants.h

script/gen_tokens_cpp.py

@@ -7,7 +7,7 @@
 # Author: Leonardo de Moura
 #
 # Given a text file containing id and token strings,
-# this script generates .h and .cpp files for initialing/finalizing these tokens
+# this script generates .h and .cpp files for initialing/finalizing theses tokens
 # as C++ name objects.
 #
 # This script is used to generate src/frontends/lean/tokens.cpp and src/frontends/lean/tokens.h

script/prepare-llvm-linux.sh

@@ -25,8 +25,6 @@ cp -L llvm/bin/llvm-ar stage1/bin/
 # dependencies of the above
 $CP llvm/lib/lib{clang-cpp,LLVM}*.so* stage1/lib/
 $CP $ZLIB/lib/libz.so* stage1/lib/
-# general clang++ dependency, breaks cross-library C++ exceptions if linked statically
-$CP $GCC_LIB/lib/libgcc_s.so* stage1/lib/
 # bundle libatomic (referenced by LLVM >= 15, and required by the lean executable to run)
 $CP $GCC_LIB/lib/libatomic.so* stage1/lib/
 
@@ -50,6 +48,7 @@ $CP -r llvm/include/*-*-* llvm-host/include/
 $CP $GLIBC/lib/libc_nonshared.a stage1/lib/glibc
 for f in $GLIBC/lib/lib{c,dl,m,rt,pthread}-*; do b=$(basename $f); cp $f stage1/lib/glibc/${b%-*}.so; done
 OPTIONS=()
+echo -n " -DLLVM=ON -DLLVM_CONFIG=$PWD/llvm-host/bin/llvm-config" # manually point to `llvm-config` location
 echo -n " -DLEAN_STANDALONE=ON"
 echo -n " -DCMAKE_CXX_COMPILER=$PWD/llvm-host/bin/clang++ -DLEAN_CXX_STDLIB='-Wl,-Bstatic -lc++ -lc++abi -Wl,-Bdynamic'"
 echo -n " -DLEAN_EXTRA_CXX_FLAGS='--sysroot $PWD/llvm -idirafter $GLIBC_DEV/include ${EXTRA_FLAGS:-}'"
@@ -62,7 +61,7 @@ fi
 # use `-nostdinc` to make sure headers are not visible by default (in particular, not to `#include_next` in the clang headers),
 # but do not change sysroot so users can still link against system libs
 echo -n " -DLEANC_INTERNAL_FLAGS='-nostdinc -isystem ROOT/include/clang' -DLEANC_CC=ROOT/bin/clang"
-echo -n " -DLEANC_INTERNAL_LINKER_FLAGS='-L ROOT/lib -L ROOT/lib/glibc ROOT/lib/glibc/libc_nonshared.a -Wl,--as-needed -Wl,-Bstatic -lgmp -lunwind -Wl,-Bdynamic -Wl,--no-as-needed -fuse-ld=lld'"
+echo -n " -DLEANC_INTERNAL_LINKER_FLAGS='-L ROOT/lib -L ROOT/lib/glibc ROOT/lib/glibc/libc_nonshared.a -Wl,--as-needed -static-libgcc -Wl,-Bstatic -lgmp -lunwind -Wl,-Bdynamic -Wl,--no-as-needed -fuse-ld=lld'"
 # when not using the above flags, link GMP dynamically/as usual
 echo -n " -DLEAN_EXTRA_LINKER_FLAGS='-Wl,--as-needed -lgmp -Wl,--no-as-needed'"
 # do not set `LEAN_CC` for tests

script/prepare-llvm-macos.sh

@@ -34,11 +34,9 @@ $CP llvm/lib/clang/*/include/{std*,__std*,limits}.h stage1/include/clang
 (cd llvm; $CP --parents lib/clang/*/lib/*/libclang_rt.osx.a ../stage1)
 # libSystem stub, includes libc
 cp $SDK/usr/lib/libSystem.tbd stage1/lib/libc
-# use for linking, use system lib for running
-gcp llvm/lib/libc++.dylib stage1/lib/libc
-# make sure we search for the library in /usr/lib instead of the rpath, which should not contain `/usr/lib`
-# and apparently since Sonoma does not do so implicitly either
-install_name_tool -id /usr/lib/libc++.dylib stage1/lib/libc/libc++.dylib
+# use for linking, use system libs for running
+gcp llvm/lib/lib{c++,c++abi,unwind}.dylib stage1/lib/libc
+echo -n " -DLLVM=ON -DLLVM_CONFIG=$PWD/llvm-host/bin/llvm-config" # manually point to `llvm-config` location
 echo -n " -DLEAN_STANDALONE=ON"
 # do not change C++ compiler; libc++ etc. being system libraries means there's no danger of conflicts,
 # and the custom clang++ outputs a myriad of warnings when consuming the SDK

script/prepare-llvm-mingw.sh

@@ -32,6 +32,7 @@ cp /clang64/lib/{crtbegin,crtend,crt2,dllcrt2}.o stage1/lib/
 (cd llvm; cp --parents lib/clang/*/lib/*/libclang_rt.builtins* ../stage1)
 # further dependencies
 cp /clang64/lib/lib{m,bcrypt,mingw32,moldname,mingwex,msvcrt,pthread,advapi32,shell32,user32,kernel32,ucrtbase}.* /clang64/lib/libgmp.a llvm/lib/lib{c++,c++abi,unwind}.a stage1/lib/
+echo -n " -DLLVM=ON -DLLVM_CONFIG=$PWD/llvm/bin/llvm-config" # manually point to `llvm-config` location
 echo -n " -DLEAN_STANDALONE=ON"
 echo -n " -DCMAKE_C_COMPILER=$PWD/stage1/bin/clang.exe -DCMAKE_C_COMPILER_WORKS=1 -DCMAKE_CXX_COMPILER=$PWD/llvm/bin/clang++.exe -DCMAKE_CXX_COMPILER_WORKS=1 -DLEAN_CXX_STDLIB='-lc++ -lc++abi'"
 echo -n " -DSTAGE0_CMAKE_C_COMPILER=clang -DSTAGE0_CMAKE_CXX_COMPILER=clang++"

script/update-stage0

@@ -3,8 +3,8 @@ set -euo pipefail
 
 rm -r stage0 || true
 # don't copy untracked files
-# `:!` is git glob flavor for exclude patterns
-for f in $(git ls-files src ':!:src/lake/*' ':!:src/Leanc.lean'); do
+for f in $(git ls-files src); do
+    [[ $f != src/lake && $f != src/Leanc.lean ]] || continue
     if [[ $f == *.lean ]]; then
         f=${f#src/}
         f=${f%.lean}.c

shell.nix

@@ -9,7 +9,7 @@ in { pkgs ? flakePkgs.nixpkgs, pkgsDist ? pkgs }:
   } (rec {
     buildInputs = with pkgs; [
       cmake gmp ccache
-      flakePkgs.llvmPackages.llvm  # llvm-symbolizer for asan/lsan
+      llvmPackages.llvm  # llvm-symbolizer for asan/lsan
     ];
     # https://github.com/NixOS/nixpkgs/issues/60919
     hardeningDisable = [ "all" ];

src/CMakeLists.txt

@@ -9,7 +9,7 @@ endif()
 include(ExternalProject)
 project(LEAN CXX C)
 set(LEAN_VERSION_MAJOR 4)
-set(LEAN_VERSION_MINOR 7)
+set(LEAN_VERSION_MINOR 0)
 set(LEAN_VERSION_PATCH 0)
 set(LEAN_VERSION_IS_RELEASE 0)  # This number is 1 in the release revision, and 0 otherwise.
 set(LEAN_SPECIAL_VERSION_DESC "" CACHE STRING "Additional version description like 'nightly-2018-03-11'")
@@ -18,14 +18,6 @@ if (LEAN_SPECIAL_VERSION_DESC)
   string(APPEND LEAN_VERSION_STRING "-${LEAN_SPECIAL_VERSION_DESC}")
 endif()
 
-set(LEAN_PLATFORM_TARGET "" CACHE STRING "LLVM triple of the target platform")
-if (NOT LEAN_PLATFORM_TARGET)
-  # this may fail when the compiler is not clang, but this should only happen in local builds where
-  # the value of the variable is not of immediate relevance
-  execute_process(COMMAND ${CMAKE_C_COMPILER} --print-target-triple
-    OUTPUT_VARIABLE LEAN_PLATFORM_TARGET OUTPUT_STRIP_TRAILING_WHITESPACE)
-endif()
-
 set(LEAN_EXTRA_LINKER_FLAGS "" CACHE STRING "Additional flags used by the linker")
 set(LEAN_EXTRA_CXX_FLAGS "" CACHE STRING "Additional flags used by the C++ compiler")
 set(LEAN_TEST_VARS "LEAN_CC=${CMAKE_C_COMPILER}" CACHE STRING "Additional environment variables used when running tests")
@@ -65,17 +57,16 @@ option(CUSTOM_ALLOCATORS   "CUSTOM_ALLOCATORS" ON)
 option(SAVE_SNAPSHOT       "SAVE_SNAPSHOT" ON)
 option(SAVE_INFO           "SAVE_INFO" ON)
 option(SMALL_ALLOCATOR     "SMALL_ALLOCATOR" ON)
-option(MMAP                "MMAP" ON)
 option(LAZY_RC             "LAZY_RC" OFF)
 option(RUNTIME_STATS       "RUNTIME_STATS" OFF)
 option(BSYMBOLIC "Link with -Bsymbolic to reduce call overhead in shared libraries (Linux)" ON)
 option(USE_GMP "USE_GMP" ON)
 
 # development-specific options
-option(CHECK_OLEAN_VERSION "Only load .olean files compiled with the current version of Lean" OFF)
+option(CHECK_OLEAN_VERSION "Only load .olean files compiled with the current version of Lean" ON)
 
 set(LEAN_EXTRA_MAKE_OPTS  ""                           CACHE STRING "extra options to lean --make")
-set(LEANC_CC              ${CMAKE_C_COMPILER}          CACHE STRING "C compiler to use in `leanc`")
+set(LEANC_CC              "cc"                         CACHE STRING "C compiler to use in `leanc`")
 
 if ("${LAZY_RC}" MATCHES "ON")
   set(LEAN_LAZY_RC "#define LEAN_LAZY_RC")
@@ -93,33 +84,38 @@ else()
   set(NumBits 32)
 endif()
 
-if ("${MMAP}" MATCHES "ON")
-  string(APPEND LEAN_EXTRA_CXX_FLAGS " -D LEAN_MMAP")
-endif()
-
 if ("${RUNTIME_STATS}" MATCHES "ON")
   string(APPEND LEAN_EXTRA_CXX_FLAGS " -D LEAN_RUNTIME_STATS")
 endif()
 
-if ("${CHECK_OLEAN_VERSION}" MATCHES "ON")
-  set(USE_GITHASH ON)
-  string(APPEND LEAN_EXTRA_CXX_FLAGS " -D LEAN_CHECK_OLEAN_VERSION")
+if (NOT("${CHECK_OLEAN_VERSION}" MATCHES "ON"))
+  string(APPEND LEAN_EXTRA_CXX_FLAGS " -D LEAN_IGNORE_OLEAN_VERSION")
 endif()
 
 if(${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
+    set(MULTI_THREAD OFF)
     # TODO(WN): code size/performance tradeoffs
     # - we're using -O3; it's /okay/
+    # - -flto crashes at runtime
     # - -Oz produces quite slow code
     # - system libraries such as OpenGL are included in the JS but shouldn't be
     # - we need EMSCRIPTEN_KEEPALIVE annotations on exports to run meta-dce (-s MAIN_MODULE=2)
+    # - -fexceptions is a slow JS blob, remove when more runtimes support the WASM exceptions spec
 
     # From https://emscripten.org/docs/compiling/WebAssembly.html#backends:
     # > The simple and safe thing is to pass all -s flags at both compile and link time.
-    set(EMSCRIPTEN_SETTINGS "-s ALLOW_MEMORY_GROWTH=1 -fwasm-exceptions -pthread -flto")
-    string(APPEND LEANC_EXTRA_FLAGS " -pthread")
+    set(EMSCRIPTEN_SETTINGS "-s ALLOW_MEMORY_GROWTH=1 -s DISABLE_EXCEPTION_CATCHING=0 -s MAIN_MODULE=1 -fexceptions")
     string(APPEND LEAN_EXTRA_CXX_FLAGS " -D LEAN_EMSCRIPTEN ${EMSCRIPTEN_SETTINGS}")
     string(APPEND LEAN_EXTRA_LINKER_FLAGS " ${EMSCRIPTEN_SETTINGS}")
 endif()
+if (CMAKE_CROSSCOMPILING_EMULATOR)
+  # emscripten likes to quote "node"
+  string(REPLACE "\"" "" CMAKE_CROSSCOMPILING_EMULATOR ${CMAKE_CROSSCOMPILING_EMULATOR})
+  # HACK(WN): lazy compilation makes Node.js startup time a bad but tolerable ~4s
+  string(APPEND CMAKE_CROSSCOMPILING_EMULATOR " --wasm-lazy-compilation")
+else()
+  set(CMAKE_CROSSCOMPILING_EMULATOR)
+endif()
 
 # Added for CTest
 include(CTest)
@@ -147,7 +143,7 @@ set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/lib/lean")
 
 # OSX default thread stack size is very small. Moreover, in Debug mode, each new stack frame consumes a lot of extra memory.
 if ((${MULTI_THREAD} MATCHES "ON") AND (${CMAKE_SYSTEM_NAME} MATCHES "Darwin"))
-  string(APPEND LEAN_EXTRA_MAKE_OPTS " -s40000")
+  set(LEAN_EXTRA_MAKE_OPTS -s40000 ${LEAN_EXTRA_MAKE_OPTS})
 endif ()
 
 # We want explicit stack probes in huge Lean stack frames for robust stack overflow detection
@@ -297,13 +293,13 @@ if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
     find_package(ZLIB REQUIRED)
     message(STATUS "ZLIB_LIBRARY: ${ZLIB_LIBRARY}")
     cmake_path(GET ZLIB_LIBRARY PARENT_PATH ZLIB_LIBRARY_PARENT_PATH)
-    string(APPEND LEANSHARED_LINKER_FLAGS " -L ${ZLIB_LIBRARY_PARENT_PATH}")
+    string(APPEND LEAN_EXTRA_LINKER_FLAGS " -L ${ZLIB_LIBRARY_PARENT_PATH}")
   endif()
-  string(APPEND TOOLCHAIN_STATIC_LINKER_FLAGS " -lleancpp -lInit -lLean -lleanrt")
+  string(APPEND LEANC_STATIC_LINKER_FLAGS " -lleancpp -lInit -lLean -lleanrt")
 elseif(${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
-  string(APPEND TOOLCHAIN_STATIC_LINKER_FLAGS " -lleancpp -lInit -lLean -lnodefs.js -lleanrt")
+  string(APPEND LEANC_STATIC_LINKER_FLAGS " -lleancpp -lInit -lLean -lnodefs.js -lleanrt")
 else()
-  string(APPEND TOOLCHAIN_STATIC_LINKER_FLAGS " -Wl,--start-group -lleancpp -lLean -Wl,--end-group -Wl,--start-group -lInit -lleanrt -Wl,--end-group")
+  string(APPEND LEANC_STATIC_LINKER_FLAGS " -Wl,--start-group -lleancpp -lLean -Wl,--end-group -Wl,--start-group -lInit -lleanrt -Wl,--end-group")
 endif()
 
 set(LEAN_CXX_STDLIB "-lstdc++" CACHE STRING "C++ stdlib linker flags")
@@ -312,41 +308,35 @@ if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
   set(LEAN_CXX_STDLIB "-lc++")
 endif()
 
-string(APPEND TOOLCHAIN_STATIC_LINKER_FLAGS " ${LEAN_CXX_STDLIB}")
-string(APPEND TOOLCHAIN_SHARED_LINKER_FLAGS " ${LEAN_CXX_STDLIB}")
+string(APPEND LEANC_STATIC_LINKER_FLAGS " ${LEAN_CXX_STDLIB}")
+string(APPEND LEANSHARED_LINKER_FLAGS " ${LEAN_CXX_STDLIB}")
 
-# flags for user binaries = flags for toolchain binaries + Lake
-string(APPEND LEANC_STATIC_LINKER_FLAGS " ${TOOLCHAIN_STATIC_LINKER_FLAGS} -lLake")
-
-if (LLVM)
-  string(APPEND LEANSHARED_LINKER_FLAGS " -L${LLVM_CONFIG_LIBDIR} ${LLVM_CONFIG_LDFLAGS} ${LLVM_CONFIG_LIBS} ${LLVM_CONFIG_SYSTEM_LIBS}")
-  string(APPEND CMAKE_CXX_FLAGS " -I${LLVM_CONFIG_INCLUDEDIR}")
-endif()
-
-if(LLVM AND ${STAGE} GREATER 0)
+if(LLVM)
     # Here, we perform a replacement of `llvm-host` with `llvm`. This is necessary for our cross-compile
-    #   builds in `script/prepare-llvm-*.sh`.
+    #   builds in `script/prepare-llvm-*.sh`. 
     # - Recall that the host's copy of LLVM binaries and libraries is at
     #   `llvm-host`, and the target's copy of LLVM binaries and libraries is at
     #   `llvm`.
-    # - In an ideal world, we would run the target's `llvm/bin/llvm-config` and get the correct link options for the target
+    # - In an ideal world, we would run the target's `llvm/bin/llvm-config` and get the corrct link options for the target 
     #   (e.g. `-Lllvm/lib/libLLVM`.)
     # - However, the target's `llvm/bin/llvm-config` has a different target
     #   triple from the host, and thus cannot be run on the host.
     # - So, we run the host `llvm-host/bin/llvm-config` from which we pick up
     #   compiler options, and change the output of the host to point to the target.
-    # - In particular, `host/bin/llvm-config` produces flags like `-Lllvm-host/lib/libLLVM`, while
+    # - In particular, `host/bin/llvm-config` produces flags like `-Lllvm-host/lib/libLLVM`, while 
     #   we need the path to be `-Lllvm/lib/libLLVM`. Thus, we perform this replacement here.
+    string(APPEND LEANSHARED_LINKER_FLAGS " -L${LLVM_CONFIG_LIBDIR} ${LLVM_CONFIG_LDFLAGS} ${LLVM_CONFIG_LIBS} ${LLVM_CONFIG_SYSTEM_LIBS}")
     string(REPLACE "llvm-host" "llvm" LEANSHARED_LINKER_FLAGS ${LEANSHARED_LINKER_FLAGS})
+    string(APPEND CMAKE_CXX_FLAGS  " -I${LLVM_CONFIG_INCLUDEDIR}")
     string(REPLACE "llvm-host" "llvm" LEAN_EXTRA_CXX_FLAGS ${LEAN_EXTRA_CXX_FLAGS})
     message(VERBOSE "leanshared linker flags: '${LEANSHARED_LINKER_FLAGS}' | lean extra cxx flags '${LEAN_EXTR_CXX_FLAGS}'")
 endif()
 
 # get rid of unused parts of C++ stdlib
 if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
-  string(APPEND TOOLCHAIN_SHARED_LINKER_FLAGS " -Wl,-dead_strip")
-elseif(NOT ${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
-  string(APPEND TOOLCHAIN_SHARED_LINKER_FLAGS " -Wl,--gc-sections")
+  string(APPEND LEANSHARED_LINKER_FLAGS " -Wl,-dead_strip")
+else()
+  string(APPEND LEANSHARED_LINKER_FLAGS " -Wl,--gc-sections")
 endif()
 
 if(NOT ${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
@@ -356,27 +346,23 @@ endif()
 if(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
   if(BSYMBOLIC)
     string(APPEND LEANC_SHARED_LINKER_FLAGS " -Wl,-Bsymbolic")
-    string(APPEND TOOLCHAIN_SHARED_LINKER_FLAGS " -Wl,-Bsymbolic")
+    string(APPEND LEANSHARED_LINKER_FLAGS " -Wl,-Bsymbolic")
   endif()
   string(APPEND CMAKE_CXX_FLAGS " -fPIC -ftls-model=initial-exec")
   string(APPEND LEANC_EXTRA_FLAGS " -fPIC")
-  string(APPEND TOOLCHAIN_SHARED_LINKER_FLAGS " -Wl,-rpath=\\$$ORIGIN/..:\\$$ORIGIN")
+  string(APPEND LEANSHARED_LINKER_FLAGS " -Wl,-rpath=\\$$ORIGIN/..:\\$$ORIGIN")
   string(APPEND CMAKE_EXE_LINKER_FLAGS " -Wl,-rpath=\\\$ORIGIN/../lib:\\\$ORIGIN/../lib/lean")
 elseif(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
   string(APPEND CMAKE_CXX_FLAGS " -ftls-model=initial-exec")
-  string(APPEND INIT_SHARED_LINKER_FLAGS " -install_name @rpath/libInit_shared.dylib")
   string(APPEND LEANSHARED_LINKER_FLAGS " -install_name @rpath/libleanshared.dylib")
   string(APPEND CMAKE_EXE_LINKER_FLAGS " -Wl,-rpath,@executable_path/../lib -Wl,-rpath,@executable_path/../lib/lean")
-elseif(${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
-  string(APPEND CMAKE_CXX_FLAGS " -fPIC")
-  string(APPEND LEANC_EXTRA_FLAGS " -fPIC")
 endif()
 
 if(${CMAKE_SYSTEM_NAME} MATCHES "Linux")
   string(APPEND LEAN_EXTRA_LINKER_FLAGS " -ldl")
 endif()
 
-if(NOT(${CMAKE_SYSTEM_NAME} MATCHES "Windows") AND NOT(${CMAKE_SYSTEM_NAME} MATCHES "Emscripten"))
+if(NOT(${CMAKE_SYSTEM_NAME} MATCHES "Windows"))
   # export symbols for the interpreter (done via `LEAN_EXPORT` for Windows)
   string(APPEND LEAN_DYN_EXE_LINKER_FLAGS " -rdynamic")
   string(APPEND CMAKE_EXE_LINKER_FLAGS " -rdynamic")
@@ -395,7 +381,7 @@ endif()
 # are already loaded) and probably fail unless we set up LD_LIBRARY_PATH.
 if(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
   # import library created by the `leanshared` target
-  string(APPEND LEANC_SHARED_LINKER_FLAGS " -lInit_shared -lleanshared")
+  string(APPEND LEANC_SHARED_LINKER_FLAGS " -lleanshared")
 elseif("${CMAKE_SYSTEM_NAME}" MATCHES "Darwin")
   string(APPEND LEANC_SHARED_LINKER_FLAGS " -Wl,-undefined,dynamic_lookup")
 endif()
@@ -406,17 +392,26 @@ if(MULTI_THREAD AND NOT MSVC AND (NOT ("${CMAKE_SYSTEM_NAME}" MATCHES "Darwin"))
 endif()
 
 # Git HASH
+set(LEAN_PACKAGE_VERSION "NOT-FOUND")
 if(USE_GITHASH)
   include(GetGitRevisionDescription)
   get_git_head_revision(GIT_REFSPEC GIT_SHA1)
   if(${GIT_SHA1} MATCHES "GITDIR-NOTFOUND")
     message(STATUS "Failed to read git_sha1")
     set(GIT_SHA1 "")
+    if(EXISTS "${LEAN_SOURCE_DIR}/bin/package_version")
+      file(STRINGS "${LEAN_SOURCE_DIR}/bin/package_version" LEAN_PACKAGE_VERSION)
+      message(STATUS "Package version detected: ${LEAN_PACKAGE_VERSION}")
+    endif()
   else()
     message(STATUS "git commit sha1: ${GIT_SHA1}")
   endif()
 else()
   set(GIT_SHA1 "")
+  if(EXISTS "${LEAN_SOURCE_DIR}/bin/package_version")
+    file(STRINGS "${LEAN_SOURCE_DIR}/bin/package_version" LEAN_PACKAGE_VERSION)
+    message(STATUS "Package version detected: ${LEAN_PACKAGE_VERSION}")
+  endif()
 endif()
 configure_file("${LEAN_SOURCE_DIR}/githash.h.in" "${LEAN_BINARY_DIR}/githash.h")
 
@@ -443,13 +438,15 @@ include_directories(${LEAN_SOURCE_DIR})
 include_directories(${CMAKE_BINARY_DIR})  # version.h etc., "private" headers
 include_directories(${CMAKE_BINARY_DIR}/include)  # config.h etc., "public" headers
 
-# Use CMake profile C++ flags for building Lean libraries, but do not embed in `leanc`
 string(TOUPPER "${CMAKE_BUILD_TYPE}" uppercase_CMAKE_BUILD_TYPE)
+# These are used in lean.mk (and libleanrt) and passed through by stdlib.make
+# They are not embedded into `leanc` since they are build profile/machine specific
 string(APPEND LEANC_OPTS " ${CMAKE_CXX_FLAGS_${uppercase_CMAKE_BUILD_TYPE}}")
-
-# Do embed flag for finding system libraries in dev builds
 if(CMAKE_OSX_SYSROOT AND NOT LEAN_STANDALONE)
-  string(APPEND LEANC_EXTRA_FLAGS " ${CMAKE_CXX_SYSROOT_FLAG}${CMAKE_OSX_SYSROOT}")
+  string(APPEND LEANC_OPTS " ${CMAKE_CXX_SYSROOT_FLAG}${CMAKE_OSX_SYSROOT}")
+endif()
+if(CMAKE_OSX_DEPLOYMENT_TARGET)
+  string(APPEND LEANC_OPTS " ${CMAKE_CXX_OSX_DEPLOYMENT_TARGET_FLAG}${CMAKE_OSX_DEPLOYMENT_TARGET}")
 endif()
 
 if(${STAGE} GREATER 1)
@@ -502,38 +499,18 @@ string(REGEX REPLACE "^([a-zA-Z]):" "/\\1" LEAN_BIN "${CMAKE_BINARY_DIR}/bin")
 file(RELATIVE_PATH LIB ${LEAN_SOURCE_DIR} ${CMAKE_BINARY_DIR}/lib)
 
 if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
-  string(APPEND INIT_SHARED_LINKER_FLAGS " -Wl,-force_load,${CMAKE_BINARY_DIR}/lib/lean/libInit.a -Wl,-force_load,${CMAKE_BINARY_DIR}/runtime/libleanrt_initial-exec.a")
+  set(LEANSHARED_LINKER_FLAGS "-Wl,-force_load,${CMAKE_BINARY_DIR}/lib/lean/libInit.a -Wl,-force_load,${CMAKE_BINARY_DIR}/lib/lean/libLean.a -Wl,-force_load,${CMAKE_BINARY_DIR}/lib/lean/libleancpp.a ${CMAKE_BINARY_DIR}/runtime/libleanrt_initial-exec.a ${LEANSHARED_LINKER_FLAGS}")
 else()
-  string(APPEND INIT_SHARED_LINKER_FLAGS " -Wl,--whole-archive -lInit ${CMAKE_BINARY_DIR}/runtime/libleanrt_initial-exec.a -Wl,--no-whole-archive")
-  if(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
-    string(APPEND INIT_SHARED_LINKER_FLAGS " -Wl,--out-implib,${CMAKE_BINARY_DIR}/lib/lean/libInit_shared.dll.a")
-  endif()
-endif()
-
-if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
-  string(APPEND LEANSHARED_LINKER_FLAGS " -Wl,-force_load,${CMAKE_BINARY_DIR}/lib/lean/libLean.a -Wl,-force_load,${CMAKE_BINARY_DIR}/lib/lean/libleancpp.a")
-else()
-  string(APPEND LEANSHARED_LINKER_FLAGS " -Wl,--whole-archive -lLean -lleancpp -Wl,--no-whole-archive")
+  set(LEANSHARED_LINKER_FLAGS "-Wl,--whole-archive -lInit -lLean -lleancpp -Wl,--no-whole-archive ${CMAKE_BINARY_DIR}/runtime/libleanrt_initial-exec.a ${LEANSHARED_LINKER_FLAGS}")
   if(${CMAKE_SYSTEM_NAME} MATCHES "Windows")
     string(APPEND LEANSHARED_LINKER_FLAGS " -Wl,--out-implib,${CMAKE_BINARY_DIR}/lib/lean/libleanshared.dll.a")
   endif()
 endif()
-string(APPEND LEANSHARED_LINKER_FLAGS " -lInit_shared")
-
-if (${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
-  # We do not use dynamic linking via leanshared for Emscripten to keep things
-  # simple. (And we are not interested in `Lake` anyway.) To use dynamic
-  # linking, we would probably have to set MAIN_MODULE=2 on `leanshared`,
-  # SIDE_MODULE=2 on `lean`, and set CMAKE_SHARED_LIBRARY_SUFFIX to ".js".
-  string(APPEND LEAN_EXE_LINKER_FLAGS " ${TOOLCHAIN_STATIC_LINKER_FLAGS} ${EMSCRIPTEN_SETTINGS} -lnodefs.js -s EXIT_RUNTIME=1 -s MAIN_MODULE=1 -s LINKABLE=1 -s EXPORT_ALL=1")
-endif()
-
-# Build the compiler using the bootstrapped C sources for stage0, and use
-# the LLVM build for stage1 and further.
-if (LLVM AND ${STAGE} GREATER 0)
-  set(EXTRA_LEANMAKE_OPTS "LLVM=1")
-endif()
 
+# Escape for `make`. Yes, twice.
+string(REPLACE "$" "$$" CMAKE_EXE_LINKER_FLAGS_MAKE "${CMAKE_EXE_LINKER_FLAGS}")
+string(REPLACE "$" "$$" CMAKE_EXE_LINKER_FLAGS_MAKE_MAKE "${CMAKE_EXE_LINKER_FLAGS_MAKE}")
+configure_file(${LEAN_SOURCE_DIR}/stdlib.make.in ${CMAKE_BINARY_DIR}/stdlib.make)
 add_custom_target(make_stdlib ALL
   WORKING_DIRECTORY ${LEAN_SOURCE_DIR}
   # The actual rule is in a separate makefile because we want to prefix it with '+' to use the Make job server
@@ -542,42 +519,16 @@ add_custom_target(make_stdlib ALL
   COMMAND $(MAKE) -f ${CMAKE_BINARY_DIR}/stdlib.make Init Lean
   VERBATIM)
 
-# if we have LLVM enabled, then build `lean.h.bc` which has the LLVM bitcode
-# of Lean runtime to be built.
-if (LLVM AND ${STAGE} EQUAL 1)
-   add_dependencies(make_stdlib runtime_bc)
-endif()
-
 # We declare these as separate custom targets so they use separate `make` invocations, which makes `make` recompute which dependencies
 # (e.g. `libLean.a`) are now newer than the target file
 
-if(${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
-  # dummy targets, see `MAIN_MODULE` discussion above
-  add_custom_target(Init_shared ALL
-    DEPENDS make_stdlib leanrt_initial-exec
-    COMMAND touch ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libInit_shared${CMAKE_SHARED_LIBRARY_SUFFIX}
-  )
-  add_custom_target(leanshared ALL
-    DEPENDS Init_shared leancpp
-    COMMAND touch ${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libleanshared${CMAKE_SHARED_LIBRARY_SUFFIX}
-  )
-else()
-  add_custom_target(Init_shared ALL
-    WORKING_DIRECTORY ${LEAN_SOURCE_DIR}
-    DEPENDS make_stdlib leanrt_initial-exec
-    COMMAND $(MAKE) -f ${CMAKE_BINARY_DIR}/stdlib.make Init_shared
-    VERBATIM)
+add_custom_target(leanshared ALL
+  WORKING_DIRECTORY ${LEAN_SOURCE_DIR}
+  DEPENDS make_stdlib leancpp leanrt_initial-exec
+  COMMAND $(MAKE) -f ${CMAKE_BINARY_DIR}/stdlib.make leanshared
+  VERBATIM)
 
-  add_custom_target(leanshared ALL
-    WORKING_DIRECTORY ${LEAN_SOURCE_DIR}
-    DEPENDS Init_shared leancpp
-    COMMAND $(MAKE) -f ${CMAKE_BINARY_DIR}/stdlib.make leanshared
-    VERBATIM)
-
-  string(APPEND CMAKE_EXE_LINKER_FLAGS " -lInit_shared -lleanshared")
-endif()
-
-if(${STAGE} GREATER 0 AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
+if(${STAGE} GREATER 0)
   if(NOT EXISTS ${LEAN_SOURCE_DIR}/lake/Lake.lean)
     message(FATAL_ERROR "src/lake does not exist. Please check out the Lake submodule using `git submodule update --init src/lake`.")
   endif()
@@ -598,7 +549,7 @@ endif()
 
 # use Bash version for building, use Lean version in bin/ for tests & distribution
 configure_file("${LEAN_SOURCE_DIR}/bin/leanc.in" "${CMAKE_BINARY_DIR}/leanc.sh" @ONLY)
-if(${STAGE} GREATER 0 AND EXISTS ${LEAN_SOURCE_DIR}/Leanc.lean AND NOT ${CMAKE_SYSTEM_NAME} MATCHES "Emscripten")
+if(${STAGE} GREATER 0 AND EXISTS ${LEAN_SOURCE_DIR}/Leanc.lean)
   configure_file("${LEAN_SOURCE_DIR}/Leanc.lean" "${CMAKE_BINARY_DIR}/leanc/Leanc.lean" @ONLY)
   add_custom_target(leanc ALL
     WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/leanc
@@ -649,8 +600,3 @@ if(LEAN_INSTALL_PREFIX)
   set(LEAN_INSTALL_SUFFIX "-${LOWER_SYSTEM_NAME}" CACHE STRING "If LEAN_INSTALL_PREFIX is set, append this value to CMAKE_INSTALL_PREFIX")
   set(CMAKE_INSTALL_PREFIX "${LEAN_INSTALL_PREFIX}/lean-${LEAN_VERSION_STRING}${LEAN_INSTALL_SUFFIX}")
 endif()
-
-# Escape for `make`. Yes, twice.
-string(REPLACE "$" "$$" CMAKE_EXE_LINKER_FLAGS_MAKE "${CMAKE_EXE_LINKER_FLAGS}")
-string(REPLACE "$" "$$" CMAKE_EXE_LINKER_FLAGS_MAKE_MAKE "${CMAKE_EXE_LINKER_FLAGS_MAKE}")
-configure_file(${LEAN_SOURCE_DIR}/stdlib.make.in ${CMAKE_BINARY_DIR}/stdlib.make)

src/Init.lean

@@ -7,9 +7,6 @@ prelude
 import Init.Prelude
 import Init.Notation
 import Init.Tactics
-import Init.TacticsExtra
-import Init.ByCases
-import Init.RCases
 import Init.Core
 import Init.Control
 import Init.Data.Basic
@@ -20,16 +17,9 @@ import Init.System
 import Init.Util
 import Init.Dynamic
 import Init.ShareCommon
-import Init.MetaTypes
 import Init.Meta
 import Init.NotationExtra
 import Init.SimpLemmas
-import Init.PropLemmas
 import Init.Hints
 import Init.Conv
-import Init.Guard
-import Init.Simproc
 import Init.SizeOfLemmas
-import Init.BinderPredicates
-import Init.Ext
-import Init.Omega

src/Init/BinderPredicates.lean

@@ -1,82 +0,0 @@
-/-
-Copyright (c) 2021 Microsoft Corporation. All rights reserved.
-Released under Apache 2.0 license as described in the file LICENSE.
-Authors: Gabriel Ebner
--/
-prelude
-import Init.NotationExtra
-
-namespace Lean
-
-/--
-The syntax category of binder predicates contains predicates like `> 0`, `∈ s`, etc.
-(`: t` should not be a binder predicate because it would clash with the built-in syntax for ∀/∃.)
--/
-declare_syntax_cat binderPred
-
-/--
-`satisfies_binder_pred% t pred` expands to a proposition expressing that `t` satisfies `pred`.
--/
-syntax "satisfies_binder_pred% " term:max binderPred : term
-
--- Extend ∀ and ∃ to binder predicates.
-
-/--
-The notation `∃ x < 2, p x` is shorthand for `∃ x, x < 2 ∧ p x`,
-and similarly for other binary operators.
--/
-syntax "∃ " binderIdent binderPred ", " term : term
-/--
-The notation `∀ x < 2, p x` is shorthand for `∀ x, x < 2 → p x`,
-and similarly for other binary operators.
--/
-syntax "∀ " binderIdent binderPred ", " term : term
-
-macro_rules
-  | `(∃ $x:ident $pred:binderPred, $p) =>
-    `(∃ $x:ident, satisfies_binder_pred% $x $pred ∧ $p)
-  | `(∃ _ $pred:binderPred, $p) =>
-    `(∃ x, satisfies_binder_pred% x $pred ∧ $p)
-
-macro_rules
-  | `(∀ $x:ident $pred:binderPred, $p) =>
-    `(∀ $x:ident, satisfies_binder_pred% $x $pred → $p)
-  | `(∀ _ $pred:binderPred, $p) =>
-    `(∀ x, satisfies_binder_pred% x $pred → $p)
-
-/-- Declare `∃ x > y, ...` as syntax for `∃ x, x > y ∧ ...` -/
-binder_predicate x " > " y:term => `($x > $y)
-/-- Declare `∃ x ≥ y, ...` as syntax for `∃ x, x ≥ y ∧ ...` -/
-binder_predicate x " ≥ " y:term => `($x ≥ $y)
-/-- Declare `∃ x < y, ...` as syntax for `∃ x, x < y ∧ ...` -/
-binder_predicate x " < " y:term => `($x < $y)
-/-- Declare `∃ x ≤ y, ...` as syntax for `∃ x, x ≤ y ∧ ...` -/
-binder_predicate x " ≤ " y:term => `($x ≤ $y)
-/-- Declare `∃ x ≠ y, ...` as syntax for `∃ x, x ≠ y ∧ ...` -/
-binder_predicate x " ≠ " y:term => `($x ≠ $y)
-
-/-- Declare `∀ x ∈ y, ...` as syntax for `∀ x, x ∈ y → ...` and `∃ x ∈ y, ...` as syntax for
-`∃ x, x ∈ y ∧ ...` -/
-binder_predicate x " ∈ " y:term => `($x ∈ $y)
-
-/-- Declare `∀ x ∉ y, ...` as syntax for `∀ x, x ∉ y → ...` and `∃ x ∉ y, ...` as syntax for
-`∃ x, x ∉ y ∧ ...` -/
-binder_predicate x " ∉ " y:term => `($x ∉ $y)
-
-/-- Declare `∀ x ⊆ y, ...` as syntax for `∀ x, x ⊆ y → ...` and `∃ x ⊆ y, ...` as syntax for
-`∃ x, x ⊆ y ∧ ...` -/
-binder_predicate x " ⊆ " y:term => `($x ⊆ $y)
-
-/-- Declare `∀ x ⊂ y, ...` as syntax for `∀ x, x ⊂ y → ...` and `∃ x ⊂ y, ...` as syntax for
-`∃ x, x ⊂ y ∧ ...` -/
-binder_predicate x " ⊂ " y:term => `($x ⊂ $y)
-
-/-- Declare `∀ x ⊇ y, ...` as syntax for `∀ x, x ⊇ y → ...` and `∃ x ⊇ y, ...` as syntax for
-`∃ x, x ⊇ y ∧ ...` -/
-binder_predicate x " ⊇ " y:term => `($x ⊇ $y)
-
-/-- Declare `∀ x ⊃ y, ...` as syntax for `∀ x, x ⊃ y → ...` and `∃ x ⊃ y, ...` as syntax for
-`∃ x, x ⊃ y ∧ ...` -/
-binder_predicate x " ⊃ " y:term => `($x ⊃ $y)
-
-end Lean

src/Init/ByCases.lean

@@ -1,74 +0,0 @@
-/-
-Copyright (c) 2024 Lean FRO, LLC. All rights reserved.
-Released under Apache 2.0 license as described in the file LICENSE.
-Authors: Leonardo de Moura, Mario Carneiro
--/
-prelude
-import Init.Classical
-
-/-! # by_cases tactic and if-then-else support -/
-
-/--
-`by_cases (h :)? p` splits the main goal into two cases, assuming `h : p` in the first branch, and `h : ¬ p` in the second branch.
--/
-syntax "by_cases " (atomic(ident " : "))? term : tactic
-
-macro_rules
-  | `(tactic| by_cases $e) => `(tactic| by_cases h : $e)
-macro_rules
-  | `(tactic| by_cases $h : $e) =>
-    `(tactic| open Classical in refine if $h:ident : $e then ?pos else ?neg)
-
-/-! ## if-then-else -/
-
-@[simp] theorem if_true {h : Decidable True} (t e : α) : ite True t e = t := if_pos trivial
-
-@[simp] theorem if_false {h : Decidable False} (t e : α) : ite False t e = e := if_neg id
-
-theorem ite_id [Decidable c] {α} (t : α) : (if c then t else t) = t := by split <;> rfl
-
-/-- A function applied to a `dite` is a `dite` of that function applied to each of the branches. -/
-theorem apply_dite (f : α → β) (P : Prop) [Decidable P] (x : P → α) (y : ¬P → α) :
-    f (dite P x y) = dite P (fun h => f (x h)) (fun h => f (y h)) := by
-  by_cases h : P <;> simp [h]
-
-/-- A function applied to a `ite` is a `ite` of that function applied to each of the branches. -/
-theorem apply_ite (f : α → β) (P : Prop) [Decidable P] (x y : α) :
-    f (ite P x y) = ite P (f x) (f y) :=
-  apply_dite f P (fun _ => x) (fun _ => y)
-
-/-- Negation of the condition `P : Prop` in a `dite` is the same as swapping the branches. -/
-@[simp] theorem dite_not (P : Prop) {_ : Decidable P}  (x : ¬P → α) (y : ¬¬P → α) :
-    dite (¬P) x y = dite P (fun h => y (not_not_intro h)) x := by
-  by_cases h : P <;> simp [h]
-
-/-- Negation of the condition `P : Prop` in a `ite` is the same as swapping the branches. -/
-@[simp] theorem ite_not (P : Prop) {_ : Decidable P} (x y : α) : ite (¬P) x y = ite P y x :=
-  dite_not P (fun _ => x) (fun _ => y)
-
-@[simp] theorem dite_eq_left_iff {P : Prop} [Decidable P] {B : ¬ P → α} :
-    dite P (fun _ => a) B = a ↔ ∀ h, B h = a := by
-  by_cases P <;> simp [*, forall_prop_of_true, forall_prop_of_false]
-
-@[simp] theorem dite_eq_right_iff {P : Prop} [Decidable P] {A : P → α} :
-    (dite P A fun _ => b) = b ↔ ∀ h, A h = b := by
-  by_cases P <;> simp [*, forall_prop_of_true, forall_prop_of_false]
-
-@[simp] theorem ite_eq_left_iff {P : Prop} [Decidable P] : ite P a b = a ↔ ¬P → b = a :=
-  dite_eq_left_iff
-
-@[simp] theorem ite_eq_right_iff {P : Prop} [Decidable P] : ite P a b = b ↔ P → a = b :=
-  dite_eq_right_iff
-
-/-- A `dite` whose results do not actually depend on the condition may be reduced to an `ite`. -/
-@[simp] theorem dite_eq_ite [Decidable P] : (dite P (fun _ => a) fun _ => b) = ite P a b := rfl
-
--- We don't mark this as `simp` as it is already handled by `ite_eq_right_iff`.
-theorem ite_some_none_eq_none [Decidable P] :
-    (if P then some x else none) = none ↔ ¬ P := by
-  simp only [ite_eq_right_iff]
-  rfl
-
-@[simp] theorem ite_some_none_eq_some [Decidable P] :
-    (if P then some x else none) = some y ↔ P ∧ x = y := by
-  split <;> simp_all

src/Init/Classical.lean

@@ -1,10 +1,11 @@
 /-
 Copyright (c) 2020 Microsoft Corporation. All rights reserved.
 Released under Apache 2.0 license as described in the file LICENSE.
-Authors: Leonardo de Moura, Mario Carneiro
+Authors: Leonardo de Moura
 -/
 prelude
-import Init.PropLemmas
+import Init.Core
+import Init.NotationExtra
 
 universe u v
 
@@ -21,7 +22,7 @@ noncomputable def choose {α : Sort u} {p : α → Prop} (h : ∃ x, p x) : α :
 theorem choose_spec {α : Sort u} {p : α → Prop} (h : ∃ x, p x) : p (choose h) :=
   (indefiniteDescription p h).property
 
-/-- **Diaconescu's theorem**: excluded middle from choice, Function extensionality and propositional extensionality. -/
+/-- Diaconescu's theorem: excluded middle from choice, Function extensionality and propositional extensionality. -/
 theorem em (p : Prop) : p ∨ ¬p :=
   let U (x : Prop) : Prop := x = True ∨ p
   let V (x : Prop) : Prop := x = False ∨ p
@@ -111,8 +112,8 @@ theorem skolem {α : Sort u} {b : α → Sort v} {p : ∀ x, b x → Prop} : (
 
 theorem propComplete (a : Prop) : a = True ∨ a = False :=
   match em a with
-  | Or.inl ha => Or.inl (eq_true ha)
-  | Or.inr hn => Or.inr (eq_false hn)
+  | Or.inl ha => Or.inl (propext (Iff.intro (fun _ => ⟨⟩) (fun _ => ha)))
+  | Or.inr hn => Or.inr (propext (Iff.intro (fun h => hn h) (fun h => False.elim h)))
 
 -- this supercedes byCases in Decidable
 theorem byCases {p q : Prop} (hpq : p → q) (hnpq : ¬p → q) : q :=
@@ -122,36 +123,21 @@ theorem byCases {p q : Prop} (hpq : p → q) (hnpq : ¬p → q) : q :=
 theorem byContradiction {p : Prop} (h : ¬p → False) : p :=
   Decidable.byContradiction (dec := propDecidable _) h
 
-/-- The Double Negation Theorem: `¬¬P` is equivalent to `P`.
-The left-to-right direction, double negation elimination (DNE),
-is classically true but not constructively. -/
-@[scoped simp] theorem not_not : ¬¬a ↔ a := Decidable.not_not
+/--
+`by_cases (h :)? p` splits the main goal into two cases, assuming `h : p` in the first branch, and `h : ¬ p` in the second branch.
+-/
+syntax "by_cases " (atomic(ident " : "))? term : tactic
 
-@[simp] theorem not_forall {p : α → Prop} : (¬∀ x, p x) ↔ ∃ x, ¬p x := Decidable.not_forall
-
-theorem not_forall_not {p : α → Prop} : (¬∀ x, ¬p x) ↔ ∃ x, p x := Decidable.not_forall_not
-theorem not_exists_not {p : α → Prop} : (¬∃ x, ¬p x) ↔ ∀ x, p x := Decidable.not_exists_not
-
-theorem forall_or_exists_not (P : α → Prop) : (∀ a, P a) ∨ ∃ a, ¬ P a := by
-  rw [← not_forall]; exact em _
-
-theorem exists_or_forall_not (P : α → Prop) : (∃ a, P a) ∨ ∀ a, ¬ P a := by
-  rw [← not_exists]; exact em _
-
-theorem or_iff_not_imp_left  : a ∨ b ↔ (¬a → b) := Decidable.or_iff_not_imp_left
-theorem or_iff_not_imp_right : a ∨ b ↔ (¬b → a) := Decidable.or_iff_not_imp_right
-
-theorem not_imp_iff_and_not : ¬(a → b) ↔ a ∧ ¬b := Decidable.not_imp_iff_and_not
-
-theorem not_and_iff_or_not_not : ¬(a ∧ b) ↔ ¬a ∨ ¬b := Decidable.not_and_iff_or_not_not
-
-theorem not_iff : ¬(a ↔ b) ↔ (¬a ↔ b) := Decidable.not_iff
+macro_rules
+  | `(tactic| by_cases $h : $e) =>
+    `(tactic|
+      cases em $e with
+      | inl $h => _
+      | inr $h => _)
+  | `(tactic| by_cases $e) =>
+    `(tactic|
+      cases em $e with
+      | inl h => _
+      | inr h => _)
 
 end Classical
-
-/-- Extract an element from a existential statement, using `Classical.choose`. -/
--- This enables projection notation.
-@[reducible] noncomputable def Exists.choose {p : α → Prop} (P : ∃ a, p a) : α := Classical.choose P
-
-/-- Show that an element extracted from `P : ∃ a, p a` using `P.choose` satisfies `p`. -/
-theorem Exists.choose_spec {p : α → Prop} (P : ∃ a, p a) : p P.choose := Classical.choose_spec P

src/Init/Coe.lean

@@ -101,9 +101,8 @@ These classes should be implemented for coercions:
   `f` does not have a function type.
   `CoeFun` instances apply to `CoeOut` as well.
 
-* `CoeSort α β` is a coercion to a sort. `β` must be a universe, and this is
-  triggered when `a : α` appears in a place where a type is expected, like
-  `(x : a)` or `a → a`.
+* `CoeSort α β` is a coercion to a sort. `β` must be a universe, and if
+  `a : α` appears in a place where a type is expected, like `(x : a)` or `a → a`.
   `CoeSort` instances apply to `CoeOut` as well.
 
 On top of these instances this file defines several auxiliary type classes:
@@ -123,7 +122,7 @@ chained with other `Coe` instances, and coercion is automatically used when
 `x` has type `α` but it is used in a context where `β` is expected.
 You can use the `↑x` operator to explicitly trigger coercion.
 -/
-class Coe (α : semiOutParam (Sort u)) (β : Sort v) where
+class Coe (α : Sort u) (β : Sort v) where
   /-- Coerces a value of type `α` to type `β`. Accessible by the notation `↑x`,
   or by double type ascription `((x : α) : β)`. -/
   coe : α → β
@@ -146,7 +145,7 @@ instance : CoeTC α α where coe a := a
 /--
 `CoeOut α β` is for coercions that are applied from left-to-right.
 -/
-class CoeOut (α : Sort u) (β : semiOutParam (Sort v)) where
+class CoeOut (α : Sort u) (β : Sort v) where
   /-- Coerces a value of type `α` to type `β`. Accessible by the notation `↑x`,
   or by double type ascription `((x : α) : β)`. -/
   coe : α → β
@@ -174,7 +173,7 @@ instance : CoeOTC α α where coe a := a
 `CoeHead α β` is for coercions that are applied from left-to-right at most once
 at beginning of the coercion chain.
 -/
-class CoeHead (α : Sort u) (β : semiOutParam (Sort v)) where
+class CoeHead (α : Sort u) (β : Sort v) where
   /-- Coerces a value of type `α` to type `β`. Accessible by the notation `↑x`,
   or by double type ascription `((x : α) : β)`. -/
   coe : α → β
@@ -199,7 +198,7 @@ instance : CoeHTC α α where coe a := a
 sequence of coercions. That is, `α` can be further coerced via `Coe σ α` and
 `CoeHead τ σ` instances but `β` will only be the expected type of the expression.
 -/
-class CoeTail (α : semiOutParam (Sort u)) (β : Sort v) where
+class CoeTail (α : Sort u) (β : Sort v) where
   /-- Coerces a value of type `α` to type `β`. Accessible by the notation `↑x`,
   or by double type ascription `((x : α) : β)`. -/
   coe : α → β
@@ -255,9 +254,8 @@ instance : CoeT α a α where coe := a
 /--
 `CoeFun α (γ : α → Sort v)` is a coercion to a function. `γ a` should be a
 (coercion-to-)function type, and this is triggered whenever an element
-`f : α` appears in an application like `f x`, which would not make sense since
-`f` does not have a function type.
-`CoeFun` instances apply to `CoeOut` as well.
+`f : α` appears in an application like `f x` which would not make sense since
+`f` does not have a function type. This is automatically turned into `CoeFun.coe f x`.
 -/
 class CoeFun (α : Sort u) (γ : outParam (α → Sort v)) where
   /-- Coerces a value `f : α` to type `γ f`, which should be either be a
@@ -269,10 +267,9 @@ attribute [coe_decl] CoeFun.coe
 instance [CoeFun α fun _ => β] : CoeOut α β where coe a := CoeFun.coe a
 
 /--
-`CoeSort α β` is a coercion to a sort. `β` must be a universe, and this is
-triggered when `a : α` appears in a place where a type is expected, like
-`(x : a)` or `a → a`.
-`CoeSort` instances apply to `CoeOut` as well.
+`CoeSort α β` is a coercion to a sort. `β` must be a universe, and if
+`a : α` appears in a place where a type is expected, like `(x : a)` or `a → a`,
+then it will be turned into `(x : CoeSort.coe a)`.
 -/
 class CoeSort (α : Sort u) (β : outParam (Sort v)) where
   /-- Coerces a value of type `α` to `β`, which must be a universe. -/
@@ -290,16 +287,10 @@ between e.g. `↑x + ↑y` and `↑(x + y)`.
 -/
 syntax:1024 (name := coeNotation) "↑" term:1024 : term
 
-/-- `⇑ t` coerces `t` to a function. -/
-syntax:1024 (name := coeFunNotation) "⇑" term:1024 : term
-
-/-- `↥ t` coerces `t` to a type. -/
-syntax:1024 (name := coeSortNotation) "↥" term:1024 : term
-
 /-! # Basic instances -/
 
 instance boolToProp : Coe Bool Prop where
-  coe b := Eq b true
+  coe := Bool.asProp
 
 instance boolToSort : CoeSort Bool Prop where
   coe b := b

src/Init/Control/Basic.lean

@@ -186,7 +186,7 @@ This is the same as [`MonadBaseControl`](https://hackage.haskell.org/package/mon
 To learn about `MonadControl`, see the comment above this docstring.
 
 -/
-class MonadControl (m : semiOutParam (Type u → Type v)) (n : Type u → Type w) where
+class MonadControl (m : Type u → Type v) (n : Type u → Type w) where
   stM      : Type u → Type u
   liftWith : {α : Type u} → (({β : Type u} → n β → m (stM β)) → m α) → n α
   restoreM : {α : Type u} → m (stM α) → n α

src/Init/Control/Lawful.lean

@@ -1,7 +1,7 @@
 /-
 Copyright (c) 2021 Microsoft Corporation. All rights reserved.
 Released under Apache 2.0 license as described in the file LICENSE.
-Authors: Sebastian Ullrich, Leonardo de Moura, Mario Carneiro
+Authors: Sebastian Ullrich, Leonardo de Moura
 -/
 prelude
 import Init.SimpLemmas
@@ -84,36 +84,6 @@ theorem seqRight_eq_bind [Monad m] [LawfulMonad m] (x : m α) (y : m β) : x *>
 theorem seqLeft_eq_bind [Monad m] [LawfulMonad m] (x : m α) (y : m β) : x <* y = x >>= fun a => y >>= fun _ => pure a := by
   rw [seqLeft_eq]; simp [map_eq_pure_bind, seq_eq_bind_map]
 
-/--
-An alternative constructor for `LawfulMonad` which has more
-defaultable fields in the common case.
--/
-theorem LawfulMonad.mk' (m : Type u → Type v) [Monad m]
-    (id_map : ∀ {α} (x : m α), id <$> x = x)
-    (pure_bind : ∀ {α β} (x : α) (f : α → m β), pure x >>= f = f x)
-    (bind_assoc : ∀ {α β γ} (x : m α) (f : α → m β) (g : β → m γ),
-      x >>= f >>= g = x >>= fun x => f x >>= g)
-    (map_const : ∀ {α β} (x : α) (y : m β),
-      Functor.mapConst x y = Function.const β x <$> y := by intros; rfl)
-    (seqLeft_eq : ∀ {α β} (x : m α) (y : m β),
-      x <* y = (x >>= fun a => y >>= fun _ => pure a) := by intros; rfl)
-    (seqRight_eq : ∀ {α β} (x : m α) (y : m β), x *> y = (x >>= fun _ => y) := by intros; rfl)
-    (bind_pure_comp : ∀ {α β} (f : α → β) (x : m α),
-      x >>= (fun y => pure (f y)) = f <$> x := by intros; rfl)
-    (bind_map : ∀ {α β} (f : m (α → β)) (x : m α), f >>= (. <$> x) = f <*> x := by intros; rfl)
-    : LawfulMonad m :=
-  have map_pure {α β} (g : α → β) (x : α) : g <$> (pure x : m α) = pure (g x) := by
-    rw [← bind_pure_comp]; simp [pure_bind]
-  { id_map, bind_pure_comp, bind_map, pure_bind, bind_assoc, map_pure,
-    comp_map := by simp [← bind_pure_comp, bind_assoc, pure_bind]
-    pure_seq := by intros; rw [← bind_map]; simp [pure_bind]
-    seq_pure := by intros; rw [← bind_map]; simp [map_pure, bind_pure_comp]
-    seq_assoc := by simp [← bind_pure_comp, ← bind_map, bind_assoc, pure_bind]
-    map_const := funext fun x => funext (map_const x)
-    seqLeft_eq := by simp [seqLeft_eq, ← bind_map, ← bind_pure_comp, pure_bind, bind_assoc]
-    seqRight_eq := fun x y => by
-      rw [seqRight_eq, ← bind_map, ← bind_pure_comp, bind_assoc]; simp [pure_bind, id_map] }
-
 /-! # Id -/
 
 namespace Id
@@ -203,16 +173,6 @@ instance [Monad m] [LawfulMonad m] : LawfulMonad (ExceptT ε m) where
 
 end ExceptT
 
-/-! # Except -/
-
-instance : LawfulMonad (Except ε) := LawfulMonad.mk'
-  (id_map := fun x => by cases x <;> rfl)
-  (pure_bind := fun a f => rfl)
-  (bind_assoc := fun a f g => by cases a <;> rfl)
-
-instance : LawfulApplicative (Except ε) := inferInstance
-instance : LawfulFunctor (Except ε) := inferInstance
-
 /-! # ReaderT -/
 
 namespace ReaderT
@@ -347,30 +307,3 @@ instance [Monad m] [LawfulMonad m] : LawfulMonad (StateT σ m) where
   bind_assoc     := by intros; apply ext; intros; simp
 
 end StateT
-
-/-! # EStateM -/
-
-instance : LawfulMonad (EStateM ε σ) := .mk'
-  (id_map := fun x => funext <| fun s => by
-    dsimp only [EStateM.instMonadEStateM, EStateM.map]
-    match x s with
-    | .ok _ _ => rfl
-    | .error _ _ => rfl)
-  (pure_bind := fun _ _ => rfl)
-  (bind_assoc := fun x _ _ => funext <| fun s => by
-    dsimp only [EStateM.instMonadEStateM, EStateM.bind]
-    match x s with
-    | .ok _ _ => rfl
-    | .error _ _ => rfl)
-  (map_const := fun _ _ => rfl)
-
-/-! # Option -/
-
-instance : LawfulMonad Option := LawfulMonad.mk'
-  (id_map := fun x => by cases x <;> rfl)
-  (pure_bind := fun x f => rfl)
-  (bind_assoc := fun x f g => by cases x <;> rfl)
-  (bind_pure_comp := fun f x => by cases x <;> rfl)
-
-instance : LawfulApplicative Option := inferInstance
-instance : LawfulFunctor Option := inferInstance

src/Init/Conv.lean

@@ -6,7 +6,7 @@ Authors: Leonardo de Moura
 Notation for operators defined at Prelude.lean
 -/
 prelude
-import Init.Meta
+import Init.NotationExtra
 
 namespace Lean.Parser.Tactic.Conv
 
@@ -54,10 +54,6 @@ syntax (name := lhs) "lhs" : conv
 (In general, for an `n`-ary operator, it traverses into the last argument.) -/
 syntax (name := rhs) "rhs" : conv
 
-/-- Traverses into the function of a (unary) function application.
-For example, `| f a b` turns into `| f a`. (Use `arg 0` to traverse into `f`.)  -/
-syntax (name := «fun») "fun" : conv
-
 /-- Reduces the target to Weak Head Normal Form. This reduces definitions
 in "head position" until a constructor is exposed. For example, `List.map f [a, b, c]`
 weak head normalizes to `f a :: List.map f [b, c]`. -/
@@ -78,13 +74,12 @@ syntax (name := congr) "congr" : conv
 * `arg i` traverses into the `i`'th argument of the target. For example if the
   target is `f a b c d` then `arg 1` traverses to `a` and `arg 3` traverses to `c`.
 * `arg @i` is the same as `arg i` but it counts all arguments instead of just the
-  explicit arguments.
-* `arg 0` traverses into the function. If the target is `f a b c d`, `arg 0` traverses into `f`. -/
+  explicit arguments. -/
 syntax (name := arg) "arg " "@"? num : conv
 
 /-- `ext x` traverses into a binder (a `fun x => e` or `∀ x, e` expression)
 to target `e`, introducing name `x` in the process. -/
-syntax (name := ext) "ext" (ppSpace colGt ident)* : conv
+syntax (name := ext) "ext" (colGt ident)* : conv
 
 /-- `change t'` replaces the target `t` with `t'`,
 assuming `t` and `t'` are definitionally equal. -/
@@ -94,7 +89,7 @@ syntax (name := change) "change " term : conv
 Like the `delta` tactic, this ignores any definitional equations and uses
 primitive delta-reduction instead, which may result in leaking implementation details.
 Users should prefer `unfold` for unfolding definitions. -/
-syntax (name := delta) "delta" (ppSpace colGt ident)+ : conv
+syntax (name := delta) "delta " (colGt ident)+ : conv
 
 /--
 * `unfold foo` unfolds all occurrences of `foo` in the target.
@@ -102,7 +97,7 @@ syntax (name := delta) "delta" (ppSpace colGt ident)+ : conv
 Like the `unfold` tactic, this uses equational lemmas for the chosen definition
 to rewrite the target. For recursive definitions,
 only one layer of unfolding is performed. -/
-syntax (name := unfold) "unfold" (ppSpace colGt ident)+ : conv
+syntax (name := unfold) "unfold " (colGt ident)+ : conv
 
 /--
 * `pattern pat` traverses to the first subterm of the target that matches `pat`.
@@ -144,8 +139,8 @@ example (a : Nat): (0 + 0) = a - a := by
     rw [← Nat.sub_self a]
 ```
 -/
-syntax (name := dsimp) "dsimp" (config)? (discharger)? (&" only")?
-  (" [" withoutPosition((simpErase <|> simpLemma),*) "]")? : conv
+syntax (name := dsimp) "dsimp " (config)? (discharger)? (&"only ")?
+  ("[" withoutPosition((simpErase <|> simpLemma),*) "]")? : conv
 
 /-- `simp_match` simplifies match expressions. For example,
 ```
@@ -219,7 +214,7 @@ macro (name := case') tk:"case' " args:sepBy1(caseArg, " | ") arr:" => " s:convS
 `next x₁ ... xₙ => tac` additionally renames the `n` most recent hypotheses with
 inaccessible names to the given names.
 -/
-macro "next" args:(ppSpace binderIdent)* " => " tac:convSeq : conv => `(conv| case _ $args* => $tac)
+macro "next " args:binderIdent* " => " tac:convSeq : conv => `(conv| case _ $args* => $tac)
 
 /--
 `focus tac` focuses on the main goal, suppressing all other goals, and runs `tac` on it.
@@ -255,7 +250,7 @@ macro "left" : conv => `(conv| lhs)
 /-- `right` traverses into the right argument. Synonym for `rhs`. -/
 macro "right" : conv => `(conv| rhs)
 /-- `intro` traverses into binders. Synonym for `ext`. -/
-macro "intro" xs:(ppSpace colGt ident)* : conv => `(conv| ext $xs*)
+macro "intro" xs:(colGt ident)* : conv => `(conv| ext $xs*)
 
 syntax enterArg := ident <|> ("@"? num)
 
@@ -266,7 +261,7 @@ It is a shorthand for other conv tactics as follows:
 * `enter [x]` (where `x` is an identifier) is equivalent to `ext x`.
 For example, given the target `f (g a (fun x => x b))`, `enter [1, 2, x, 1]`
 will traverse to the subterm `b`. -/
-syntax "enter" " [" withoutPosition(enterArg,+) "]" : conv
+syntax "enter" " [" (colGt enterArg),+ "]": conv
 macro_rules
   | `(conv| enter [$i:num]) => `(conv| arg $i)
   | `(conv| enter [@$i]) => `(conv| arg @$i)
@@ -280,7 +275,7 @@ cannot be reasonably interpreted as proving one equality from a list of others.
 macro "apply " e:term : conv => `(conv| tactic => apply $e)
 
 /-- `first | conv | ...` runs each `conv` until one succeeds, or else fails. -/
-syntax (name := first) "first " withPosition((ppDedent(ppLine) colGe "| " convSeq)+) : conv
+syntax (name := first) "first " withPosition((colGe "|" convSeq)+) : conv
 
 /-- `try tac` runs `tac` and succeeds even if `tac` failed. -/
 macro "try " t:convSeq : conv => `(conv| first | $t | skip)
@@ -289,15 +284,15 @@ macro:1 x:conv tk:" <;> " y:conv:0 : conv =>
   `(conv| tactic' => (conv' => $x:conv) <;>%$tk (conv' => $y:conv))
 
 /-- `repeat convs` runs the sequence `convs` repeatedly until it fails to apply. -/
-syntax "repeat " convSeq : conv
+syntax "repeat" convSeq : conv
 macro_rules
-  | `(conv| repeat $seq) => `(conv| first | ($seq); repeat $seq | skip)
+  | `(conv| repeat $seq) => `(conv| first | ($seq); repeat $seq | rfl)
 
 /--
 `conv => ...` allows the user to perform targeted rewriting on a goal or hypothesis,
 by focusing on particular subexpressions.
 
-See <https://lean-lang.org/theorem_proving_in_lean4/conv.html> for more details.
+See <https://leanprover.github.io/theorem_proving_in_lean4/conv.html> for more details.
 
 Basic forms:
 * `conv => cs` will rewrite the goal with conv tactics `cs`.
@@ -306,9 +301,6 @@ Basic forms:
 -/
 -- HACK: put this at the end so that references to `conv` above
 -- refer to the syntax category instead of this syntax
-syntax (name := conv) "conv" (" at " ident)? (" in " (occs)? term)? " => " convSeq : tactic
-
-/-- `norm_cast` tactic in `conv` mode. -/
-syntax (name := normCast) "norm_cast" : conv
+syntax (name := conv) "conv " (" at " ident)? (" in " (occs)? term)? " => " convSeq : tactic
 
 end Lean.Parser.Tactic.Conv

src/Init/Core.lean

@@ -17,9 +17,7 @@ universe u v w
 at the application site itself (by comparison to the `@[inline]` attribute,
 which applies to all applications of the function).
 -/
-@[simp] def inline {α : Sort u} (a : α) : α := a
-
-theorem id.def {α : Sort u} (a : α) : id a = a := rfl
+def inline {α : Sort u} (a : α) : α := a
 
 /--
 `flip f a b` is `f b a`. It is useful for "point-free" programming,
@@ -34,32 +32,8 @@ and `flip (·<·)` is the greater-than relation.
 
 @[simp] theorem Function.comp_apply {f : β → δ} {g : α → β} {x : α} : comp f g x = f (g x) := rfl
 
-theorem Function.comp_def {α β δ} (f : β → δ) (g : α → β) : f ∘ g = fun x => f (g x) := rfl
-
 attribute [simp] namedPattern
 
-/--
-`Empty.elim : Empty → C` says that a value of any type can be constructed from
-`Empty`. This can be thought of as a compiler-checked assertion that a code path is unreachable.
-
-This is a non-dependent variant of `Empty.rec`.
--/
-@[macro_inline] def Empty.elim {C : Sort u} : Empty → C := Empty.rec
-
-/-- Decidable equality for Empty -/
-instance : DecidableEq Empty := fun a => a.elim
-
-/--
-`PEmpty.elim : Empty → C` says that a value of any type can be constructed from
-`PEmpty`. This can be thought of as a compiler-checked assertion that a code path is unreachable.
-
-This is a non-dependent variant of `PEmpty.rec`.
--/
-@[macro_inline] def PEmpty.elim {C : Sort _} : PEmpty → C := fun a => nomatch a
-
-/-- Decidable equality for PEmpty -/
-instance : DecidableEq PEmpty := fun a => a.elim
-
 /--
   Thunks are "lazy" values that are evaluated when first accessed using `Thunk.get/map/bind`.
   The value is then stored and not recomputed for all further accesses. -/
@@ -104,8 +78,6 @@ instance thunkCoe : CoeTail α (Thunk α) where
 abbrev Eq.ndrecOn.{u1, u2} {α : Sort u2} {a : α} {motive : α → Sort u1} {b : α} (h : a = b) (m : motive a) : motive b :=
   Eq.ndrec m h
 
-/-! # definitions  -/
-
 /--
 If and only if, or logical bi-implication. `a ↔ b` means that `a` implies `b` and vice versa.
 By `propext`, this implies that `a` and `b` are equal and hence any expression involving `a`
@@ -154,10 +126,6 @@ inductive PSum (α : Sort u) (β : Sort v) where
 
 @[inherit_doc] infixr:30 " ⊕' " => PSum
 
-instance {α β} [Inhabited α] : Inhabited (PSum α β) := ⟨PSum.inl default⟩
-
-instance {α β} [Inhabited β] : Inhabited (PSum α β) := ⟨PSum.inr default⟩
-
 /--
 `Sigma β`, also denoted `Σ a : α, β a` or `(a : α) × β a`, is the type of dependent pairs
 whose first component is `a : α` and whose second component is `b : β a`
@@ -374,70 +342,6 @@ class HasEquiv (α : Sort u) where
 
 @[inherit_doc] infix:50 " ≈ "  => HasEquiv.Equiv
 
-/-! # set notation  -/
-
-/-- Notation type class for the subset relation `⊆`. -/
-class HasSubset (α : Type u) where
-  /-- Subset relation: `a ⊆ b`  -/
-  Subset : α → α → Prop
-export HasSubset (Subset)
-
-/-- Notation type class for the strict subset relation `⊂`. -/
-class HasSSubset (α : Type u) where
-  /-- Strict subset relation: `a ⊂ b`  -/
-  SSubset : α → α → Prop
-export HasSSubset (SSubset)
-
-/-- Superset relation: `a ⊇ b`  -/
-abbrev Superset [HasSubset α] (a b : α) := Subset b a
-
-/-- Strict superset relation: `a ⊃ b`  -/
-abbrev SSuperset [HasSSubset α] (a b : α) := SSubset b a
-
-/-- Notation type class for the union operation `∪`. -/
-class Union (α : Type u) where
-  /-- `a ∪ b` is the union of`a` and `b`. -/
-  union : α → α → α
-
-/-- Notation type class for the intersection operation `∩`. -/
-class Inter (α : Type u) where
-  /-- `a ∩ b` is the intersection of`a` and `b`. -/
-  inter : α → α → α
-
-/-- Notation type class for the set difference `\`. -/
-class SDiff (α : Type u) where
-  /--
-  `a \ b` is the set difference of `a` and `b`,
-  consisting of all elements in `a` that are not in `b`.
-  -/
-  sdiff : α → α → α
-
-/-- Subset relation: `a ⊆ b`  -/
-infix:50 " ⊆ " => Subset
-
-/-- Strict subset relation: `a ⊂ b`  -/
-infix:50 " ⊂ " => SSubset
-
-/-- Superset relation: `a ⊇ b`  -/
-infix:50 " ⊇ " => Superset
-
-/-- Strict superset relation: `a ⊃ b`  -/
-infix:50 " ⊃ " => SSuperset
-
-/-- `a ∪ b` is the union of`a` and `b`. -/
-infixl:65 " ∪ " => Union.union
-
-/-- `a ∩ b` is the intersection of`a` and `b`. -/
-infixl:70 " ∩ " => Inter.inter
-
-/--
-`a \ b` is the set difference of `a` and `b`,
-consisting of all elements in `a` that are not in `b`.
--/
-infix:70 " \\ " => SDiff.sdiff
-
-/-! # collections  -/
-
 /-- `EmptyCollection α` is the typeclass which supports the notation `∅`, also written as `{}`. -/
 class EmptyCollection (α : Type u) where
   /-- `∅` or `{}` is the empty set or empty collection.
@@ -447,36 +351,6 @@ class EmptyCollection (α : Type u) where
 @[inherit_doc] notation "{" "}" => EmptyCollection.emptyCollection
 @[inherit_doc] notation "∅"     => EmptyCollection.emptyCollection
 
-/--
-Type class for the `insert` operation.
-Used to implement the `{ a, b, c }` syntax.
--/
-class Insert (α : outParam <| Type u) (γ : Type v) where
-  /-- `insert x xs` inserts the element `x` into the collection `xs`. -/
-  insert : α → γ → γ
-export Insert (insert)
-
-/--
-Type class for the `singleton` operation.
-Used to implement the `{ a, b, c }` syntax.
--/
-class Singleton (α : outParam <| Type u) (β : Type v) where
-  /-- `singleton x` is a collection with the single element `x` (notation: `{x}`). -/
-  singleton : α → β
-export Singleton (singleton)
-
-/-- `insert x ∅ = {x}` -/
-class IsLawfulSingleton (α : Type u) (β : Type v) [EmptyCollection β] [Insert α β] [Singleton α β] :
-    Prop where
-  /-- `insert x ∅ = {x}` -/
-  insert_emptyc_eq (x : α) : (insert x ∅ : β) = singleton x
-export IsLawfulSingleton (insert_emptyc_eq)
-
-/-- Type class used to implement the notation `{ a ∈ c | p a }` -/
-class Sep (α : outParam <| Type u) (γ : Type v) where
-  /-- Computes `{ a ∈ c | p a }`. -/
-  sep : (α → Prop) → γ → γ
-
 /--
 `Task α` is a primitive for asynchronous computation.
 It represents a computation that will resolve to a value of type `α`,
@@ -537,10 +411,9 @@ set_option linter.unusedVariables.funArgs false in
 be available and then calls `f` on the result.
 
 `prio`, if provided, is the priority of the task.
-If `sync` is set to true, `f` is executed on the current thread if `x` has already finished.
 -/
 @[noinline, extern "lean_task_map"]
-protected def map (f : α → β) (x : Task α) (prio := Priority.default) (sync := false) : Task β :=
+protected def map {α : Type u} {β : Type v} (f : α → β) (x : Task α) (prio := Priority.default) : Task β :=
   ⟨f x.get⟩
 
 set_option linter.unusedVariables.funArgs false in
@@ -551,11 +424,9 @@ for the value of `x` to be available and then calls `f` on the result,
 resulting in a new task which is then run for a result.
 
 `prio`, if provided, is the priority of the task.
-If `sync` is set to true, `f` is executed on the current thread if `x` has already finished.
 -/
 @[noinline, extern "lean_task_bind"]
-protected def bind (x : Task α) (f : α → Task β) (prio := Priority.default) (sync := false) :
-    Task β :=
+protected def bind {α : Type u} {β : Type v} (x : Task α) (f : α → Task β) (prio := Priority.default) : Task β :=
   ⟨(f x.get).get⟩
 
 end Task
@@ -593,13 +464,13 @@ theorem optParam_eq (α : Sort u) (default : α) : optParam α default = α := r
 `strictOr` is the same as `or`, but it does not use short-circuit evaluation semantics:
 both sides are evaluated, even if the first value is `true`.
 -/
-@[extern "lean_strict_or"] def strictOr  (b₁ b₂ : Bool) := b₁ || b₂
+@[extern c inline "#1 || #2"] def strictOr  (b₁ b₂ : Bool) := b₁ || b₂
 
 /--
 `strictAnd` is the same as `and`, but it does not use short-circuit evaluation semantics:
 both sides are evaluated, even if the first value is `false`.
 -/
-@[extern "lean_strict_and"] def strictAnd (b₁ b₂ : Bool) := b₁ && b₂
+@[extern c inline "#1 && #2"] def strictAnd (b₁ b₂ : Bool) := b₁ && b₂
 
 /--
 `x != y` is boolean not-equal. It is the negation of `x == y` which is supplied by
@@ -651,7 +522,9 @@ theorem not_not_intro {p : Prop} (h : p) : ¬ ¬ p :=
   fun hn : ¬ p => hn h
 
 -- proof irrelevance is built in
-theorem proof_irrel {a : Prop} (h₁ h₂ : a) : h₁ = h₂ := rfl
+theorem proofIrrel {a : Prop} (h₁ h₂ : a) : h₁ = h₂ := rfl
+
+theorem id.def {α : Sort u} (a : α) : id a = a := rfl
 
 /--
 If `h : α = β` is a proof of type equality, then `h.mp : α → β` is the induced
@@ -699,9 +572,8 @@ theorem Ne.elim (h : a ≠ b) : a = b → False := h
 
 theorem Ne.irrefl (h : a ≠ a) : False := h rfl
 
-theorem Ne.symm (h : a ≠ b) : b ≠ a := fun h₁ => h (h₁.symm)
-
-theorem ne_comm {α} {a b : α} : a ≠ b ↔ b ≠ a := ⟨Ne.symm, Ne.symm⟩
+theorem Ne.symm (h : a ≠ b) : b ≠ a :=
+  fun h₁ => h (h₁.symm)
 
 theorem false_of_ne : a ≠ a → False := Ne.irrefl
 
@@ -713,8 +585,8 @@ theorem ne_true_of_not : ¬p → p ≠ True :=
     have : ¬True := h ▸ hnp
     this trivial
 
-theorem true_ne_false : ¬True = False := ne_false_of_self trivial
-theorem false_ne_true : False ≠ True := fun h => h.symm ▸ trivial
+theorem true_ne_false : ¬True = False :=
+  ne_false_of_self trivial
 
 end Ne
 
@@ -726,6 +598,10 @@ theorem Bool.of_not_eq_false : {b : Bool} → ¬ (b = false) → b = true
   | true,  _ => rfl
   | false, h => absurd rfl h
 
+theorem Bool.of_not_asProp : ¬ b.asProp → b = false := of_not_eq_true
+
+theorem Bool.of_asProp : b.asProp → b = true := id
+
 theorem ne_of_beq_false [BEq α] [LawfulBEq α] {a b : α} (h : (a == b) = false) : a ≠ b := by
   intro h'; subst h'; have : true = false := Eq.trans LawfulBEq.rfl.symm h; contradiction
 
@@ -791,31 +667,22 @@ theorem Iff.refl (a : Prop) : a ↔ a :=
 protected theorem Iff.rfl {a : Prop} : a ↔ a :=
   Iff.refl a
 
-macro_rules | `(tactic| rfl) => `(tactic| exact Iff.rfl)
-
-theorem Iff.of_eq (h : a = b) : a ↔ b := h ▸ Iff.rfl
-
 theorem Iff.trans (h₁ : a ↔ b) (h₂ : b ↔ c) : a ↔ c :=
-  Iff.intro (h₂.mp ∘ h₁.mp) (h₁.mpr ∘ h₂.mpr)
+  Iff.intro
+    (fun ha => Iff.mp h₂ (Iff.mp h₁ ha))
+    (fun hc => Iff.mpr h₁ (Iff.mpr h₂ hc))
 
--- This is needed for `calc` to work with `iff`.
-instance : Trans Iff Iff Iff where
-  trans := Iff.trans
+theorem Iff.symm (h : a ↔ b) : b ↔ a :=
+  Iff.intro (Iff.mpr h) (Iff.mp h)
 
-theorem Eq.comm {a b : α} : a = b ↔ b = a := Iff.intro Eq.symm Eq.symm
-theorem eq_comm {a b : α} : a = b ↔ b = a := Eq.comm
+theorem Iff.comm : (a ↔ b) ↔ (b ↔ a) :=
+  Iff.intro Iff.symm Iff.symm
 
-theorem Iff.symm (h : a ↔ b) : b ↔ a := Iff.intro h.mpr h.mp
-theorem Iff.comm: (a ↔ b) ↔ (b ↔ a) := Iff.intro Iff.symm Iff.symm
-theorem iff_comm : (a ↔ b) ↔ (b ↔ a) := Iff.comm
+theorem Iff.of_eq (h : a = b) : a ↔ b :=
+  h ▸ Iff.refl _
 
-theorem And.symm : a ∧ b → b ∧ a := fun ⟨ha, hb⟩ => ⟨hb, ha⟩
-theorem And.comm : a ∧ b ↔ b ∧ a := Iff.intro And.symm And.symm
-theorem and_comm : a ∧ b ↔ b ∧ a := And.comm
-
-theorem Or.symm : a ∨ b → b ∨ a := .rec .inr .inl
-theorem Or.comm : a ∨ b ↔ b ∨ a := Iff.intro Or.symm Or.symm
-theorem or_comm : a ∨ b ↔ b ∨ a := Or.comm
+theorem And.comm : a ∧ b ↔ b ∧ a := by
+  constructor <;> intro ⟨h₁, h₂⟩ <;> exact ⟨h₂, h₁⟩
 
 /-! # Exists -/
 
@@ -934,13 +801,6 @@ theorem if_neg {c : Prop} {h : Decidable c} (hnc : ¬c) {α : Sort u} {t e : α}
   | isTrue hc   => absurd hc hnc
   | isFalse _   => rfl
 
-/-- Split an if-then-else into cases. The `split` tactic is generally easier to use than this theorem. -/
-def iteInduction {c} [inst : Decidable c] {motive : α → Sort _} {t e : α}
-    (hpos : c → motive t) (hneg : ¬c → motive e) : motive (ite c t e) :=
-  match inst with
-  | isTrue h => hpos h
-  | isFalse h => hneg h
-
 theorem dif_pos {c : Prop} {h : Decidable c} (hc : c) {α : Sort u} {t : c → α} {e : ¬ c → α} : (dite c t e) = t hc :=
   match h with
   | isTrue  _   => rfl
@@ -1015,13 +875,8 @@ protected theorem Subsingleton.helim {α β : Sort u} [h₁ : Subsingleton α] (
   apply heq_of_eq
   apply Subsingleton.elim
 
-instance (p : Prop) : Subsingleton p := ⟨fun a b => proof_irrel a b⟩
-
-instance : Subsingleton Empty  := ⟨(·.elim)⟩
-instance : Subsingleton PEmpty := ⟨(·.elim)⟩
-
-instance [Subsingleton α] [Subsingleton β] : Subsingleton (α × β) :=
-  ⟨fun {..} {..} => by congr <;> apply Subsingleton.elim⟩
+instance (p : Prop) : Subsingleton p :=
+  ⟨fun a b => proofIrrel a b⟩
 
 instance (p : Prop) : Subsingleton (Decidable p) :=
   Subsingleton.intro fun
@@ -1032,9 +887,6 @@ instance (p : Prop) : Subsingleton (Decidable p) :=
       | isTrue t₂  => absurd t₂ f₁
       | isFalse _  => rfl
 
-example [Subsingleton α] (p : α → Prop) : Subsingleton (Subtype p) :=
-  ⟨fun ⟨x, _⟩ ⟨y, _⟩ => by congr; exact Subsingleton.elim x y⟩
-
 theorem recSubsingleton
      {p : Prop} [h : Decidable p]
      {h₁ : p → Sort u}
@@ -1314,117 +1166,12 @@ gen_injective_theorems% Lean.Syntax
 @[simp] theorem beq_iff_eq [BEq α] [LawfulBEq α] (a b : α) : a == b ↔ a = b :=
   ⟨eq_of_beq, by intro h; subst h; exact LawfulBEq.rfl⟩
 
-/-! # Prop lemmas -/
-
-/-- *Ex falso* for negation: from `¬a` and `a` anything follows. This is the same as `absurd` with
-the arguments flipped, but it is in the `Not` namespace so that projection notation can be used. -/
-def Not.elim {α : Sort _} (H1 : ¬a) (H2 : a) : α := absurd H2 H1
-
-/-- Non-dependent eliminator for `And`. -/
-abbrev And.elim (f : a → b → α) (h : a ∧ b) : α := f h.left h.right
-
-/-- Non-dependent eliminator for `Iff`. -/
-def Iff.elim (f : (a → b) → (b → a) → α) (h : a ↔ b) : α := f h.mp h.mpr
+/-! # Quotients -/
 
 /-- Iff can now be used to do substitutions in a calculation -/
 theorem Iff.subst {a b : Prop} {p : Prop → Prop} (h₁ : a ↔ b) (h₂ : p a) : p b :=
   Eq.subst (propext h₁) h₂
 
-theorem Not.intro {a : Prop} (h : a → False) : ¬a := h
-
-theorem Not.imp {a b : Prop} (H2 : ¬b) (H1 : a → b) : ¬a := mt H1 H2
-
-theorem not_congr (h : a ↔ b) : ¬a ↔ ¬b := ⟨mt h.2, mt h.1⟩
-
-theorem not_not_not : ¬¬¬a ↔ ¬a := ⟨mt not_not_intro, not_not_intro⟩
-
-theorem iff_of_true (ha : a) (hb : b) : a ↔ b := Iff.intro (fun _ => hb) (fun _ => ha)
-theorem iff_of_false (ha : ¬a) (hb : ¬b) : a ↔ b := Iff.intro ha.elim hb.elim
-
-theorem iff_true_left  (ha : a) : (a ↔ b) ↔ b := Iff.intro (·.mp ha) (iff_of_true ha)
-theorem iff_true_right (ha : a) : (b ↔ a) ↔ b := Iff.comm.trans (iff_true_left ha)
-
-theorem iff_false_left  (ha : ¬a) : (a ↔ b) ↔ ¬b := Iff.intro (mt ·.mpr ha) (iff_of_false ha)
-theorem iff_false_right (ha : ¬a) : (b ↔ a) ↔ ¬b := Iff.comm.trans (iff_false_left ha)
-
-theorem of_iff_true    (h : a ↔ True) : a := h.mpr trivial
-theorem iff_true_intro (h : a) : a ↔ True := iff_of_true h trivial
-
-theorem not_of_iff_false : (p ↔ False) → ¬p := Iff.mp
-theorem iff_false_intro (h : ¬a) : a ↔ False := iff_of_false h id
-
-theorem not_iff_false_intro (h : a) : ¬a ↔ False := iff_false_intro (not_not_intro h)
-theorem not_true : (¬True) ↔ False := iff_false_intro (not_not_intro trivial)
-
-theorem not_false_iff : (¬False) ↔ True := iff_true_intro not_false
-
-theorem Eq.to_iff : a = b → (a ↔ b) := Iff.of_eq
-theorem iff_of_eq : a = b → (a ↔ b) := Iff.of_eq
-theorem neq_of_not_iff : ¬(a ↔ b) → a ≠ b := mt Iff.of_eq
-
-theorem iff_iff_eq : (a ↔ b) ↔ a = b := Iff.intro propext Iff.of_eq
-@[simp] theorem eq_iff_iff : (a = b) ↔ (a ↔ b) := iff_iff_eq.symm
-
-theorem eq_self_iff_true (a : α)  : a = a ↔ True  := iff_true_intro rfl
-theorem ne_self_iff_false (a : α) : a ≠ a ↔ False := not_iff_false_intro rfl
-
-theorem false_of_true_iff_false (h : True ↔ False) : False := h.mp trivial
-theorem false_of_true_eq_false  (h : True = False) : False := false_of_true_iff_false (Iff.of_eq h)
-
-theorem true_eq_false_of_false : False → (True = False) := False.elim
-
-theorem iff_def  : (a ↔ b) ↔ (a → b) ∧ (b → a) := iff_iff_implies_and_implies a b
-theorem iff_def' : (a ↔ b) ↔ (b → a) ∧ (a → b) := Iff.trans iff_def And.comm
-
-theorem true_iff_false : (True ↔ False) ↔ False := iff_false_intro (·.mp  True.intro)
-theorem false_iff_true : (False ↔ True) ↔ False := iff_false_intro (·.mpr True.intro)
-
-theorem iff_not_self : ¬(a ↔ ¬a) | H => let f h := H.1 h h; f (H.2 f)
-theorem heq_self_iff_true (a : α) : HEq a a ↔ True := iff_true_intro HEq.rfl
-
-/-! ## implies -/
-
-theorem not_not_of_not_imp : ¬(a → b) → ¬¬a := mt Not.elim
-
-theorem not_of_not_imp {a : Prop} : ¬(a → b) → ¬b := mt fun h _ => h
-
-@[simp] theorem imp_not_self : (a → ¬a) ↔ ¬a := Iff.intro (fun h ha => h ha ha) (fun h _ => h)
-
-theorem imp_intro {α β : Prop} (h : α) : β → α := fun _ => h
-
-theorem imp_imp_imp {a b c d : Prop} (h₀ : c → a) (h₁ : b → d) : (a → b) → (c → d) := (h₁ ∘ · ∘ h₀)
-
-theorem imp_iff_right {a : Prop} (ha : a) : (a → b) ↔ b := Iff.intro (· ha) (fun a _ => a)
-
--- This is not marked `@[simp]` because we have `implies_true : (α → True) = True`
-theorem imp_true_iff (α : Sort u) : (α → True) ↔ True := iff_true_intro (fun _ => trivial)
-
-theorem false_imp_iff (a : Prop) : (False → a) ↔ True := iff_true_intro False.elim
-
-theorem true_imp_iff (α : Prop) : (True → α) ↔ α := imp_iff_right True.intro
-
-@[simp] theorem imp_self : (a → a) ↔ True := iff_true_intro id
-
-theorem imp_false : (a → False) ↔ ¬a := Iff.rfl
-
-theorem imp.swap : (a → b → c) ↔ (b → a → c) := Iff.intro flip flip
-
-theorem imp_not_comm : (a → ¬b) ↔ (b → ¬a) := imp.swap
-
-theorem imp_congr_left (h : a ↔ b) : (a → c) ↔ (b → c) := Iff.intro (· ∘ h.mpr) (· ∘ h.mp)
-
-theorem imp_congr_right (h : a → (b ↔ c)) : (a → b) ↔ (a → c) :=
-  Iff.intro (fun hab ha => (h ha).mp (hab ha)) (fun hcd ha => (h ha).mpr (hcd ha))
-
-theorem imp_congr_ctx (h₁ : a ↔ c) (h₂ : c → (b ↔ d)) : (a → b) ↔ (c → d) :=
-  Iff.trans (imp_congr_left h₁) (imp_congr_right h₂)
-
-theorem imp_congr (h₁ : a ↔ c) (h₂ : b ↔ d) : (a → b) ↔ (c → d) := imp_congr_ctx h₁ fun _ => h₂
-
-theorem imp_iff_not (hb : ¬b) : a → b ↔ ¬a := imp_congr_right fun _ => iff_false_intro hb
-
-/-! # Quotients -/
-
 namespace Quot
 /--
 The **quotient axiom**, or at least the nontrivial part of the quotient
@@ -1601,8 +1348,7 @@ then it lifts to a function on `Quotient s` such that `lift f h (mk a) = f a`.
 protected abbrev lift {α : Sort u} {β : Sort v} {s : Setoid α} (f : α → β) : ((a b : α) → a ≈ b → f a = f b) → Quotient s → β :=
   Quot.lift f
 
-/-- The analogue of `Quot.ind`: every element of `Quotient s` is of the form `Quotient.mk s a`. -/
-protected theorem ind {α : Sort u} {s : Setoid α} {motive : Quotient s → Prop} : ((a : α) → motive (Quotient.mk s a)) → (q : Quotient s) → motive q :=
+protected theorem ind {α : Sort u} {s : Setoid α} {motive : Quotient s → Prop} : ((a : α) → motive (Quotient.mk s a)) → (q : Quot Setoid.r) → motive q :=
   Quot.ind
 
 /--
@@ -1612,7 +1358,6 @@ then it lifts to a function on `Quotient s` such that `lift (mk a) f h = f a`.
 protected abbrev liftOn {α : Sort u} {β : Sort v} {s : Setoid α} (q : Quotient s) (f : α → β) (c : (a b : α) → a ≈ b → f a = f b) : β :=
   Quot.liftOn q f c
 
-/-- The analogue of `Quot.inductionOn`: every element of `Quotient s` is of the form `Quotient.mk s a`. -/
 @[elab_as_elim]
 protected theorem inductionOn {α : Sort u} {s : Setoid α} {motive : Quotient s → Prop}
     (q : Quotient s)
@@ -1730,7 +1475,7 @@ end
 
 section Exact
 
-variable {α : Sort u}
+variable   {α : Sort u}
 
 private def rel {s : Setoid α} (q₁ q₂ : Quotient s) : Prop :=
   Quotient.liftOn₂ q₁ q₂
@@ -1862,11 +1607,6 @@ class Antisymm {α : Sort u} (r : α → α → Prop) where
 namespace Lean
 /-! # Kernel reduction hints -/
 
-/--
-Depends on the correctness of the Lean compiler, interpreter, and all `[implemented_by ...]` and `[extern ...]` annotations.
--/
-axiom trustCompiler : True
-
 /--
 When the kernel tries to reduce a term `Lean.reduceBool c`, it will invoke the Lean interpreter to evaluate `c`.
 The kernel will not use the interpreter if `c` is not a constant.
@@ -1886,10 +1626,7 @@ Recall that the compiler trusts the correctness of all `[implemented_by ...]` an
 If an extern function is executed, then the trusted code base will also include the implementation of the associated
 foreign function.
 -/
-opaque reduceBool (b : Bool) : Bool :=
-  -- This ensures that `#print axioms` will track use of `reduceBool`.
-  have := trustCompiler
-  b
+opaque reduceBool (b : Bool) : Bool := b
 
 /--
 Similar to `Lean.reduceBool` for closed `Nat` terms.
@@ -1898,11 +1635,7 @@ Remark: we do not have plans for supporting a generic `reduceValue {α} (a : α)
 The main issue is that it is non-trivial to convert an arbitrary runtime object back into a Lean expression.
 We believe `Lean.reduceBool` enables most interesting applications (e.g., proof by reflection).
 -/
-opaque reduceNat (n : Nat) : Nat :=
-  -- This ensures that `#print axioms` will track use of `reduceNat`.
-  have := trustCompiler
-  n
-
+opaque reduceNat (n : Nat) : Nat := n
 
 /--
 The axiom `ofReduceBool` is used to perform proofs by reflection. See `reduceBool`.
@@ -1930,104 +1663,40 @@ So, you are mainly losing the capability of type checking your development using
 -/
 axiom ofReduceNat (a b : Nat) (h : reduceNat a = b) : a = b
 
-end Lean
-
-@[simp] theorem ge_iff_le [LE α] {x y : α} : x ≥ y ↔ y ≤ x := Iff.rfl
-
-@[simp] theorem gt_iff_lt [LT α] {x y : α} : x > y ↔ y < x := Iff.rfl
-
-theorem le_of_eq_of_le {a b c : α} [LE α] (h₁ : a = b) (h₂ : b ≤ c) : a ≤ c := h₁ ▸ h₂
-
-theorem le_of_le_of_eq {a b c : α} [LE α] (h₁ : a ≤ b) (h₂ : b = c) : a ≤ c := h₂ ▸ h₁
-
-theorem lt_of_eq_of_lt {a b c : α} [LT α] (h₁ : a = b) (h₂ : b < c) : a < c := h₁ ▸ h₂
-
-theorem lt_of_lt_of_eq {a b c : α} [LT α] (h₁ : a < b) (h₂ : b = c) : a < c := h₂ ▸ h₁
-
-namespace Std
-variable {α : Sort u}
-
 /--
-`Associative op` indicates `op` is an associative operation,
-i.e. `(a ∘ b) ∘ c = a ∘ (b ∘ c)`.
+`IsAssociative op` says that `op` is an associative operation,
+i.e. `(a ∘ b) ∘ c = a ∘ (b ∘ c)`. It is used by the `ac_rfl` tactic.
 -/
-class Associative (op : α → α → α) : Prop where
+class IsAssociative {α : Sort u} (op : α → α → α) where
   /-- An associative operation satisfies `(a ∘ b) ∘ c = a ∘ (b ∘ c)`. -/
   assoc : (a b c : α) → op (op a b) c = op a (op b c)
 
 /--
-`Commutative op` says that `op` is a commutative operation,
-i.e. `a ∘ b = b ∘ a`.
+`IsCommutative op` says that `op` is a commutative operation,
+i.e. `a ∘ b = b ∘ a`. It is used by the `ac_rfl` tactic.
 -/
-class Commutative (op : α → α → α) : Prop where
+class IsCommutative {α : Sort u} (op : α → α → α) where
   /-- A commutative operation satisfies `a ∘ b = b ∘ a`. -/
   comm : (a b : α) → op a b = op b a
 
 /--
-`IdempotentOp op` indicates `op` is an idempotent binary operation.
-i.e. `a ∘ a = a`.
+`IsIdempotent op` says that `op` is an idempotent operation,
+i.e. `a ∘ a = a`. It is used by the `ac_rfl` tactic
+(which also simplifies up to idempotence when available).
 -/
-class IdempotentOp (op : α → α → α) : Prop where
+class IsIdempotent {α : Sort u} (op : α → α → α) where
   /-- An idempotent operation satisfies `a ∘ a = a`. -/
   idempotent : (x : α) → op x x = x
 
 /--
-`LeftIdentify op o` indicates `o` is a left identity of `op`.
-
-This class does not require a proof that `o` is an identity, and
-is used primarily for infering the identity using class resoluton.
+`IsNeutral op e` says that `e` is a neutral operation for `op`,
+i.e. `a ∘ e = a = e ∘ a`. It is used by the `ac_rfl` tactic
+(which also simplifies neutral elements when available).
 -/
-class LeftIdentity (op : α → β → β) (o : outParam α) : Prop
+class IsNeutral {α : Sort u} (op : α → α → α) (neutral : α) where
+  /-- A neutral element can be cancelled on the left: `e ∘ a = a`. -/
+  left_neutral : (a : α) → op neutral a = a
+  /-- A neutral element can be cancelled on the right: `a ∘ e = a`. -/
+  right_neutral : (a : α) → op a neutral = a
 
-/--
-`LawfulLeftIdentify op o` indicates `o` is a verified left identity of
-`op`.
--/
-class LawfulLeftIdentity (op : α → β → β) (o : outParam α) extends LeftIdentity op o : Prop where
-  /-- Left identity `o` is an identity. -/
-  left_id : ∀ a, op o a = a
-
-/--
-`RightIdentify op o` indicates `o` is a right identity `o` of `op`.
-
-This class does not require a proof that `o` is an identity, and is used
-primarily for infering the identity using class resoluton.
--/
-class RightIdentity (op : α → β → α) (o : outParam β) : Prop
-
-/--
-`LawfulRightIdentify op o` indicates `o` is a verified right identity of
-`op`.
--/
-class LawfulRightIdentity (op : α → β → α) (o : outParam β) extends RightIdentity op o : Prop where
-  /-- Right identity `o` is an identity. -/
-  right_id : ∀ a, op a o = a
-
-/--
-`Identity op o` indicates `o` is a left and right identity of `op`.
-
-This class does not require a proof that `o` is an identity, and is used
-primarily for infering the identity using class resoluton.
--/
-class Identity (op : α → α → α) (o : outParam α) extends LeftIdentity op o, RightIdentity op o : Prop
-
-/--
-`LawfulIdentity op o` indicates `o` is a verified left and right
-identity of `op`.
--/
-class LawfulIdentity (op : α → α → α) (o : outParam α) extends Identity op o, LawfulLeftIdentity op o, LawfulRightIdentity op o : Prop
-
-/--
-`LawfulCommIdentity` can simplify defining instances of `LawfulIdentity`
-on commutative functions by requiring only a left or right identity
-proof.
-
-This class is intended for simplifying defining instances of
-`LawfulIdentity` and functions needed commutative operations with
-identity should just add a `LawfulIdentity` constraint.
--/
-class LawfulCommIdentity (op : α → α → α) (o : outParam α) [hc : Commutative op] extends LawfulIdentity op o : Prop where
-  left_id a := Eq.trans (hc.comm o a) (right_id a)
-  right_id a := Eq.trans (hc.comm a o) (left_id a)
-
-end Std
+end Lean

src/Init/Data.lean

@@ -6,9 +6,6 @@ Authors: Leonardo de Moura
 prelude
 import Init.Data.Basic
 import Init.Data.Nat
-import Init.Data.Bool
-import Init.Data.BitVec
-import Init.Data.Cast
 import Init.Data.Char
 import Init.Data.String
 import Init.Data.List
@@ -32,5 +29,3 @@ import Init.Data.Prod
 import Init.Data.AC
 import Init.Data.Queue
 import Init.Data.Channel
-import Init.Data.Cast
-import Init.Data.Sum

src/Init/Data/AC.lean

@@ -14,17 +14,15 @@ inductive Expr
   | op (lhs rhs : Expr)
   deriving Inhabited, Repr, BEq
 
-open Std
-
 structure Variable {α : Sort u} (op : α → α → α) : Type u where
   value : α
-  neutral : Option $ PLift (LawfulIdentity op value)
+  neutral : Option $ IsNeutral op value
 
 structure Context (α : Sort u) where
   op : α → α → α
-  assoc : Associative op
-  comm : Option $ PLift $ Commutative op
-  idem : Option $ PLift $ IdempotentOp op
+  assoc : IsAssociative op
+  comm : Option $ IsCommutative op
+  idem : Option $ IsIdempotent op
   vars : List (Variable op)
   arbitrary : α
 
@@ -130,14 +128,7 @@ theorem Context.mergeIdem_head2 (h : x ≠ y) : mergeIdem (x :: y :: ys) = x ::
   simp [mergeIdem, mergeIdem.loop, h]
 
 theorem Context.evalList_mergeIdem (ctx : Context α) (h : ContextInformation.isIdem ctx) (e : List Nat) : evalList α ctx (mergeIdem e) = evalList α ctx e := by
-  have h : IdempotentOp ctx.op := by
-    simp [ContextInformation.isIdem, Option.isSome] at h;
-    match h₂ : ctx.idem with
-    | none =>
-      simp [h₂] at h
-    | some val =>
-      simp [h₂] at h
-      exact val.down
+  have h : IsIdempotent ctx.op := by simp [ContextInformation.isIdem, Option.isSome] at h; cases h₂ : ctx.idem <;> simp [h₂] at h; assumption
   induction e using List.two_step_induction with
   | empty => rfl
   | single => rfl
@@ -150,18 +141,18 @@ theorem Context.evalList_mergeIdem (ctx : Context α) (h : ContextInformation.is
       rfl
     | cons z zs =>
       by_cases h₂ : x = y
-      case pos =>
+      case inl =>
         rw [h₂, mergeIdem_head, ih]
         simp [evalList, ←ctx.assoc.1, h.1, EvalInformation.evalOp]
-      case neg =>
+      case inr =>
         rw [mergeIdem_head2]
         by_cases h₃ : y = z
-        case pos =>
+        case inl =>
           simp [mergeIdem_head, h₃, evalList]
           cases h₄ : mergeIdem (z :: zs) with
           | nil => apply absurd h₄; apply mergeIdem_nonEmpty; simp
           | cons u us => simp_all [mergeIdem, mergeIdem.loop, evalList]
-        case neg =>
+        case inr =>
           simp [mergeIdem_head2, h₃, evalList] at *
           rw [ih]
         assumption
@@ -178,7 +169,7 @@ theorem Context.sort_loop_nonEmpty (xs : List Nat) (h : xs ≠ []) : sort.loop x
 
 theorem Context.evalList_insert
   (ctx : Context α)
-  (h : Commutative ctx.op)
+  (h : IsCommutative ctx.op)
   (x : Nat)
   (xs : List Nat)
   : evalList α ctx (insert x xs) = evalList α ctx (x::xs) := by
@@ -199,7 +190,7 @@ theorem Context.evalList_insert
 
 theorem Context.evalList_sort_congr
   (ctx : Context α)
-  (h : Commutative ctx.op)
+  (h : IsCommutative ctx.op)
   (h₂ : evalList α ctx a = evalList α ctx b)
   (h₃ : a ≠ [])
   (h₄ : b ≠ [])
@@ -218,7 +209,7 @@ theorem Context.evalList_sort_congr
 
 theorem Context.evalList_sort_loop_swap
   (ctx : Context α)
-  (h : Commutative ctx.op)
+  (h : IsCommutative ctx.op)
   (xs ys : List Nat)
   : evalList α ctx (sort.loop xs (y::ys)) = evalList α ctx (sort.loop (y::xs) ys) := by
   induction ys generalizing y xs with
@@ -233,7 +224,7 @@ theorem Context.evalList_sort_loop_swap
 
 theorem Context.evalList_sort_cons
   (ctx : Context α)
-  (h : Commutative ctx.op)
+  (h : IsCommutative ctx.op)
   (x : Nat)
   (xs : List Nat)
   : evalList α ctx (sort (x :: xs)) = evalList α ctx (x :: sort xs) := by
@@ -256,14 +247,7 @@ theorem Context.evalList_sort_cons
     all_goals simp [insert_nonEmpty]
 
 theorem Context.evalList_sort (ctx : Context α) (h : ContextInformation.isComm ctx) (e : List Nat) : evalList α ctx (sort e) = evalList α ctx e := by
-  have h : Commutative ctx.op := by
-    simp [ContextInformation.isComm, Option.isSome] at h
-    match h₂ : ctx.comm with
-    | none =>
-      simp only [h₂] at h
-    | some val =>
-      simp [h₂] at h
-      exact val.down
+  have h : IsCommutative ctx.op := by simp [ContextInformation.isComm, Option.isSome] at h; cases h₂ : ctx.comm <;> simp [h₂] at h; assumption
   induction e using List.two_step_induction with
   | empty => rfl
   | single => rfl
@@ -285,12 +269,10 @@ theorem Context.toList_nonEmpty (e : Expr) : e.toList ≠ [] := by
 theorem Context.unwrap_isNeutral
   {ctx : Context α}
   {x : Nat}
-  : ContextInformation.isNeutral ctx x = true → LawfulIdentity (EvalInformation.evalOp ctx) (EvalInformation.evalVar (β := α) ctx x) := by
+  : ContextInformation.isNeutral ctx x = true → IsNeutral (EvalInformation.evalOp ctx) (EvalInformation.evalVar (β := α) ctx x) := by
   simp [ContextInformation.isNeutral, Option.isSome, EvalInformation.evalOp, EvalInformation.evalVar]
   match (var ctx x).neutral with
-  | some hn =>
-    intro
-    exact hn.down
+  | some hn => intro; assumption
   | none => intro; contradiction
 
 theorem Context.evalList_removeNeutrals (ctx : Context α) (e : List Nat) : evalList α ctx (removeNeutrals ctx e) = evalList α ctx e := by
@@ -301,12 +283,10 @@ theorem Context.evalList_removeNeutrals (ctx : Context α) (e : List Nat) : eval
     case h_1 => rfl
     case h_2 h => split at h <;> simp_all
   | step x y ys ih =>
-    cases h₁ : ContextInformation.isNeutral ctx x <;>
-    cases h₂ : ContextInformation.isNeutral ctx y <;>
-    cases h₃ : removeNeutrals.loop ctx ys
+    cases h₁ : ContextInformation.isNeutral ctx x <;> cases h₂ : ContextInformation.isNeutral ctx y <;> cases h₃ : removeNeutrals.loop ctx ys
     <;> simp [removeNeutrals, removeNeutrals.loop, h₁, h₂, h₃, evalList, ←ih]
-    <;> (try simp [unwrap_isNeutral h₂ |>.right_id])
-    <;> (try simp [unwrap_isNeutral h₁ |>.left_id])
+    <;> (try simp [unwrap_isNeutral h₂ |>.2])
+    <;> (try simp [unwrap_isNeutral h₁ |>.1])
 
 theorem Context.evalList_append
   (ctx : Context α)