Skip to content

[#14953] feat: remove deprecated in-kernel native reduction - #27

Open
downstream-lean4[bot] wants to merge 3 commits into
masterfrom
adaptation-14953
Open

[#14953] feat: remove deprecated in-kernel native reduction#27
downstream-lean4[bot] wants to merge 3 commits into
masterfrom
adaptation-14953

Conversation

@downstream-lean4

Copy link
Copy Markdown
Contributor

This is the adaptation PR for leanprover/lean4#14953.

@downstream-lean4 downstream-lean4 Bot added the adaptation This is an adaptation PR for a PR in the lean4 repository. label Aug 28, 2026
@downstream-lean4

downstream-lean4 Bot commented Aug 28, 2026

Copy link
Copy Markdown
Contributor Author

Build report for reference-manual: adapt to removal of in-kernel native reduction

Stayed green
Repo Critical Build Test Lint
aesop ✅ in 7s ✅ in 5s ⏭️
batteries ✅ in 5s ✅ in 4s ✅ in 2s
import-graph ✅ in 2s ✅ in 3s ⏭️
lean4-cli ✅ in 1s ✅ in 0s ⏭️
mathlib4 ✅ in 1134s ✅ in 49s ✅ in 92s
plausible ✅ in 1s ✅ in 2s ⏭️
ProofWidgets4 ✅ in 3s ✅ in 1s ⏭️
quote4 ✅ in 2s ✅ in 1s ⏭️
reference-manual ✅ in 22s ⏭️ ⏭️
BibtexQuery ✅ in 1s ⏭️ ⏭️
comparator ✅ in 2s ⏭️ ⏭️
cslib ✅ in 37s ✅ in 9s ✅ in 3s
doc-gen4 ✅ in 3s ⏭️ ⏭️
illuminate ✅ in 4s ✅ in 11s ⏭️
lean4-unicode-basic ✅ in 2s ⏭️ ⏭️
lean4export ✅ in 0s ✅ in 7s ⏭️
LeanSearchClient ✅ in 1s ✅ in 0s ⏭️
leansqlite ✅ in 4s ✅ in 16s ⏭️
repl ✅ in 1s ✅ in 58s ⏭️
verso ✅ in 37s ✅ in 85s ⏭️
verso-slides ✅ in 5s ✅ in 6s ⏭️
verso-web-components ✅ in 31s ⏭️ ⏭️

View run

Kha added 2 commits August 28, 2026 14:49
`Lean.Meta.reduceNative?` was removed along with in-kernel native
reduction; upstream dropped the corresponding branch from `whnfImp`,
which `unfolds` mirrors.
`Lean.trustCompiler`, `Lean.reduceBool`/`reduceNat` and
`Lean.ofReduceBool`/`ofReduceNat` no longer exist, so `{name}` and
`signature` references to them no longer resolve. Drop the "Standard
Axioms" entries and the reflection example that used them, and describe
the per-invocation axioms that `native_decide` and `bv_decide` have
generated since Lean 4.29.0 instead. The historical
`validating-trustCompiler` section keeps its text as plain code spans.

* If {name}`sorryAx` is reported, then this theorem or one of its dependencies uses {lean}`sorry` or is otherwise incomplete.
* If {name}`Lean.trustCompiler` is reported, then native evaluation is used; see below for a discussion.
* If an axiom generated by native evaluation is reported, then compiled code is trusted as part of the proof; see below for a discussion.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably describe here what such axioms look like?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the very least, we should have a bit about precisely how the axiom connects to the compiled code.

The trusted code base is larger (it includes Lean's compilation toolchain and library annotations in the standard library), but still fixed and vetted.

General use ({tactic}`decide`{keywordOf Lean.Parser.Tactic.decide}` +native` or direct use of {name}`Lean.ofReduceBool`) can be used to create invalid proofs whenever the native evaluation of a term disagrees with the kernel's evaluation.
General use ({tactic}`decide`{keywordOf Lean.Parser.Tactic.decide}` +native` or direct use of `Lean.ofReduceBool`) can be used to create invalid proofs whenever the native evaluation of a term disagrees with the kernel's evaluation.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, since it's not part of the diff: this is the "up to 4.28" section

In addition to the full suite of automation and tools provided by Lean for every type, the {tactic}`bv_decide` tactic can solve many bitvector-related problems.
This tactic invokes an external automated theorem prover (`cadical`) and reconstructs the proof that it provides in Lean's own logic.
The resulting proofs rely only on the axiom {name}`Lean.ofReduceBool`; the external prover is not part of the trusted code base.
The resulting proofs rely only on a dedicated axiom that {tactic}`bv_decide` generates for each invocation; the external prover is not part of the trusted code base.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the external prover is not part of the trusted code base.

Is this still true? Before, the compiler was trusted and we ran a checker using compiled code. But if we "merely" emit an axiom, then we are trusting the checker, right? If not, then I think this sentence needs a bit of expansion to say in what way we are not trusting the external checker for the truth of the axiom.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cadical remains outside the TCB as the elaborator, formerly the kernel, runs the certificate checker. We should probably say here that this is what the axiom stands for /cc @hargoniX

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

adaptation This is an adaptation PR for a PR in the lean4 repository. cache-available toolchain-available

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants