vow-lean-kernel - Lean Kernel Arena

Checker "vow-lean-kernel"

Version: 0.1.0 · 📄 Declaration · 🔗 Source

A Lean 4 kernel (proof checker) written in Vow, a young systems language. Reads lean4export NDJSON and verifies each declaration is well-typed.

It accepts the full Arena tutorial suite and all of Lean core Init (54,475 declarations). Nat arithmetic uses a base-2^32 bignum backend, so reductions past 2^64 are exact. Declarations beyond the currently supported fragment are declined (exit 2) rather than falsely rejected — the checker is sound-by-construction on what it accepts and conservative elsewhere.

Vow is a language developed by Paulo Matos (github.com/pmatos) for agentic use — one of several such languages currently emerging, alongside MoonBit, Vera-lang, and Zerolang. This kernel, the first large program written in Vow, was undertaken as a challenge: to have an agent develop a complete Lean kernel entirely in the new language, and it doubles as a proving ground for it. The work was 100% agentic, carried out with Claude Code.

Soundness (rightfully rejected tests)

66 ✅ 5 ❌ 2 🚫

Completeness (rightfully accepted tests)

108 ✅ 1 ❌ 9 🚫

Corner cases (no outcome prescribed)

12 ✅ 0 🚫

Test	Expected	Result	⏱️		🧠
bogus1	✋	✋	107 ms		8.2 MB
cedar	👍	💥	1.1 m		429.0 MB
constlevels	✋	✋	125 ms		8.0 MB
cslib	👍	💥	1.1 m		427.7 MB
ctor-num-fields	✋	✋	138 ms		8.4 MB
extra-rec	✋	✋	43 ms		8.0 MB
init	👍	💥	1.1 m		425.3 MB
init-prelude	👍	👍	16.1 s	(×45)	33.9 MB	(÷2.2)
k-rec-conv	✋	✋	112 ms		8.1 MB
large-elim-param	✋	👍	86 ms		8.0 MB
large-elim-prop-bool	✋	👍	158 ms		8.4 MB
level-imax-leq	✋	✋	79 ms		8.3 MB
level-imax-normalization	✋	✋	79 ms		8.1 MB
level-index-out-of-order	👍	👍	46 ms		8.1 MB
mathlib	👍	💥	1.2 m		431.4 MB
nat-rec-k-lie	✋	✋	84 ms		8.1 MB
nat-rec-rules	✋	✋	93 ms		8.2 MB
nested-nonuniform-param	🤷	👍	101 ms		8.2 MB
nested-unused-param	✋	✋	310 ms		8.5 MB
orphan-ctor	✋	👍	57 ms		8.3 MB
orphan-rec	✋	✋	43 ms		8.1 MB
proj-non-structure	✋	🚫	83 ms		8.3 MB
proj-of-imax-prop	✋	✋	106 ms		8.2 MB
proj-of-prop	✋	🚫	78 ms		8.2 MB
proj-of-stuck-prop	✋	✋	867 ms		9.9 MB
proj-of-subst-prop	✋	✋	820 ms		10.1 MB
proof-irrel	👍	👍	68 ms		8.2 MB
rec-k-lie	✋	✋	83 ms		8.3 MB
rec-missing-ih	✋	✋	899 ms		10.3 MB
rec-of-subst-prop	✋	✋	836 ms		10.2 MB
sparse-name-index	👍	👍	46 ms		8.1 MB
std	👍	💥	1.2 m		444.5 MB
corner-cases/ (11 tests)		0	2.3 s		8.8 MB
alg-conv-trans-acc	🤷	✋	349 ms		8.7 MB
alg-conv-trans-acc-left	🤷	✋	354 ms		8.7 MB
alg-conv-trans-acc-right	🤷	👍	357 ms		8.7 MB
alg-conv-trans-quot	🤷	✋	77 ms		8.4 MB
alg-conv-trans-quot-left	🤷	✋	77 ms		8.3 MB
alg-conv-trans-quot-left-def	🤷	✋	86 ms		8.2 MB
alg-conv-trans-quot-right	🤷	👍	83 ms		8.2 MB
proj-maybe-prop	🤷	👍	96 ms		8.2 MB
proj-maybe-prop-past	🤷	👍	96 ms		8.3 MB
subject-reduction-redex	🤷	✋	349 ms		8.8 MB
subject-reduction-reduct	🤷	✋	344 ms		8.6 MB
perf/ (18 tests)		13	4.3 m	(×27)	525.5 MB
app-lam	👍	💥	1.2 m		19.6 MB
args-before-unfold	👍	👍	147 ms	(×4.1)	10.7 MB	(÷6.1)
beta-ladder	👍	💥	18.2 s		525.5 MB
church-numerals	👍	✋	136 ms		18.3 MB
discarded-argument	👍	👍	7.3 s	(×44)	16.7 MB	(÷3.9)
discarded-argument-match	👍	💥	1.1 m		313.6 MB
folded-constant-first	👍	👍	217 ms	(×5.4)	22.2 MB	(÷3.1)
folded-constant-last	👍	👍	216 ms	(×5.3)	22.1 MB	(÷3.1)
grind-ring-5	👍	💥	53.4 s		246.0 MB
identical-nesting	👍	👍	97 ms	(×3.5)	8.3 MB	(÷7.9)
irrelevance-before-evaluation	👍	👍	128 ms	(×4.5)	11.2 MB	(÷5.9)
let-ladder	👍	👍	31.6 s	(×31)	525.3 MB	(+64%)
refute-cheap-first	✋	✋	7.4 s		16.7 MB
refute-cheap-last	✋	✋	138 ms		10.9 MB
repeated-subproblem	👍	👍	101 ms	(×3.5)	8.1 MB	(÷8.1)
shared-subterm	👍	👍	309 ms	(×5.4)	26.2 MB	(÷2.8)
shift-cascade	👍	👍	317 ms	(×6.9)	12.2 MB	(÷5.6)
unroll-versus-evaluate	👍	👍	120 ms	(×3.9)	8.9 MB	(÷7.4)
tutorial/ (142 tests)		140	9.2 s	(×2.4)	8.9 MB
001_basicDef	👍	👍	46 ms		8.3 MB
002_badDef	✋	✋	42 ms		8.3 MB
003_arrowType	👍	👍	46 ms		8.2 MB
004_dependentType	👍	👍	46 ms		8.2 MB
005_constType	👍	👍	46 ms		8.2 MB
006_betaReduction	👍	👍	50 ms		8.3 MB
007_betaReduction2	👍	👍	50 ms		8.2 MB
008_forallSortWhnf	👍	👍	50 ms		8.3 MB
009_forallSortBad	✋	✋	47 ms		8.3 MB
010_nonTypeType	✋	✋	46 ms		8.3 MB
011_nonTypeAxiom	✋	✋	46 ms		8.4 MB
012_nonPropThm	✋	✋	42 ms		8.1 MB
013_thmProof	👍	👍	50 ms		8.1 MB
014_selfProof	✋	👍	46 ms		8.4 MB
015_levelComp1	👍	👍	46 ms		8.1 MB
016_levelComp2	👍	👍	46 ms		8.3 MB
017_levelComp3	👍	👍	46 ms		8.2 MB
018_levelParams	👍	👍	50 ms		8.1 MB
019_tut06_bad01	✋	✋	42 ms		8.1 MB
020_levelComp4	👍	👍	46 ms		8.1 MB
021_levelComp5	👍	👍	46 ms		8.2 MB
022_imax1	👍	👍	46 ms		8.2 MB
023_imax2	👍	👍	46 ms		8.2 MB
024_levelMaxComm	👍	👍	46 ms		8.3 MB
025_levelMaxAssoc	👍	👍	46 ms		8.2 MB
026_levelMaxIdem	👍	👍	46 ms		8.4 MB
027_levelMaxAbsorb	👍	👍	46 ms		8.2 MB
028_inferVar	👍	👍	46 ms		8.1 MB
029_defEqLambda	👍	👍	47 ms		8.2 MB
030_peano1	👍	👍	70 ms		8.3 MB
031_peano2	👍	👍	75 ms		8.2 MB
032_peano3	👍	👍	82 ms		8.2 MB
033_letType	👍	👍	46 ms		8.1 MB
034_letTypeDep	👍	👍	53 ms		8.2 MB
035_letRed	👍	👍	49 ms		8.3 MB
036_empty	👍	👍	54 ms		8.4 MB
037_boolType	👍	👍	62 ms		8.1 MB
038_twoBool	👍	👍	75 ms		8.2 MB
039_andType	👍	👍	59 ms		8.3 MB
040_prodType	👍	👍	60 ms		8.0 MB
041_pprodType	👍	👍	60 ms		8.2 MB
042_pUnitType	👍	👍	58 ms		8.2 MB
043_eqType	👍	👍	59 ms		8.3 MB
044_natDef	👍	👍	63 ms		8.3 MB
045_rbTreeDef	👍	👍	111 ms		8.6 MB
046_inductBadNonSort	✋	✋	46 ms		8.1 MB
047_inductBadNonSort2	✋	✋	46 ms		8.3 MB
048_inductLevelParam	✋	✋	42 ms		8.3 MB
049_inductTooFewParams	✋	✋	42 ms		8.2 MB
050_inductWrongCtorParams	✋	✋	54 ms		8.4 MB
051_inductWrongCtorResParams	✋	✋	50 ms		8.3 MB
052_inductWrongCtorResLevel	✋	✋	50 ms		8.1 MB
053_inductInIndex	✋	✋	54 ms		8.3 MB
054_indNeg	✋	✋	50 ms		8.3 MB
055_reduceCtorParam.mk	👍	👍	64 ms		8.2 MB
056_reduceCtorType.mk	✋	✋	54 ms		8.0 MB
057_indNegReducible	✋	✋	58 ms		8.1 MB
058_predWithTypeField	👍	👍	58 ms		8.3 MB
059_typeWithTypeField	👍	👍	58 ms		8.3 MB
060_typeWithTypeFieldPoly	👍	👍	58 ms		8.2 MB
061_typeWithTooHighTypeField.mk	✋	✋	50 ms		8.3 MB
062_emptyRec	👍	👍	54 ms		8.2 MB
063_boolRec	👍	👍	63 ms		8.1 MB
064_twoBoolRec	👍	👍	75 ms		8.4 MB
065_andRec	👍	👍	60 ms		8.3 MB
066_prodRec	👍	👍	60 ms		8.3 MB
067_pprodRec	👍	👍	60 ms		8.1 MB
068_punitRec	👍	👍	58 ms		8.2 MB
069_eqRec	👍	👍	59 ms		8.2 MB
070_nRec	👍	👍	63 ms		8.2 MB
071_rbTreeRef	👍	👍	112 ms		8.6 MB
072_boolPropRec	👍	👍	62 ms		8.3 MB
073_BogusRecursor	✋	👍	65 ms		8.4 MB
074_existsRec	👍	👍	60 ms		8.3 MB
075_typeSingletonRecReduction	👍	👍	92 ms		8.4 MB
076_sortElimPropRec	👍	👍	76 ms		8.2 MB
077_sortElimProp2Rec	👍	👍	81 ms		8.2 MB
078_boolRecEqns	👍	👍	92 ms		8.4 MB
079_prodRecEqns	👍	👍	77 ms		8.4 MB
080_nRecReduction	👍	👍	101 ms		8.2 MB
081_listRecReduction	👍	👍	111 ms		8.2 MB
082_RBTree.id_spec	👍	👍	166 ms		8.9 MB
083_And.right	👍	👍	64 ms		8.3 MB
084_Prod.snd	👍	👍	64 ms		8.3 MB
085_PProd.snd	👍	👍	64 ms		8.4 MB
086_PSigma.snd	👍	👍	65 ms		8.2 MB
087_projOutOfRange	✋	✋	57 ms		8.1 MB
088_projNotStruct	✋	✋	59 ms		8.2 MB
089_projProp1	👍	👍	86 ms		8.3 MB
090_projProp2	✋	✋	82 ms		8.3 MB
091_projProp3	👍	👍	86 ms		8.2 MB
092_projProp4	✋	✋	82 ms		8.3 MB
093_projProp5	✋	✋	83 ms		8.1 MB
094_projProp6	✋	✋	83 ms		8.1 MB
095_projDataIndexRec	👍	👍	88 ms		8.3 MB
096_projIndexData	✋	✋	84 ms		8.2 MB
097_projIndexData2	✋	✋	84 ms		8.1 MB
098_projRed	👍	👍	98 ms		8.3 MB
099_ruleK	👍	👍	77 ms		8.2 MB
100_ruleKbad	✋	✋	73 ms		8.3 MB
101_ruleKAcc	✋	✋	92 ms		8.0 MB
102_aNatLit	👍	👍	63 ms		8.4 MB
103_natLitEq	👍	👍	77 ms		8.3 MB
104_proofIrrelevance	👍	👍	64 ms		8.2 MB
105_proofIrrelevanceBad	✋	✋	61 ms		8.2 MB
106_proofIrrelevanceWhnf	👍	👍	69 ms		8.2 MB
107_unitEta1	👍	👍	80 ms		8.2 MB
108_unitEta2	👍	👍	76 ms		8.3 MB
109_unitEta3	👍	👍	76 ms		8.0 MB
110_indexedUnitEta	✋	✋	85 ms		8.3 MB
111_structEta	👍	👍	102 ms		8.2 MB
112_indexedStructEta	✋	✋	97 ms		8.2 MB
113_funEta	👍	👍	65 ms		8.2 MB
114_funEtaDep	👍	👍	65 ms		8.2 MB
115_funEtaBad	✋	✋	58 ms		8.4 MB
116_etaRuleK	✋	✋	73 ms		8.2 MB
117_etaCtor	✋	✋	101 ms		8.1 MB
118_reflOccLeft	✋	✋	67 ms		8.3 MB
119_reflOccInIndex	✋	✋	67 ms		8.3 MB
120_reduceCtorParamRefl.mk	👍	👍	64 ms		8.3 MB
121_reduceCtorParamRefl2.mk	👍	👍	64 ms		8.1 MB
122_rTreeRec	👍	👍	79 ms		8.2 MB
123_rtreeRecReduction	👍	👍	103 ms		8.2 MB
124_accRecType	👍	👍	64 ms		8.2 MB
125_accRecReduction	👍	👍	96 ms		8.4 MB
126_accRecNoEta	✋	✋	92 ms		8.2 MB
127_quotMkType	👍	👍	76 ms		8.3 MB
128_quotIndType	👍	👍	77 ms		8.3 MB
129_quotLiftType	👍	👍	77 ms		8.3 MB
130_quotSoundType	👍	👍	81 ms		8.4 MB
131_quotLiftReduction	👍	👍	79 ms		8.1 MB
132_quotIndReduction	👍	👍	78 ms		8.4 MB
133_dup_defs	✋	✋	42 ms		8.0 MB
134_dup_ind_def	✋	✋	43 ms		8.1 MB
135_dup_ctor_def	✋	✋	43 ms		8.0 MB
136_dup_rec_def	✋	✋	43 ms		8.2 MB
137_misnamed_rec_user	✋	✋	44 ms		7.9 MB
138_dup_rec_def2	✋	✋	43 ms		8.2 MB
139_dup_ctor_rec	✋	✋	43 ms		7.9 MB
140_DupConCon	✋	✋	44 ms		7.8 MB
141_falseFromUnsafe	✋	✋	50 ms		8.2 MB
142_falseFromPartial	✋	✋	50 ms		8.0 MB

Detailed results

Test "bogus1"

Expected: ✋ reject · Size: 11.4 KB · Lines: 198 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A clearly bogus proof. Also serves as an example for how to write simple cases.

Test result: ✋ rejected · exit code 1 · wall time: 100 ms · instructions: 641.3 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/16 arena=143
FAIL decl 15 name=thm kind=2

Test "cedar"

Expected: 👍 accept · Size: 790.9 MB · Lines: 14.6 M · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Lean formalization of, and proofs about, Cedar.

Auto-generated documentation is available at https://cedar-policy.github.io/cedar-spec/docs/.

This test case exports the whole Cedar module and as such contains even unused parts Init and Batteries.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 413.1 G · max rss memory: 429.0 MB

Test "constlevels"

Expected: ✋ reject · Size: 15.3 KB · Lines: 283 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Regression test for undefined behavior in lazy_delta_reduction_step in the official kernel

In the function lazy_delta_reduction_step, the official kernel expects unfold_definition to always succeed. However, if the constant has an incorrect number of level parameters, it actually fails, which leads to memory corruption in lazy_delta_reduction_step.

This test is to check that the official kernel and also other kernels that closely follow the logic of the official kernel correctly handle this unfolding failure.

The issue in the official kernel was originally reported as https://github.com/leanprover/lean4/issues/10577.

Test result: ✋ rejected · exit code 1 · wall time: 65 ms · instructions: 749.9 M · max rss memory: 8.0 MB

stdout:

Checking decl 0/20 arena=204
FAIL decl 19 name=_test kind=2

Test "corner-cases/alg-conv-trans-acc"

Expected: 🤷 either · Size: 66.0 KB · Lines: 1.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

As Lean's type theory has undecidable conversion (a.k.a. definitional equality), there are bound to be gaps between so called "algorithmic" conversion (that which is implemented by a typechecker), and the "declarative" conversion.

In the official kernel, algorithmic conversion fails to be transitive. f 1 a is a normal form: a is a variable, so Acc.rec cannot fire on it. Proof irrelevance admits any other proof of Acc (· < ·) 1 in its place, and Acc.intro 1 fun _ => Acc.inv a carries a constructor at the head, so it reduces. left is that substitution, right the reduction it unblocks, and trans chains the two.

acc asks for the endpoints on their own, which means inventing the middle term: choosing, among the proofs of a proposition, the one that happens to reduce the right way. The kernel has no reason to go looking, the left side being normal already, and unfolding regardless does not terminate here, as each step makes the term larger.

References:

Mario Carneiro, The Type Theory of Lean, MSc thesis

Test result: ✋ rejected · exit code 1 · wall time: 155 ms · instructions: 2.1 G · max rss memory: 8.7 MB

stdout:

Checking decl 0/66 arena=917
FAIL decl 65 name=trans kind=2

Test "corner-cases/alg-conv-trans-acc-left"

Expected: 🤷 either · Size: 67.0 KB · Lines: 1.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The creative half of corner-cases/alg-conv-trans-acc. Acc.rec is stuck on the variable a, and proof irrelevance admits any other proof of Acc (· < ·) 1 in its place, including one with a constructor at the head. Given both sides, a checker verifies this immediately; producing the right-hand side unprompted is the step no algorithm takes.

Test result: ✋ rejected · exit code 1 · wall time: 152 ms · instructions: 2.1 G · max rss memory: 8.7 MB

stdout:

Checking decl 0/67 arena=931
FAIL decl 66 name=left kind=2

Test "corner-cases/alg-conv-trans-acc-right"

Expected: 🤷 either · Size: 67.3 KB · Lines: 1.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The mechanical half of corner-cases/alg-conv-trans-acc. With a constructor in the major premise, Acc.rec fires and step descends to the predecessor 0.

Test result: 👍 accepted · exit code 0 · wall time: 156 ms · instructions: 2.1 G · max rss memory: 8.7 MB

stdout:

Checking decl 0/67 arena=938

Test "corner-cases/alg-conv-trans-quot"

Expected: 🤷 either · Size: 8.5 KB · Lines: 169 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

left composed with right. Quotients of propositions cause algorithmic conversion transitivity to fail because the typechecker must creatively synthesise the representative of the quotient, and proof irrelevance is definitional.

References:

Mario Carneiro, The Type Theory of Lean, MSc thesis

Test result: ✋ rejected · exit code 1 · wall time: 44 ms · instructions: 461.3 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/8 arena=127
FAIL decl 7 name=trans kind=2

Test "corner-cases/alg-conv-trans-quot-left"

Expected: 🤷 either · Size: 8.6 KB · Lines: 173 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Quot r is a Prop, so proof irrelevance relates q and Quot.mk r z. However the official kernel does WHNF first, reducing the right side to f z, so congruence never compares the arguments.

Test result: ✋ rejected · exit code 1 · wall time: 42 ms · instructions: 462.5 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/8 arena=131
FAIL decl 7 name=left kind=2

Test "corner-cases/alg-conv-trans-quot-left-def"

Expected: 🤷 either · Size: 10.5 KB · Lines: 208 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

left with Quot.lift behind a definition. WHNF does not unfold lift, so the arguments are compared and proof irrelevance applies.

Test result: ✋ rejected · exit code 1 · wall time: 56 ms · instructions: 517.3 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/10 arena=160
FAIL decl 9 name=left' kind=2

Test "corner-cases/alg-conv-trans-quot-right"

Expected: 🤷 either · Size: 9.0 KB · Lines: 180 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Quotient computation rule.

Test result: 👍 accepted · exit code 0 · wall time: 47 ms · instructions: 500.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/9 arena=136

Test "corner-cases/proj-maybe-prop"

Expected: 🤷 either · Size: 8.1 KB · Lines: 131 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Projecting out of a structure that may or may not be a proposition.

MaybeProp is a structure whose sort is a bare level parameter: a proposition for u := 0 and a data type for every other u. Lean's inductive command refuses to declare one ("the resulting universe is not Prop, but it may be Prop for some parameter values"), but the kernel accepts it. The exported definition projects out its first field, field : PUnit.{u}.

The official kernel accepts this. The field is not a proof for every u, but the projection is sound at every instantiation: MaybeProp.{u} is a proposition only for u := 0, and there the field's type PUnit.{0} is a proposition too. That is no coincidence. A structure that is not a Prop had every constructor field's universe checked against its resulting universe (see the tutorial's typeWithTooHighTypeField), here u ≤ u, and such an inequality survives instantiation — so wherever the structure does turn out to be a proposition, so do all of its fields.

At the same time, the official kernel here allows more projections than the recursor allows: MaybeProp.rec eliminates into Prop only, so this projection cannot be expressed through the recursor. The elaborator does not currently rely on this extra power, so for now it is reasonable for a checker to be more restrictive here and reject the projection — for example by asking "could this be a proposition?" and then demanding that the field be definitely a proof. See https://github.com/leanprover/lean4/issues/7637 for discussion.

Test result: 👍 accepted · exit code 0 · wall time: 50 ms · instructions: 578.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/13 arena=92

Test "corner-cases/proj-maybe-prop-past"

Expected: 🤷 either · Size: 8.1 KB · Lines: 131 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The same as corner-cases/proj-maybe-prop, for a projection that only has to step over such a field.

MaybeProp.tail is a proof for every u, so the field asked for here is unobjectionable even under the restrictive reading. But reaching it means walking past field, which proof depends on, and that is where the check on a genuine proposition (the tutorial's projProp6) fires. A checker that rejects corner-cases/proj-maybe-prop therefore rejects this one as well, at field 0 rather than at field 2, and that remains a reasonable choice for the same reason. See https://github.com/leanprover/lean4/issues/7637 for discussion.

Test result: 👍 accepted · exit code 0 · wall time: 58 ms · instructions: 578.6 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/13 arena=92

Test "corner-cases/subject-reduction-redex"

Expected: 🤷 either · Size: 66.2 KB · Lines: 1.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Test for subject reduction, as in Carneiro's thesis.

The annotation on the lambda writes the middle term of corner-cases/alg-conv-trans-acc down by hand, sparing the kernel from having to invent it. The body checks against right, the argument against left, and the two endpoints are never compared.

References:

Mario Carneiro, The Type Theory of Lean, MSc thesis

Test result: ✋ rejected · exit code 1 · wall time: 150 ms · instructions: 2.1 G · max rss memory: 8.8 MB

stdout:

Checking decl 0/66 arena=921
FAIL decl 65 name=redex kind=1

Test "corner-cases/subject-reduction-reduct"

Expected: 🤷 either · Size: 65.2 KB · Lines: 1.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Beta erases the annotation of corner-cases/subject-reduction-redex, and with it the middle term, leaving the two endpoints to compare: the conversion of corner-cases/alg-conv-trans-acc. A term the kernel accepts thus reduces to one it rejects.

References:

Mario Carneiro, The Type Theory of Lean, MSc thesis

Test result: ✋ rejected · exit code 1 · wall time: 153 ms · instructions: 2.1 G · max rss memory: 8.6 MB

stdout:

Checking decl 0/65 arena=903
FAIL decl 64 name=reduct kind=1

Test "cslib"

Expected: 👍 accept · Size: 2.0 GB · Lines: 37.5 M · lean4export: 3.1.0 · Lean: 4.30.0 · 📄 Declaration · 🔗 Source

The Lean Computer Science Library (CSLib).

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 411.3 G · max rss memory: 427.7 MB

Test "ctor-num-fields"

Expected: ✋ reject · Size: 34.1 KB · Lines: 622 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Proof of False via trusted numFields on a constructor.

Define a wrapper structure S with one field, and lie by saying it has 0 fields, making it look unit-like. Then definitional eta means all inhabitants are equal.

Derive a contradiction from S.mk false = S.mk true.

Test result: ✋ rejected · exit code 1 · wall time: 75 ms · instructions: 825.5 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/40 arena=465
FAIL decl 18 name=_private.Test.0.S kind=5

Test "extra-rec"

Expected: ✋ reject · Size: 1.4 KB · Lines: 21 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False from an extra recursor that no inductive declaration could produce.

The export contains False exactly as the prelude has it — an empty Prop-valued inductive with no constructors — together with its ordinary False.rec. Smuggled into the same inductive group is a second recursor, named rogue, whose type is False itself and which has no motives, no minor premises and no rules. The theorem inconsistent : False is then simply rogue.

A checker must derive the recursors of an inductive group from the inductive declaration and reject any exported recursor that is not one of them; here that fails on the name (rogue is not False.rec) as well as on the type. A checker that instead registers exported recursors as given ends up with an inhabitant of the genuine empty type.

This is a different gap from nat-rec-rules, which perturbs the rules of a legitimate recursor: here an entire recursor constant is fabricated, so validating only the rules of the recursors one expects does not catch it.

Test result: ✋ rejected · exit code 1 · wall time: 29 ms · instructions: 258.6 M · max rss memory: 8.0 MB

stderr:

error: duplicate or invalid declaration metadata

Test "init"

Expected: 👍 accept · Size: 309.5 MB · Lines: 6.1 M · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The Init module export from Lean 4 core.

This test contains the fundamental building blocks of Lean 4, including:

Basic data types (Nat, List, Array, String, etc.)
Core tactics and syntax
Foundational mathematical structures
Essential metaprogramming infrastructure

This is one of the smallest meaningful test cases, making it ideal for initial checker validation and debugging.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 411.1 G · max rss memory: 425.3 MB

Test "init-prelude"

Expected: 👍 accept · Size: 3.5 MB · Lines: 63.7 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The Init.Prelude module export.

Test result: 👍 accepted · exit code 0 · wall time: 6.9 s · instructions: 96.9 G · max rss memory: 33.9 MB

stdout:

Checking decl 0/2059 arena=54535
Checking decl 100/2059 arena=54535
Checking decl 200/2059 arena=54535
Checking decl 300/2059 arena=54535
Checking decl 400/2059 arena=54535
Checking decl 500/2059 arena=54535
Checking decl 600/2059 arena=54535
Checking decl 700/2059 arena=54535
Checking decl 800/2059 arena=54535
Checking decl 900/2059 arena=54535
Checking decl 1000/2059 arena=54535
Checking decl 1100/2059 arena=54535
Checking decl 1200/2059 arena=54535
Checking decl 1300/2059 arena=54535
Checking decl 1400/2059 arena=54535
Checking decl 1500/2059 arena=54535
Checking decl 1600/2059 arena=54535
Checking decl 1700/2059 arena=54535
Checking decl 1800/2059 arena=54535
Checking decl 1900/2059 arena=54535
Checking decl 2000/2059 arena=54535

Test "k-rec-conv"

Expected: ✋ reject · Size: 13.0 KB · Lines: 243 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Bogus proof that tests for incorrectly implemented K-like reduction.

fun x => x and fun _ => y are not convertible, but a checker that does treat them as convertible would accept the resulting theorem bad, which is true propositionally, but not definitionally.

Regression test for sokonanoda.

Test result: ✋ rejected · exit code 1 · wall time: 57 ms · instructions: 673.0 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/17 arena=167
FAIL decl 16 name=bad kind=2

Test "large-elim-param"

Expected: ✋ reject · Size: 6.2 KB · Lines: 88 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False via incorrect large elimination restriction.

If the check for whether a level is surely not zero is implemented wrong, in particular if it incorrectly returns true for params, we can create a universe-polymorphic

inductive MyBool.{u} : Sort u | tt | ff

where the recursor MyBool.rec.{1,0} can do large elimination of a Prop. Because of proof irrelevance we have tt = ff, so we can derive a contradiction.

Found by Anthony Wang using Aristotle.

Test result: 👍 accepted · exit code 0 · wall time: 47 ms · instructions: 517.6 M · max rss memory: 8.0 MB

stdout:

Checking decl 0/11 arena=58

Test "large-elim-prop-bool"

Expected: ✋ reject · Size: 22.6 KB · Lines: 438 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Proof of False by allowing a Prop inductive to have the same recursor that the corresponding Type inductive would have.

Proof irrelevance makes .tt = .ff, but pick distinguishes between them.

Test result: 👍 accepted · exit code 0 · wall time: 74 ms · instructions: 946.6 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/26 arena=318

Test "level-imax-leq"

Expected: ✋ reject · Size: 5.6 KB · Lines: 93 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False via incorrect universe level comparison for imax.

A correct kernel must reject leq(imax(u,v)+1, imax(u,v)), since at u=0, v=0 this becomes leq(1, 0) which is false. However, a checker that only compares the imax arguments structurally (without accounting for an accumulated successor offset) will incorrectly accept it.

This allows defining a universe-collapsing identity function down.{u,v} : Sort (succ (imax u v)) → Sort (imax u v), which is used to cast between True and False via Bool.rec at Sort (imax 0 0) = Prop.

Nanoda incorrectly accepted this proof until it was fixed.

Test result: ✋ rejected · exit code 1 · wall time: 43 ms · instructions: 475.8 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/11 arena=59
FAIL decl 9 name=down kind=1

Test "level-imax-normalization"

Expected: ✋ reject · Size: 5.8 KB · Lines: 96 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False via incorrect universe level normalization for imax.

A correct kernel must distinguish imax 0 v from succ(imax 0 v), since at v=0 these evaluate to 0 and 1 respectively. However, a level normalization algorithm that drops an accumulated successor offset when decomposing imax u (param v) will produce identical normal forms for both, causing the equivalence check to incorrectly return true.

This allows defining a universe-collapsing identity function down.{v} : Sort (succ (imax 0 v)) → Sort (imax 0 v), and then myProp : Prop := down.{0} Bool (a Prop that is computationally Bool). Proof irrelevance on myProp equates Bool.true and Bool.false, and Bool.rec maps this into False.

Test result: ✋ rejected · exit code 1 · wall time: 48 ms · instructions: 476.3 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/12 arena=60
FAIL decl 9 name=down kind=1

Test "level-index-out-of-order"

Expected: 👍 accept · Size: 328 B · Lines: 6 · lean4export: 0.1.0 · Lean: 4.29.1 · 📄 Declaration

Lean4export will create internalization-table references contiguously in order: in references for names, il references for levels, and ie references for expressions all work this way.

However, the spec merely requires that these are integers. It's reasonable for an implementation to assume these are approximately dense (and to treat them as array indices instead of hashtable entries), but a kernel should handle skipped indices or out-of-order indices.

This test checks that the kernel doesn't require internaliation-table references to be presented in ascending order. If the level referenes 2 and 1 were swapped, this would be the expected encoding of axiom foo : Sort 2. This encoding should be equivalent.

Test result: 👍 accepted · exit code 0 · wall time: 31 ms · instructions: 273.8 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=1

Test "mathlib"

Expected: 👍 accept · Size: 5.2 GB · Lines: 100.0 M · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The complete Mathlib library export.

This test contains all the mathematical definitions, theorems, and proofs from Mathlib, representing the largest and most comprehensive test case in the Lean kernel arena.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 420.3 G · max rss memory: 431.4 MB

Test "nat-rec-k-lie"

Expected: ✋ reject · Size: 6.3 KB · Lines: 106 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False via trusted k on Nat.rec.

Lie by claiming Nat.rec is K-like. Then replace the major premise by Nat.zero, but nat literals bypasses K-like reduction, so two reduction rules disagree.

∀ n, g n holds by the first, and g 1 is False by the second.

Test result: ✋ rejected · exit code 1 · wall time: 41 ms · instructions: 502.2 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/12 arena=67
FAIL decl 10 name=k1 kind=2

Test "nat-rec-rules"

Expected: ✋ reject · Size: 8.1 KB · Lines: 128 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False via incorrect recursor rule validation.

When processing an inductive type declaration, a correct kernel must verify that the generated recursor rules match the ones provided in the export data. A checker that accidentally compares the imported rules against themselves (instead of against independently constructed rules) will accept arbitrary recursor reduction behavior.

This test defines Nat with a wrong Nat.rec succ rule that always returns hzero (ignoring the induction hypothesis). Combined with a nat literal extension that hardcodes correct arithmetic for concrete nat literals but falls back to the wrong Nat.rec rules for symbolic arguments, this creates an inconsistency that yields a proof of False.

Nanoda incorrectly accepted this proof until it was fixed.

Test result: ✋ rejected · exit code 1 · wall time: 48 ms · instructions: 555.9 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/15 arena=92
FAIL decl 12 name=Nat kind=5

Test "nested-nonuniform-param"

Expected: 🤷 either · Size: 9.2 KB · Lines: 142 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Checks that a parameter supplied to a nested inductive occurrence really acts as the datatype's parameter, i.e. that it is the parameter itself and does not change between recursive occurrences (as is already enforced for non-nested occurrences).

The inductive E : W → Type has constructor E.mk : (w : W) → L (E ⟨false⟩) → E w, where L (α : Type) is nested. The occurrence E ⟨false⟩ inside the nested L uses the constant ⟨false⟩ in the position of E's parameter, instead of the actual parameter w. That argument is type-correct, so it is not caught by merely type-checking the nested application (leanprover/lean4#14577); a correct checker must also verify that it is the expected parameter.

This particular declaration is not known to yield a proof of False: here L stores no value of type α, so the nested occurrence is phantom and E w is isomorphic to Unit for every w. The variant where L actually stores an α (so recursion would descend into an E ⟨false⟩ while the motive is fixed at E w) is already rejected by the kernel's positivity check ("non valid occurrence"). Since it is not a demonstrated unsoundness, it is not settled whether a checker should accept or reject it, so the expected outcome is either and the test does not count towards completeness or soundness.

Origin: raised by @arthur-adjedj on leanprover/lean4#14577 (https://github.com/leanprover/lean4/pull/14577#issuecomment-5101819377) as a case not covered by that PR's fix; related to leanprover/lean4#14576.

Test result: 👍 accepted · exit code 0 · wall time: 51 ms · instructions: 607.8 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/14 arena=108

Test "nested-unused-param"

Expected: ✋ reject · Size: 59.2 KB · Lines: 1.1 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Checks that the parameters of a nested inductive application are type-checked even when they do not appear in the auxiliary type generated during nested-inductive compilation.

When an inductive E has a constructor whose type contains a nested application L (E w) b, the elaboration of nested inductives replaces that occurrence with an auxiliary type. The argument b does not occur in the auxiliary declaration, so a checker that only checks the auxiliary type never sees b. A correct checker must still ensure b is well-typed; this test rejects if it is not.

Here b is a malformed projection C.0 (C.0 w) (applying a C projection to a value of the unrelated structure W), disguised by a hash collision. If the parameter is not checked, the bogus projection slips through and the resulting E can be used to build an axiom-free proof of False (boom). The projection is merely the payload; the property under test is that the nested-inductive parameter is checked.

Origin: reported as leanprover/lean4#14576 by @kiranandcode, with the original source recorded by @xrchz (https://github.com/xrchz/collatzlean); fixed in leanprover/lean4#14577.

Test result: ✋ rejected · exit code 1 · wall time: 136 ms · instructions: 1.9 G · max rss memory: 8.5 MB

stdout:

Checking decl 0/63 arena=811
FAIL decl 58 name=E kind=5

Test "orphan-ctor"

Expected: ✋ reject · Size: 1.4 KB · Lines: 22 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False from a constructor of an inductive type that does not exist.

The export contains False exactly as the prelude has it — an empty Prop-valued inductive with no constructors, its ctors field is the empty list — together with its ordinary False.rec. Smuggled into the same inductive block is a constructor named rogue, of type False, with no parameters and no fields, whose induct field names Orphan, a name for which the export has no declaration at all. The theorem inconsistent : False is then simply rogue.

A checker must derive the constructors of an inductive group from the inductive declarations and reject any exported constructor that is not one of them; here that fails because False has no constructors, and the inductive type rogue claims to come from does not exist. A checker that instead registers exported constructors as given — or that only checks constructors whose induct field points at a declaration it knows — ends up with an inhabitant of the genuine empty type.

This is the constructor-side counterpart of orphan-rec: in both cases the bogus declaration escapes by not being attached to any inductive declaration that the checker verifies, rather than by disagreeing with one.

Test result: 👍 accepted · exit code 0 · wall time: 34 ms · instructions: 343.9 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/4 arena=10

Test "orphan-rec"

Expected: ✋ reject · Size: 1.4 KB · Lines: 21 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False from a recursor that claims not to belong to any inductive type.

The export contains False exactly as the prelude has it — an empty Prop-valued inductive with no constructors — together with its ordinary False.rec. Smuggled into the same inductive block is a second recursor, named rogue, whose type is False itself, which has no motives, no minor premises and no rules, and whose all field is the empty list. The theorem inconsistent : False is then simply rogue.

This is the sibling of extra-rec, and it defeats the obvious fix for it. A checker that associates each exported recursor with the inductive type named in its all field, and then requires the recursors so associated with an inductive type to be exactly the ones it derives from that declaration, still accepts rogue: False is associated with False.rec and nothing else, and rogue is associated with nothing at all, so no comparison ever looks at it — yet it is added to the environment and inhabits the genuine empty type.

A checker must therefore reject any recursor it did not itself derive from an inductive declaration, rather than only checking the recursors that point at one. The same hole is reachable by pointing all at a name that has no declaration in the export (that variant is what orphan-ctor does on the constructor side).

Nanoda accepted this export until it was fixed.

Test result: ✋ rejected · exit code 1 · wall time: 27 ms · instructions: 258.6 M · max rss memory: 8.1 MB

stderr:

error: duplicate or invalid declaration metadata

Test "perf/app-lam"

Expected: 👍 accept · Size: 1.2 MB · Lines: 28.6 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A synthetically generated term with n levels of alternating applications and lambdas, with DAG sharing.

At each level, a constant is applied to two identical lambda arguments. The export format records these as a single shared expression (DAG). Each lambda body grows with the nesting depth, referencing all enclosing binders.

This tests two aspects of checker performance:

Infer cache: Since both arguments at each level are the same expression, a checker without an infer cache re-infers the type of each shared subterm, doubling work at every level — O(2ⁿ) total.

Substitution cost: Even with a cache, type-inferring each lambda requires substituting into its body (size O(n)) at each of the n levels, giving O(n²) total. Whether this cost arises depends on the checker's binder representation.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 431.0 G · max rss memory: 19.6 MB

stdout:

Checking decl 0/34 arena=24427

Test "perf/args-before-unfold"

Expected: 👍 accept · Size: 44.5 KB · Lines: 1.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

count #n      and      count (N.add #(n-1) #1)

where #k is the numeral with k successors, and count #k evaluates to #k in Θ(k²) reductions.

N.add #(n-1) #1 reduces to #n in n steps, so the two arguments agree for Θ(n), and the applications agree with them without count ever being unfolded. Evaluating both applications costs Θ(n²). The test asks whether a checker tries the arguments of a shared head constant before unfolding it.

N=1000 in the Lean source. From Courant and Leroy, POPL 2026, §10.

Test result: 👍 accepted · exit code 0 · wall time: 70 ms · instructions: 879.9 M · max rss memory: 10.7 MB

stdout:

Checking decl 0/10 arena=1106

Test "perf/beta-ladder"

Expected: 👍 accept · Size: 450.2 KB · Lines: 10.4 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check reduces

(fun x₁ => … (fun xₙ => x₁ + (x₂ + (… + (xₙ + 0)))) 0 …) 0

to 0, through n beta redexes over a body that reads every binder.

Reducing the ladder takes n beta steps whatever a checker does, so the test is what one step costs. Substituting into the body on entry to binder k copies the n − k redexes still below it, and those copies sum to Θ(n²). Carrying the substitution in an environment leaves the body untouched, for Θ(n).

N=2000 in the Lean source.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 109.0 G · max rss memory: 525.5 MB

stdout:

Checking decl 0/20 arena=10281

Test "perf/church-numerals"

Expected: 👍 accept · Size: 9.6 KB · Lines: 227 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

cmul (cnum n) (cnum (n+1))      and      cmul (cnum (n+1)) (cnum n)

where cnum k is the Church numeral fun X s z => s (s (... z)) and cmul a b iterates b as many times as a counts.

Both sides have the normal form with n(n+1) applications of the bound s. Unfolding cmul on the left leaves cnum n X (cnum (n+1) X s), where each of the n occurrences of the bound function copies the redex cnum (n+1) X s, so the normal form takes n(n+1) beta steps and shares nothing. No other delta step is available, so the Θ(n²) measured is beta reduction under binders and little else.

N=120 in the Lean source, giving a reduction depth of 14520. From the conv_eval benchmark of András Kovács' smalltt.

Test result: ✋ rejected · exit code 1 · wall time: 86 ms · instructions: 814.8 M · max rss memory: 18.3 MB

stdout:

Checking decl 0/6 arena=197
FAIL decl 5 name=kernel_church_numerals kind=2

Test "perf/discarded-argument"

Expected: 👍 accept · Size: 15.9 KB · Lines: 367 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

dropArg (count #n)      and      dropArg (count #(n+1))

where count #k evaluates to the numeral #k in Θ(k²) reductions, and dropArg maps every numeral to N.O.

Unfolding dropArg leaves N.O against N.O, for Θ(1). Comparing the arguments first evaluates two numerals of different value, for Θ(n²), and then throws that answer away. The test asks whether a checker unfolds a constant before looking at an argument the constant never uses.

N=200 in the Lean source. From Courant and Leroy, POPL 2026, §10.

Test result: 👍 accepted · exit code 0 · wall time: 3.6 s · instructions: 44.1 G · max rss memory: 16.7 MB

stdout:

Checking decl 0/11 arena=309
DIAG decl 10 name=kernel_discarded_argument kind=2 r=0 peak=3378 delta=3069 fuel=1394629 infer_u=624 deq_full=1394005 deq_one=20705 cong_hit=1 cong_ft=20502 ld_iter=20908 whnf_nd=41816 dfull{app=2747000,lf=6,prj=0,pi=0,eta=0,lf=20504,ee=0,pr=0} tags=[0,0,8,612,3,0,0,0,0,0,1,0,0,0,0,0]

Test "perf/discarded-argument-match"

Expected: 👍 accept · Size: 28.6 KB · Lines: 596 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

discarded-argument.lean with count and N.add written by structural recursion, so the declaration to check is the same

dropArg (count #n)      and      dropArg (count #(n+1))

over definitions that unfold through brecOn rather than through N.rec.

brecOn reduces via the course-of-values table N.below #k = m #(k-1) ×' (m #(k-2) ×' (… ×' PUnit)), a k-deep tuple holding the result at every predecessor. The compiled count reads only x.1, so the rest of the table is built and never read, and typing each projection forces N.below to the depth of that projection.

N=200 in the Lean source, matching its pair.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 397.8 G · max rss memory: 313.6 MB

stdout:

Checking decl 0/24 arena=490

Test "perf/folded-constant-first"

Expected: 👍 accept · Size: 52.0 KB · Lines: 1.3 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

tagged (count #n)      and      (false, count #n)

where tagged m = (isZero m, m), so unfolding the left side leaves the same application count #n in both components, forced by isZero in one and plain in the other.

The plain occurrences are identical, for Θ(1); the forced one evaluates count #n once. The order matters for a checker that leaves a constant unfolded once it reduces it: reducing the forced component first replaces count #n by its value on one side, and the plain comparison then faces a folded application against an evaluated one. Here the forcing component comes first; folded-constant-last.lean swaps them, and the ratio between the two files is what that costs.

N=1000 in the Lean source. From Courant and Leroy, POPL 2026, §10, where the two orders cost Rocq 3 × 10⁻⁵ s and 0.078 s.

Test result: 👍 accepted · exit code 0 · wall time: 101 ms · instructions: 1.3 G · max rss memory: 22.2 MB

stdout:

Checking decl 0/19 arena=1180

Test "perf/folded-constant-last"

Expected: 👍 accept · Size: 51.0 KB · Lines: 1.3 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

tagged (count #n)      and      (count #n, false)

where tagged m = (m, isZero m): folded-constant-first.lean with the components swapped, so the plain occurrences of count #n are compared before anything forces the application.

N=1000 in the Lean source. From Courant and Leroy, POPL 2026, §10.

Test result: 👍 accepted · exit code 0 · wall time: 100 ms · instructions: 1.3 G · max rss memory: 22.1 MB

stdout:

Checking decl 0/19 arena=1180

Test "perf/grind-ring-5"

Expected: 👍 accept · Size: 9.7 MB · Lines: 199.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A grind tactic test from the Lean 4 test suite.

This produces a theorem with a rather large proof term that needs fast reduction.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 320.3 G · max rss memory: 246.0 MB

stdout:

Checking decl 0/2432 arena=180991
Checking decl 100/2432 arena=180991
Checking decl 200/2432 arena=180991
Checking decl 300/2432 arena=180991
Checking decl 400/2432 arena=180991
Checking decl 500/2432 arena=180991
Checking decl 600/2432 arena=180991
Checking decl 700/2432 arena=180991
Checking decl 800/2432 arena=180991
Checking decl 900/2432 arena=180991
Checking decl 1000/2432 arena=180991
Checking decl 1100/2432 arena=180991
Checking decl 1200/2432 arena=180991
Checking decl 1300/2432 arena=180991
Checking decl 1400/2432 arena=180991
Checking decl 1500/2432 arena=180991
Checking decl 1600/2432 arena=180991
Checking decl 1700/2432 arena=180991
Checking decl 1800/2432 arena=180991
Checking decl 1900/2432 arena=180991
Checking decl 2000/2432 arena=180991
Checking decl 2100/2432 arena=180991
Checking decl 2200/2432 arena=180991
Checking decl 2300/2432 arena=180991
Checking decl 2400/2432 arena=180991

Test "perf/identical-nesting"

Expected: 👍 accept · Size: 8.7 KB · Lines: 172 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

f4 (f4 (... (f4 N.O) ...))      and      f4 (f4 (... (f4 N.O) ...))

n applications of f4 on each side, the same term twice, where f0 is the identity on N and each of f1, f2, f3, f4 applies its predecessor twice, so the nesting expands into 16n applications of f0.

The test asks whether a checker compares the two sides before it starts unfolding, which answers in Θ(n). Unfolding one side at a time offers 16n applications to choose from per side, and the reachable pairs of partially unfolded sides grow exponentially in n.

N=30 in the Lean source. From Courant and Leroy, POPL 2026, §10.

Test result: 👍 accepted · exit code 0 · wall time: 48 ms · instructions: 579.8 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/13 arena=128

Test "perf/irrelevance-before-evaluation"

Expected: 👍 accept · Size: 17.5 KB · Lines: 389 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check is

slowTriv (count #n) = True.intro

proved by Eq.refl, where slowTriv m : True recurses over m, so forcing it to a constructor evaluates the numeral in Θ(n²) reductions.

Checking compares the two proofs as arguments of Eq, whose head is rigid: nothing can be unfolded instead. Proof irrelevance settles the proofs by their type for Θ(1); evaluating the left one to a constructor costs Θ(n²) and yields the answer irrelevance already gave. The test asks whether a checker consults proof irrelevance before it reduces.

N=200 in the Lean source.

Test result: 👍 accepted · exit code 0 · wall time: 60 ms · instructions: 768.4 M · max rss memory: 11.2 MB

stdout:

Checking decl 0/14 arena=325

Test "perf/let-ladder"

Expected: 👍 accept · Size: 457.3 KB · Lines: 10.4 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check has type Nat and value

let x₃ := 0; x₃ + (let x₂ := 0; x₂ + (let x₁ := 0; x₁ + (x₃ + (x₂ + (x₁ + 0)))))

shown at n=3: n let bindings, each separated from the next by an addition, over an innermost sum that names every binding.

Substituting a binding into the body before checking it traverses O(n) nodes at each of the n bindings, for Θ(n²) in time and in allocated nodes. Recording the binding and reading it where the body names it costs O(1) per binding, for Θ(n).

The additions are what keep the bindings apart: a run of adjacent lets could be opened by a single substitution; not so here. Nat.add is the only application head, so no beta reduction is involved.

N=2000 in the Lean source.

Test result: 👍 accepted · exit code 0 · wall time: 23.0 s · instructions: 189.8 G · max rss memory: 525.3 MB

stdout:

Checking decl 0/22 arena=10292
DIAG decl 21 name=kernel_quadratic_let_ladder kind=1 r=0 peak=6011302 delta=6001010 fuel=6010 infer_u=6010 deq_full=0 deq_one=0 cong_hit=0 cong_ft=0 ld_iter=0 whnf_nd=0 dfull{app=0,lf=0,prj=0,pi=0,eta=0,lf=0,ee=0,pr=0} tags=[0,0,4,4005,0,0,2000,1,0,0,0,0,0,0,0,0]

Test "perf/refute-cheap-first"

Expected: ✋ reject · Size: 20.7 KB · Lines: 439 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check claims

(false, count #n) = (true, count #(n+1))

and must be rejected. Both sides are constructor applications, so comparing components is the only route, and either component refutes on its own: false against true for Θ(1), the numerals for Θ(n²) (count #k evaluates to #k in Θ(k²) reductions). The test asks in which order a checker visits the components. refute-cheap-last.lean swaps them, and the ratio between the two files is what that order costs.

N=200 in the Lean source. From Courant and Leroy, POPL 2026, §10, where the two orders cost Rocq 4 × 10⁻⁶ s and 0.61 s.

Test result: ✋ rejected · exit code 1 · wall time: 3.5 s · instructions: 44.2 G · max rss memory: 16.7 MB

stdout:

Checking decl 0/17 arena=367
FAIL decl 16 name=kernel_refute_cheap_first kind=2

Test "perf/refute-cheap-last"

Expected: ✋ reject · Size: 20.5 KB · Lines: 439 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check claims

(count #n, false) = (count #(n+1), true)

and must be rejected: refute-cheap-first.lean with the components swapped, so the cheap refutation sits behind the expensive one for a checker that visits components left to right.

N=200 in the Lean source. From Courant and Leroy, POPL 2026, §10.

Test result: ✋ rejected · exit code 1 · wall time: 65 ms · instructions: 826.0 M · max rss memory: 10.9 MB

stdout:

Checking decl 0/17 arena=367
FAIL decl 16 name=kernel_refute_cheap_last kind=2

Test "perf/repeated-subproblem"

Expected: 👍 accept · Size: 11.4 KB · Lines: 214 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

perfect #n leaf      and      perfect #(n-1) (node leaf leaf)

where perfect #k t builds the perfect binary tree of depth k with leaves t, in k steps that each duplicate the tree so far into both arguments of Tr.node.

Both sides reduce to the perfect tree of depth n. Descending them meets Tr.node u u against Tr.node v v at every level, where both argument positions pose the same subproblem, so the recursion reaches 2^n pairs of nodes of which n are distinct. The test asks whether a checker records the pairs it has proved convertible: Θ(n) if it does, Θ(2ⁿ) if not.

N=20 in the Lean source, stepped up by one rather than doubled. From Courant and Leroy, POPL 2026, §10.

Test result: 👍 accepted · exit code 0 · wall time: 47 ms · instructions: 603.9 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/13 arena=162

Test "perf/shared-subterm"

Expected: 👍 accept · Size: 50.1 KB · Lines: 1.3 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

ldepth (perfect #n leaf)      and      ldepth2 (perfect #n leaf)

where perfect #n leaf builds the perfect binary tree of depth n in n steps that each duplicate the tree so far, and ldepth and ldepth2 both return the length of the leftmost path.

The head constants differ, so both sides are evaluated, and neither traversal looks beyond the leftmost path: ldepth walks n nodes for Θ(n), ldepth2 folds n additions over growing numerals for Θ(n²). The test asks whether a checker consumes the tree through its representation, for Θ(n²), or expands it into the 2ⁿ nodes of its normal form.

N=1000 in the Lean source. From Courant and Leroy, POPL 2026, §10.

Test result: 👍 accepted · exit code 0 · wall time: 149 ms · instructions: 1.9 G · max rss memory: 26.2 MB

stdout:

Checking decl 0/16 arena=1175

Test "perf/shift-cascade"

Expected: 👍 accept · Size: 256.3 KB · Lines: 5.1 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Stress test for cascading substitution overhead in kernel let processing.

N nested let bindings inside a lambda, where each value references the outer lambda parameter and the previous binding:

fun (a : Nat → Nat) => let f₁ := fun x => a x let f₂ := fun x => a (f₁ x) ... let fₙ := fun x => a (fₙ₋₁ x) fₙ 0

The kernel processes each let by substituting the value into the body. Each value has a free bvar (references a), so substitution under inner binders creates shifted copies. In a de Bruijn kernel with deferred shifts, these Shift(val, offset) wrappers accumulate: step k must traverse through O(k) wrappers from previous steps, giving O(N²) total work.

A locally-nameless kernel substitutes fvars that need no shifting, giving O(N) total.

N=1000 in the Lean source. Increase to stress further.

Test result: 👍 accepted · exit code 0 · wall time: 129 ms · instructions: 1.9 G · max rss memory: 12.2 MB

stdout:

Checking decl 0/10 arena=4089

Test "perf/unroll-versus-evaluate"

Expected: 👍 accept · Size: 44.6 KB · Lines: 1.2 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The declaration to check compares

count #(n+1)      and      N.add (count #n) #1

where #k is the numeral with k successors, and count #k evaluates to #k in Θ(k²) reductions.

The head constants differ. Unrolling count once turns the left side into the right side, leaving a traversal of the shared numeral #n, for Θ(n); evaluating both sides costs Θ(n²). The test asks which of two differing head constants a checker chooses to unfold.

N=1000 in the Lean source. From Courant and Leroy, POPL 2026, §2.

Test result: 👍 accepted · exit code 0 · wall time: 58 ms · instructions: 721.0 M · max rss memory: 8.9 MB

stdout:

Checking decl 0/10 arena=1107

Test "proj-non-structure"

Expected: ✋ reject · Size: 5.0 KB · Lines: 75 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Bad has two constructors, so projections should not be allowed. Prove false by using the second constructor, then projecting, hoping that the first constructor is used when inferring the type of the projection.

Test result: 🚫 declined · exit code 2 · wall time: 44 ms · instructions: 495.2 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/10 arena=48
DIAG decl 9 name=bad kind=2 r=2 peak=48 delta=0 fuel=5 infer_u=5 deq_full=0 deq_one=0 cong_hit=0 cong_ft=0 ld_iter=0 whnf_nd=0 dfull{app=0,lf=0,prj=0,pi=0,eta=0,lf=0,ee=0,pr=0} tags=[0,0,3,1,0,0,0,0,1,0,0,0,0,0,0,0]

Test "proj-of-imax-prop"

Expected: ✋ reject · Size: 19.3 KB · Lines: 321 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A closed proof of False, with no axioms, via a data projection out of a proposition whose sort is Prop only up to universe level normalization.

ImaxProp : Sort (imax 1 0) is a proposition, since imax 1 0 normalizes to 0. The exploit uses two definitionally equal spellings of that type. Proof irrelevance is stated through ImaxAsProp : Prop := ImaxProp, whose type is the literal Sort 0, so it is accepted; the data projection imaxProjBool is stated on ImaxProp, whose type is the literal Sort (imax 1 0). A kernel that tests sorts for Prop syntactically does not recognize the latter as a proposition and wrongly allows projecting its Bool field out of a proof. Congruence on the proof-irrelevance equation then equates false and true, giving False.

This is https://github.com/leanprover/lean4/pull/14613, a bug in the official kernel.

Test result: ✋ rejected · exit code 1 · wall time: 52 ms · instructions: 635.4 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/33 arena=217
FAIL decl 13 name=ImaxPropDummy kind=5

Test "proj-of-prop"

Expected: ✋ reject · Size: 3.9 KB · Lines: 56 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A proof of False via a projection from a Prop-typed structure whose constructor was applied to an ill-typed argument. The exported term is

badFalse : False := (Wrapper.mk True.intro).p

where Wrapper : Prop has a single field p : False, so Wrapper.mk expects a proof of False but is given True.intro : True.

A sound checker must reject this. A checker that types a projection by inferring (rather than checking) its structure argument — i.e. that trusts the structure to be well-typed instead of verifying the constructor's argument types against its binders — will accept it, because Wrapper.mk True.intro still formally inhabits Wrapper at the structural level, and the p projection is then read back out at the declared field type False.

Test result: 🚫 declined · exit code 2 · wall time: 40 ms · instructions: 467.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/9 arena=35
DIAG decl 8 name=badFalse kind=2 r=2 peak=36 delta=1 fuel=8 infer_u=7 deq_full=1 deq_one=1 cong_hit=0 cong_ft=0 ld_iter=1 whnf_nd=2 dfull{app=0,lf=0,prj=0,pi=0,eta=0,lf=1,ee=0,pr=0} tags=[0,1,4,1,0,0,0,0,1,0,0,0,0,0,0,0]

Test "proj-of-stuck-prop"

Expected: ✋ reject · Size: 275.9 KB · Lines: 5.3 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Proof of False by projecting the Bool field out of a proposition, exploiting that a kernel can disagree with itself about whether the structure lives in Prop.

Same underlying defect as rec-missing-ih, but with a different consequence.

Mechanism

Definitional equality is not transitive here. Three functions Bool → Bool are built from Acc.rec such that a kernel reports rcA ≡ rcB and rcB ≡ rcC — both by proof irrelevance on the Acc argument — while rcA ≢ rcC, because there the two Acc proofs have different types.
In the affected kernels, the defeq cache closes that relation transitively, but only for hash-equal terms. Established equalities are kept in a union-find structure, and the comparison returns early, without consulting it, when the hashes differ:

~~~cpp if (is_eqp(a, b)) return true; if (m_use_hash && hash(a) != hash(b)) return false; // skips the union-find ... node_ref r1 = find(to_node(a)); node_ref r2 = find(to_node(b)); if (r1 == r2) return true; ~~~

So whether rcA ≡ rcC holds depends on the hash of the surrounding term. The constants and paddings are chosen so that the hashes collide exactly when the argument is the free variable _kernel_fresh.0, and not for the closed instantiation used later.
That comparison decides a result sort. Native64ResultSortGate is a K-like inductive predicate, and its recursor is used as the result sort of the inductive family Native64ResultSortOwner: the sort Gate.rec x … Prop requested h reduces to Prop only if the requested indices are definitionally equal to the ones of Gate.intro. Hence Owner x h is a proposition in one context and a stuck sort in another:
- Native64ResultSort.asProp is checked against a constant standing for ∀ x h, Prop, so the kernel introduces _kernel_fresh.0 for x, the hashes collide, Owner x h : Prop is accepted, and Native64ResultSortLeak.proposition is a Prop for every later declaration — including for proof irrelevance.
- Native64ResultSortLeak.observe projects field 0 out of that proposition. There the sort of the closed term Owner false closedGate is needed, and that one is stuck — the affected kernels answer false when asked whether it is definitionally equal to Prop — so they do not see a proposition and permit projecting out the Bool field.

Proof irrelevance then identifies two Owner.mk applications carrying different Bool fields, and observing them yields False. The affected kernels rejected Native64ResultSortOwner with type expected as soon as the hashes no longer collided.

This was accepted by the official kernel at v4.28.0, v4.29.1, v4.33.0 and nightly-2026-08-01. Other kernels reject the export in one of two places: either they refuse Native64ResultSortOwner because its result type does not reduce to a sort, or they accept the type but refuse the projection of a data field out of a proposition.

Both steps are ruled out now: the projection by leanprover/lean4#14807, which makes the kernel's is_prop check require the inferred type to reduce to a sort, and the hash-gated transitivity of step 2 by leanprover/lean4#14806, which replaces the union-find defeq cache with an order-independent one. The same projection, reached without any help from that cache, is proj-of-subst-prop.

Test result: ✋ rejected · exit code 1 · wall time: 342 ms · instructions: 5.2 G · max rss memory: 9.9 MB

stdout:

Checking decl 0/161 arena=4392
Checking decl 100/161 arena=4392
FAIL decl 146 name=Native64ResultSortOwner kind=5

Test "proj-of-subst-prop"

Expected: ✋ reject · Size: 255.6 KB · Lines: 4.9 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Proof of False by projecting the Bool field out of a proposition, reached by substituting a proof of one proposition for a proof of a definitionally equal one.

Mechanism

Definitional equality is not transitive here. a, b and c are three Bools built from Acc.rec such that a kernel reports a ≡ b and b ≡ c — both by proof irrelevance on the Acc argument, the latter after some iota steps — while a ≢ c, because there the two Acc proofs have different types (Acc (· < ·) 1 vs. Acc (· < ·) 0).
So P := a = b and Q := a = c are definitionally equal types whose proofs behave differently. gate h := Eq.rec (motive := fun _ _ => Type) Prop h K-reduces to Prop for h : P, because that reduction only needs the type of h to be definitionally equal to the type a = a of Eq.refl a, i.e. b ≡ a. For the closed witness : Q it stays stuck, since that would need c ≡ a.
An inductive family is declared over the reducing side and used on the stuck one. Owner : ∀ (h : P), gate h is accepted as a family of propositions — its recursor only eliminates into Prop. Owner witness is well-typed, since Q ≡ P, but its sort does not reduce to Prop, so the projection observe is permitted to extract the Bool field from an inhabitant.

Proof irrelevance then identifies two Owner.mk applications carrying different Bool fields, and observing them yields False, with no axioms involved.

Unlike rec-missing-ih and proj-of-stuck-prop, this needs no interference from the definitional-equality cache: every comparison above comes out the same way in a fresh type-checker session, so it is independent of whether, and how, such a cache is keyed. What it does need is that the sort of an inductive family is re-examined after a substitution that definitional equality permits.

The projection in the last step is ruled out by leanprover/lean4#14807, which makes the kernel's is_prop check require the inferred type to reduce to a sort: a stuck sort then raises (kernel) type expected instead of answering that the type is not a proposition.

Test result: ✋ rejected · exit code 1 · wall time: 317 ms · instructions: 4.9 G · max rss memory: 10.1 MB

stdout:

Checking decl 0/152 arena=4030
Checking decl 100/152 arena=4030
FAIL decl 138 name=PR14806Subst.Owner kind=5

Test "proof-irrel"

Expected: 👍 accept · Size: 1.7 KB · Lines: 38 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Incompleteness test for proof irrelevance under a binder.

bar : ∀ h : A → P, Q (h a) := foo where foo : ∀ h : A → P, Q (h b). Checking the assignment needs Q (h a) ≡ Q (h b), i.e. h a ≡ h b. Both h a and h b are proofs of the same Prop P, so they are definitionally equal by proof irrelevance and a complete kernel accepts.

A checker that fails to apply proof irrelevance here — comparing h a and h b structurally and finding the arguments a and b distinct — wrongly rejects a valid proof.

Test result: 👍 accepted · exit code 0 · wall time: 36 ms · instructions: 408.6 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/7 arena=17

Test "rec-k-lie"

Expected: ✋ reject · Size: 5.3 KB · Lines: 87 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

False theorem via trusted k on a recursor.

Define MyBool with two constructors, and lie by claiming its recursor is K-like, so the major premise is replaced by the first constructor without being examined.

disc MyBool.true is then True rather than False.

MyBool rather than Bool because a module that overwrites an imported constant cannot be re-imported by the exporter.

Test result: ✋ rejected · exit code 1 · wall time: 41 ms · instructions: 495.4 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/11 arena=49
FAIL decl 10 name=bad kind=2

Test "rec-missing-ih"

Expected: ✋ reject · Size: 289.6 KB · Lines: 5.5 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration

Proof of False from a generated recursor whose reduction rule drops the induction hypothesis.

Mechanism

Definitional equality is not transitive here. The test builds three functions Bool → Bool from Acc.rec for which a kernel reports rcA ≡ rcB and rcB ≡ rcC — both by proof irrelevance on the Acc argument, the latter after some iota steps — but rcA ≢ rcC, because there the two Acc proofs have different types (Acc (· < ·) 1 vs. Acc (· < ·) 0).
In the affected kernels, the defeq cache closes that relation transitively, but only for hash-equal terms. Established equalities are kept in a union-find structure, and the comparison returns early, without consulting it, when the hashes differ:

~~~cpp if (is_eqp(a, b)) return true; if (m_use_hash && hash(a) != hash(b)) return false; // skips the union-find ... node_ref r1 = find(to_node(a)); node_ref r2 = find(to_node(b)); if (r1 == r2) return true; ~~~

So whether rcA ≡ rcC holds depends on the hash of the surrounding term. The three constants and the two paddings are picked so that the hashes collide for the free variables that the affected implementations create while building the minor premises of the recursor (_ind_fresh.3, _ind_fresh.9), but not for the pass that builds the recursor rules (_ind_fresh.14).
A K-like reduction is made to depend on that comparison. Native64TwoHashGate is a K-like inductive predicate (one parameter, four Bool indices, one field-less constructor pinning the indices), so reducing Gate.rec … h requires the indices of h's type to be definitionally equal to the ones of Gate.intro's result type. Native64TwoHashOwner.step has a recursive argument whose type is such a Gate.rec application, which therefore reduces to Owner in one pass but not in the other.

The resulting Native64TwoHashOwner.rec has a step minor premise expecting four arguments (including the induction hypothesis) but a rule that applies it to only three, so the ih binder swallows the next argument. That makes the Prop-valued badProp reduce to Bool, and a Prop with two distinguishable inhabitants gives False.

Affected kernels not only accept these declarations, they also re-derive the same broken recursor when replaying the export data. This was the case for the official kernel at v4.28.0, v4.29.1, v4.33.0 and nightly-2026-08-01. Kernels that construct the recursor independently reject the export, mostly with an error about Native64TwoHashOwner.step having an invalid occurrence of the datatype being declared — which is also what the affected kernels reported as soon as one of the hashes no longer collided.

Fixed by leanprover/lean4#14806, which replaces the union-find defeq cache with an order-independent one, so that a hash collision can no longer make a comparison succeed that fails on its own.

Test result: ✋ rejected · exit code 1 · wall time: 347 ms · instructions: 5.4 G · max rss memory: 10.3 MB

stdout:

Checking decl 0/167 arena=4596
Checking decl 100/167 arena=4596
FAIL decl 151 name=Native64TwoHashOwner kind=5

Test "rec-of-subst-prop"

Expected: ✋ reject · Size: 270.3 KB · Lines: 5.1 k · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Proof of False from a Prop that carries a Type field, recovered through the recursor instead of a projection.

A second variant of proj-of-subst-prop, sharing its first two steps:

Definitional equality is not transitive on three Bools built from Acc.rec — gateA ≡ gateB and gateB ≡ gateC by proof irrelevance on the Acc argument, but gateA ≢ gateC — so GateP := gateA = gateB and GateQ := gateA = gateC are definitionally equal types whose proofs behave differently under Eq.rec. resultSort h K-reduces to Prop for a variable h : GateP and stays stuck for the closed gateWitness : GateQ.
Issue.Owner : ∀ (h : GateP), resultSort h is therefore accepted as a family of propositions whose constructor carries a field A : Type, while Owner gateWitness — well-typed, since GateQ ≡ GateP — has a sort that does not reduce to Prop.

Where proj-of-subst-prop then projects the field out, this variant eliminates Owner with its own Prop-only recursor into Fiber X := Acc emptyTypeRel X, which is a proposition, and recovers the data from there: Acc.rec eliminates Acc into Type, and propext transports an Acc proof between two Fiber types. Proof irrelevance identifies Owner.mk gateWitness Empty with Owner.mk gateWitness Unit, so the identity function of one type is applied to a value of the other, and Empty becomes inhabited. The proof of False uses propext and no other axiom.

Because no projection is involved, the guard that stops proj-of-subst-prop — refusing to project a data field out of a proposition — never fires here. A checker has to refuse the substitution, or the stuck result sort of Issue.Owner, instead.

Both variants are ruled out by leanprover/lean4#14807, which makes the kernel's is_prop check require the inferred type to reduce to a sort: Issue.Owner is then rejected with (kernel) type expected.

The exploit is by Daniel Selsam (OpenAI), generated with OpenAI's internal models, and is the regression test added in leanprover/lean4#14847.

Test result: ✋ rejected · exit code 1 · wall time: 320 ms · instructions: 5.0 G · max rss memory: 10.2 MB

stdout:

Checking decl 0/174 arena=4203
Checking decl 100/174 arena=4203
FAIL decl 140 name=Issue.Owner kind=5

Test "sparse-name-index"

Expected: 👍 accept · Size: 292 B · Lines: 4 · lean4export: 0.1.0 · Lean: 4.29.1 · 📄 Declaration

Lean4export will create internalization-table references contiguously in order: in references for names, il references for levels, and ie references for expressions all work this way.

This test checks that a kernel doesn't require internalization-table references to be assigned sequentially starting from 1. If the "2" and "4" were replaced by "1" and "0", respectively, this would be the expected encoding of axiom foo : Prop. This encoding should be equivalent.

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 273.7 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=5

Test "std"

Expected: 👍 accept · Size: 526.1 MB · Lines: 10.0 M · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The complete Std library export from Lean 4.

This test contains the standard library extensions beyond core Lean 4, including:

Enhanced data structures (HashMap, RBTree, etc.)
Additional mathematical operations
Extended list and array operations
Utility functions and theorems

This represents a medium-sized test case, larger than core modules but smaller than Mathlib, making it useful for performance testing.

Test result: 💥 error · exit code 124 · wall time: 30.0 s · instructions: 432.4 G · max rss memory: 444.5 MB

Test "tutorial/001_basicDef"

Expected: 👍 accept · Size: 367 B · Lines: 6 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Basic definition

Test result: 👍 accepted · exit code 0 · wall time: 26 ms · instructions: 274.1 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/002_badDef"

Expected: ✋ reject · Size: 365 B · Lines: 6 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Mismatched types

Test result: ✋ rejected · exit code 1 · wall time: 26 ms · instructions: 253.4 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/1 arena=2
FAIL decl 0 name=badDef kind=1

Test "tutorial/003_arrowType"

Expected: 👍 accept · Size: 622 B · Lines: 12 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Arrow type (function type)

Test result: 👍 accepted · exit code 0 · wall time: 25 ms · instructions: 274.9 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=3

Test "tutorial/004_dependentType"

Expected: 👍 accept · Size: 460 B · Lines: 7 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Dependent type (forall)

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 274.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=3

Test "tutorial/005_constType"

Expected: 👍 accept · Size: 897 B · Lines: 17 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Lambda expression

Test result: 👍 accepted · exit code 0 · wall time: 27 ms · instructions: 276.4 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=6

Test "tutorial/006_betaReduction"

Expected: 👍 accept · Size: 1.3 KB · Lines: 27 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Lambda reduction

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 300.2 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/2 arena=13

Test "tutorial/007_betaReduction2"

Expected: 👍 accept · Size: 1.4 KB · Lines: 28 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Lambda reduction under binder

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 300.6 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/2 arena=14

Test "tutorial/008_forallSortWhnf"

Expected: 👍 accept · Size: 1.2 KB · Lines: 25 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The binding domain of a forall may need to be reduce before it is a sort

Test result: 👍 accepted · exit code 0 · wall time: 30 ms · instructions: 299.7 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/2 arena=13

Test "tutorial/009_forallSortBad"

Expected: ✋ reject · Size: 1.2 KB · Lines: 26 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The binding domain of a forall has to be a sort

Test result: ✋ rejected · exit code 1 · wall time: 29 ms · instructions: 279.5 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/2 arena=14
FAIL decl 1 name=forallSortBad kind=1

Test "tutorial/010_nonTypeType"

Expected: ✋ reject · Size: 1.1 KB · Lines: 21 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The type of a declaration has to be a type, not some other expression

Test result: ✋ rejected · exit code 1 · wall time: 29 ms · instructions: 277.9 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/2 arena=8
FAIL decl 1 name=nonTypeType kind=1

Test "tutorial/011_nonTypeAxiom"

Expected: ✋ reject · Size: 1.0 KB · Lines: 20 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

This applies to axioms as well, which are easy to overlook because they have no value to check the type against. Letting one through is not merely untidy: an axiom whose type is an arbitrary term inhabits whatever that term is later found definitionally equal to, and the eta and proof irrelevance rules are happy to equate a term like this with a great many things.

Test result: ✋ rejected · exit code 1 · wall time: 31 ms · instructions: 277.6 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/2 arena=7
FAIL decl 1 name=nonTypeAxiom kind=0

Test "tutorial/012_nonPropThm"

Expected: ✋ reject · Size: 424 B · Lines: 7 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The type of a theorem has to be a proposition

Test result: ✋ rejected · exit code 1 · wall time: 27 ms · instructions: 253.7 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=3
FAIL decl 0 name=nonPropThm kind=2

Test "tutorial/013_thmProof"

Expected: 👍 accept · Size: 1.3 KB · Lines: 26 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A theorem can refer to another theorem

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 300.7 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/2 arena=14

Test "tutorial/014_selfProof"

Expected: ✋ reject · Size: 459 B · Lines: 8 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A theorem cannot refer to itself

Test result: 👍 accepted · exit code 0 · wall time: 27 ms · instructions: 274.6 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/1 arena=4

Test "tutorial/015_levelComp1"

Expected: 👍 accept · Size: 391 B · Lines: 7 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Some level computation

Test result: 👍 accepted · exit code 0 · wall time: 25 ms · instructions: 274.2 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/016_levelComp2"

Expected: 👍 accept · Size: 409 B · Lines: 8 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Some level computation

Test result: 👍 accepted · exit code 0 · wall time: 27 ms · instructions: 274.3 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/017_levelComp3"

Expected: 👍 accept · Size: 427 B · Lines: 9 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Some level computation

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 274.3 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/018_levelParams"

Expected: 👍 accept · Size: 1.4 KB · Lines: 29 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Level parameters

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 300.5 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/2 arena=13

Test "tutorial/019_tut06_bad01"

Expected: ✋ reject · Size: 427 B · Lines: 8 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Duplicate universe parameters

Test result: ✋ rejected · exit code 1 · wall time: 28 ms · instructions: 253.6 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=2
FAIL decl 0 name=tut06_bad01 kind=1

Test "tutorial/020_levelComp4"

Expected: 👍 accept · Size: 424 B · Lines: 8 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Some level computation

Test result: 👍 accepted · exit code 0 · wall time: 26 ms · instructions: 274.3 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/021_levelComp5"

Expected: 👍 accept · Size: 424 B · Lines: 8 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Some level computation

Test result: 👍 accepted · exit code 0 · wall time: 26 ms · instructions: 274.3 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/022_imax1"

Expected: 👍 accept · Size: 809 B · Lines: 16 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Type inference for forall using imax

Test result: 👍 accepted · exit code 0 · wall time: 27 ms · instructions: 276.0 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=6

Test "tutorial/023_imax2"

Expected: 👍 accept · Size: 828 B · Lines: 17 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Type inference for forall using imax

Test result: 👍 accepted · exit code 0 · wall time: 26 ms · instructions: 276.0 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=6

Test "tutorial/024_levelMaxComm"

Expected: 👍 accept · Size: 524 B · Lines: 12 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Level equality: max is commutative (max u v ≈ max v u).

Test result: 👍 accepted · exit code 0 · wall time: 27 ms · instructions: 274.8 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/025_levelMaxAssoc"

Expected: 👍 accept · Size: 623 B · Lines: 16 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Level equality: max is associative (max (max u v) w ≈ max u (max v w)).

Test result: 👍 accepted · exit code 0 · wall time: 29 ms · instructions: 275.4 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/026_levelMaxIdem"

Expected: 👍 accept · Size: 447 B · Lines: 9 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Level equality: max is idempotent (max u u ≈ u).

Test result: 👍 accepted · exit code 0 · wall time: 27 ms · instructions: 274.4 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/027_levelMaxAbsorb"

Expected: 👍 accept · Size: 526 B · Lines: 12 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Level equality: max absorption (max u (max u v) ≈ max u v).

Test result: 👍 accepted · exit code 0 · wall time: 30 ms · instructions: 274.8 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=2

Test "tutorial/028_inferVar"

Expected: 👍 accept · Size: 713 B · Lines: 12 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Type inference of local variables

Test result: 👍 accepted · exit code 0 · wall time: 26 ms · instructions: 276.0 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=7

Test "tutorial/029_defEqLambda"

Expected: 👍 accept · Size: 1.4 KB · Lines: 26 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Definitional equality between lambdas

Test result: 👍 accepted · exit code 0 · wall time: 27 ms · instructions: 279.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=15

Test "tutorial/030_peano1"

Expected: 👍 accept · Size: 3.6 KB · Lines: 73 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Peano arithmetic: 2 = 2

Test result: 👍 accepted · exit code 0 · wall time: 35 ms · instructions: 419.4 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/7 arena=41

Test "tutorial/031_peano2"

Expected: 👍 accept · Size: 4.5 KB · Lines: 90 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Peano arithmetic: 1 + 1 = 2

Test result: 👍 accepted · exit code 0 · wall time: 40 ms · instructions: 447.3 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/8 arena=55

Test "tutorial/032_peano3"

Expected: 👍 accept · Size: 4.9 KB · Lines: 98 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Peano arithmetic: 2 * 2 = 4

Test result: 👍 accepted · exit code 0 · wall time: 41 ms · instructions: 493.1 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/10 arena=59

Test "tutorial/033_letType"

Expected: 👍 accept · Size: 489 B · Lines: 9 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Type checking a non-dependent let

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 274.7 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/1 arena=4

Test "tutorial/034_letTypeDep"

Expected: 👍 accept · Size: 1.2 KB · Lines: 26 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Type checking a dependent let

Test result: 👍 accepted · exit code 0 · wall time: 29 ms · instructions: 320.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/3 arena=11

Test "tutorial/035_letRed"

Expected: 👍 accept · Size: 627 B · Lines: 12 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Reducing a let

Test result: 👍 accepted · exit code 0 · wall time: 28 ms · instructions: 296.6 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/2 arena=5

Test "tutorial/036_empty"

Expected: 👍 accept · Size: 1.2 KB · Lines: 20 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A simple empty inductive type

Test result: 👍 accepted · exit code 0 · wall time: 30 ms · instructions: 321.6 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/3 arena=9

Test "tutorial/037_boolType"

Expected: 👍 accept · Size: 2.3 KB · Lines: 37 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A simple enumeration inductive type

Test result: 👍 accepted · exit code 0 · wall time: 34 ms · instructions: 371.3 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/5 arena=22

Test "tutorial/038_twoBool"

Expected: 👍 accept · Size: 4.2 KB · Lines: 65 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A simple product type

Test result: 👍 accepted · exit code 0 · wall time: 39 ms · instructions: 447.0 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/8 arena=43

Test "tutorial/039_andType"

Expected: 👍 accept · Size: 3.2 KB · Lines: 57 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A parametrized product type (no level parameters)

Test result: 👍 accepted · exit code 0 · wall time: 31 ms · instructions: 356.4 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/4 arena=41

Test "tutorial/040_prodType"

Expected: 👍 accept · Size: 3.8 KB · Lines: 76 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A parametrized product type (with level parameters)

Test result: 👍 accepted · exit code 0 · wall time: 31 ms · instructions: 359.5 M · max rss memory: 8.0 MB

stdout:

Checking decl 0/4 arena=47

Test "tutorial/041_pprodType"

Expected: 👍 accept · Size: 3.8 KB · Lines: 75 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A parametrized product type (with more general level parameters)

Test result: 👍 accepted · exit code 0 · wall time: 32 ms · instructions: 359.4 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/4 arena=47

Test "tutorial/042_pUnitType"

Expected: 👍 accept · Size: 1.8 KB · Lines: 31 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Level-polymorphic unit type

Test result: 👍 accepted · exit code 0 · wall time: 35 ms · instructions: 346.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/4 arena=16

Test "tutorial/043_eqType"

Expected: 👍 accept · Size: 3.2 KB · Lines: 62 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Equality, as an important indexed non-recursive data type

Test result: 👍 accepted · exit code 0 · wall time: 32 ms · instructions: 355.9 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/4 arena=42

Test "tutorial/044_natDef"

Expected: 👍 accept · Size: 3.3 KB · Lines: 61 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A recursive inductive data type

Test result: 👍 accepted · exit code 0 · wall time: 32 ms · instructions: 376.6 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/5 arena=36

Test "tutorial/045_rbTreeDef"

Expected: 👍 accept · Size: 15.7 KB · Lines: 296 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A recursive indexed data type

Test result: 👍 accepted · exit code 0 · wall time: 53 ms · instructions: 664.7 M · max rss memory: 8.6 MB

stdout:

Checking decl 0/14 arena=248

Test "tutorial/046_inductBadNonSort"

Expected: ✋ reject · Size: 1.2 KB · Lines: 20 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive type with a non-sort type

Test result: ✋ rejected · exit code 1 · wall time: 30 ms · instructions: 278.6 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/2 arena=7
FAIL decl 1 name=inductBadNonSort kind=5

Test "tutorial/047_inductBadNonSort2"

Expected: ✋ reject · Size: 598 B · Lines: 8 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

Another inductive type with a non-sort type

Test result: ✋ rejected · exit code 1 · wall time: 29 ms · instructions: 276.0 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/2 arena=2
FAIL decl 1 name=inductBadNonSort2 kind=5

Test "tutorial/048_inductLevelParam"

Expected: ✋ reject · Size: 515 B · Lines: 7 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive with duplicate level params

Test result: ✋ rejected · exit code 1 · wall time: 26 ms · instructions: 254.3 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/1 arena=1
FAIL decl 0 name=inductLevelParam kind=5

Test "tutorial/049_inductTooFewParams"

Expected: ✋ reject · Size: 548 B · Lines: 6 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive with too few parameters in the type

Test result: ✋ rejected · exit code 1 · wall time: 25 ms · instructions: 254.5 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/1 arena=2
FAIL decl 0 name=inductTooFewParams kind=5

Test "tutorial/050_inductWrongCtorParams"

Expected: ✋ reject · Size: 1.2 KB · Lines: 16 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive with a constructor with wrong parameters

Test result: ✋ rejected · exit code 1 · wall time: 31 ms · instructions: 322.3 M · max rss memory: 8.4 MB

stdout:

Checking decl 0/4 arena=7
FAIL decl 3 name=inductWrongCtorParams kind=5

Test "tutorial/051_inductWrongCtorResParams"

Expected: ✋ reject · Size: 1.3 KB · Lines: 19 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive with a constructor with wrong parameters in result (they are swapped)

Test result: ✋ rejected · exit code 1 · wall time: 31 ms · instructions: 301.8 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/3 arena=11
FAIL decl 2 name=inductWrongCtorResParams kind=5

Test "tutorial/052_inductWrongCtorResLevel"

Expected: ✋ reject · Size: 1.4 KB · Lines: 23 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive with a constructor with wrong level parameters in result (they are swapped)

Test result: ✋ rejected · exit code 1 · wall time: 34 ms · instructions: 302.2 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/3 arena=11
FAIL decl 2 name=inductWrongCtorResLevel kind=5

Test "tutorial/053_inductInIndex"

Expected: ✋ reject · Size: 1.1 KB · Lines: 14 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

A constructor with an unexpected occurrence of the type in index position of a return type.

Test result: ✋ rejected · exit code 1 · wall time: 30 ms · instructions: 321.8 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/4 arena=6
FAIL decl 3 name=inductInIndex kind=5

Test "tutorial/054_indNeg"

Expected: ✋ reject · Size: 996 B · Lines: 12 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

The classic example of an inductive with negative recursive occurrence

Test result: ✋ rejected · exit code 1 · wall time: 29 ms · instructions: 300.1 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/3 arena=5
FAIL decl 2 name=indNeg kind=5

Test "tutorial/055_reduceCtorParam.mk"

Expected: 👍 accept · Size: 4.1 KB · Lines: 80 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

When checking inductives, we expect the kernel to reduce the types of constructor arguments.

Test result: 👍 accepted · exit code 0 · wall time: 32 ms · instructions: 381.6 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/5 arena=54

Test "tutorial/056_reduceCtorType.mk"

Expected: ✋ reject · Size: 1.5 KB · Lines: 26 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

When checking inductives, we expect the kernel to not reduce the type of the constructor itself; that should be all manifest foralls

Test result: ✋ rejected · exit code 1 · wall time: 31 ms · instructions: 324.1 M · max rss memory: 8.0 MB

stdout:

Checking decl 0/4 arena=13
FAIL decl 3 name=reduceCtorType kind=5

Test "tutorial/057_indNegReducible"

Expected: ✋ reject · Size: 1.9 KB · Lines: 31 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

When checking inductives, we expect the kernel to not reduce the type of the constructor parameters further than head normal form. Recursive occurrences nested inside the head normal form are considered negative occurrences, even if they could be reduced to disappear.

Test result: ✋ rejected · exit code 1 · wall time: 31 ms · instructions: 346.9 M · max rss memory: 8.1 MB

stdout:

Checking decl 0/5 arena=14
FAIL decl 4 name=indNegReducible kind=5

Test "tutorial/058_predWithTypeField"

Expected: 👍 accept · Size: 2.0 KB · Lines: 32 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive proposition can have constructors with fields of arbitrary level.

Test result: 👍 accepted · exit code 0 · wall time: 30 ms · instructions: 347.9 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/4 arena=20

Test "tutorial/059_typeWithTypeField"

Expected: 👍 accept · Size: 2.1 KB · Lines: 36 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive type can have fields of level up to that of the inductive.

Test result: 👍 accepted · exit code 0 · wall time: 33 ms · instructions: 348.3 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/4 arena=21

Test "tutorial/060_typeWithTypeFieldPoly"

Expected: 👍 accept · Size: 2.1 KB · Lines: 38 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive type can have fields of level up to that of the inductive (polymorphic variant).

Test result: 👍 accepted · exit code 0 · wall time: 33 ms · instructions: 348.6 M · max rss memory: 8.2 MB

stdout:

Checking decl 0/4 arena=21

Test "tutorial/061_typeWithTooHighTypeField.mk"

Expected: ✋ reject · Size: 943 B · Lines: 11 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source

An inductive type can have fields of from higher universes.

Test result: ✋ rejected · exit code 1 · wall time: 33 ms · instructions: 299.8 M · max rss memory: 8.3 MB

stdout:

Checking decl 0/3 arena=4
FAIL decl 2 name=typeWithTooHighTypeField kind=5

Test "tutorial/062_emptyRec"

Expected: 👍 accept · Size: 1.2 KB · Lines: 21 · lean4export: 3.1.0 · Lean: 4.29.1 · 📄 Declaration · 🔗 Source