Lean Kernel Arena / evmlean

Checker "evmlean"

Version: 0.3.0 · 📄 Declaration · 🔗 Source

A Lean 4 kernel implemented in Solidity and executed on the Ethereum Virtual Machine. Accepting a proof is a metered EVM execution; the same call can be replayed on any EVM chain (61.5KB deployed — over today's EIP-170 limit, sized for the 64KiB raise on the Glamsterdam track, so it needs a devnet/L2 with a raised code-size limit to deploy for real).

Checks inductive families including multi-type mutual groups and nested inductives, projections, quotients, Nat and String literals. Gets all ten of the Arena's static tests right: the eight adversarial ones are rejected at the offending declaration, and the two that are actually valid (level-index-out-of-order, sparse-name-index) are accepted. Declines unsafe/partial declarations and any export beyond its resource budget; resource exhaustion is reported as a decline rather than as a wrong verdict or a checker fault.

Completeness (rightfully accepted tests)

105/105

Soundness (rightfully rejected tests)

68/68

Declined tests

21

Test Expected Result ⏱️ 🧠
bogus1 ✋ ✋ 1.3 s 133.5 MB
cedar 👍 🚫 0 ms 0 B
constlevels ✋ ✋ 1.7 s 131.3 MB
cslib 👍 🚫 0 ms 0 B
ctor-num-fields ✋ ✋ 1.7 s 133.1 MB
extra-rec ✋ ✋ 488 ms 133.3 MB
init 👍 🚫 0 ms 0 B
init-prelude 👍 🚫 0 ms 0 B
k-rec-conv ✋ ✋ 2.1 s 132.9 MB
large-elim-param ✋ ✋ 642 ms 133.4 MB
large-elim-prop-bool ✋ ✋ 2.9 s 135.6 MB
level-imax-leq ✋ ✋ 682 ms 133.7 MB
level-imax-normalization ✋ ✋ 682 ms 133.8 MB
level-index-out-of-order 👍 👍 468 ms 133.6 MB
mathlib 👍 🚫 0 ms 0 B
nat-rec-k-lie ✋ ✋ 610 ms 133.3 MB
nat-rec-rules ✋ ✋ 856 ms 133.4 MB
nested-nonuniform-param 🤷 👍 1.3 s 134.5 MB
nested-unused-param ✋ ✋ 13.1 s 196.5 MB
orphan-ctor ✋ ✋ 489 ms 132.9 MB
orphan-rec ✋ ✋ 488 ms 133.1 MB
proj-non-structure ✋ ✋ 675 ms 133.2 MB
proj-of-imax-prop ✋ ✋ 1.6 s 132.0 MB
proj-of-prop ✋ ✋ 636 ms 133.3 MB
proj-of-stuck-prop ✋ ✋ 1.6 m 385.3 MB
proj-of-subst-prop ✋ ✋ 1.6 m 378.6 MB
proof-irrel 👍 👍 544 ms 132.4 MB
rec-k-lie ✋ ✋ 577 ms 133.1 MB
rec-missing-ih ✋ ✋ 2.1 m 438.6 MB
rec-of-subst-prop ✋ ✋ 1.6 m 430.3 MB
sparse-name-index 👍 👍 464 ms 133.5 MB
std 👍 🚫 0 ms 0 B
3 14.2 m (×7508) 408.2 MB
app-lam 👍 🚫 305 ms 106.9 MB
args-before-unfold 👍 🚫 1.6 s 137.8 MB
beta-ladder 👍 🚫 7.1 s 282.1 MB
church-numerals 👍 🚫 43.2 s 408.2 MB
discarded-argument 👍 🚫 1.3 s 133.0 MB
discarded-argument-match 👍 🚫 3.7 s 136.9 MB
folded-constant-first 👍 🚫 2.3 s 139.1 MB
folded-constant-last 👍 🚫 2.3 s 140.6 MB
grind-ring-5 👍 🚫 305 ms 107.3 MB
identical-nesting 👍 👍 1.1 s (×41) 131.2 MB (×2.1)
irrelevance-before-evaluation 👍 🚫 1.4 s 135.5 MB
let-ladder 👍 🚫 8.2 s 283.8 MB
refute-cheap-first ✋ 🚫 1.9 s 135.2 MB
refute-cheap-last ✋ 🚫 1.9 s 135.7 MB
repeated-subproblem 👍 👍 12.7 m (×26789) 177.3 MB (×2.8)
shared-subterm 👍 🚫 2.0 s 137.6 MB
shift-cascade 👍 👍 8.9 s (×193) 188.9 MB (×3.0)
unroll-versus-evaluate 👍 🚫 1.6 s 137.7 MB
141 3.2 m (×59) 316.1 MB
001_basicDef 👍 👍 472 ms 133.2 MB
002_badDef ✋ ✋ 477 ms 133.6 MB
003_arrowType 👍 👍 487 ms 133.0 MB
004_dependentType 👍 👍 477 ms 133.8 MB
005_constType 👍 👍 495 ms 133.6 MB
006_betaReduction 👍 👍 520 ms 133.4 MB
007_betaReduction2 👍 👍 526 ms 133.6 MB
008_forallSortWhnf 👍 👍 518 ms 133.7 MB
009_forallSortBad ✋ ✋ 515 ms 134.2 MB
010_nonTypeType ✋ ✋ 502 ms 133.1 MB
011_nonTypeAxiom ✋ ✋ 500 ms 135.8 MB
012_nonPropThm ✋ ✋ 473 ms 133.4 MB
013_levelComp1 👍 👍 483 ms 133.3 MB
014_levelComp2 👍 👍 487 ms 133.2 MB
015_levelComp3 👍 👍 488 ms 133.4 MB
016_levelParams 👍 👍 520 ms 133.9 MB
017_tut06_bad01 ✋ ✋ 473 ms 133.7 MB
018_levelComp4 👍 👍 478 ms 134.2 MB
019_levelComp5 👍 👍 478 ms 133.2 MB
020_imax1 👍 👍 487 ms 133.0 MB
021_imax2 👍 👍 512 ms 134.9 MB
022_levelMaxComm 👍 👍 498 ms 133.5 MB
023_levelMaxAssoc 👍 👍 505 ms 133.8 MB
024_levelMaxIdem 👍 👍 485 ms 133.7 MB
025_levelMaxAbsorb 👍 👍 496 ms 132.9 MB
026_inferVar 👍 👍 485 ms 133.9 MB
027_defEqLambda 👍 👍 528 ms 133.0 MB
028_peano1 👍 👍 645 ms 133.3 MB
029_peano2 👍 👍 968 ms 133.1 MB
030_peano3 👍 👍 1.2 s 133.4 MB
031_letType 👍 👍 479 ms 133.2 MB
032_letTypeDep 👍 👍 508 ms 133.7 MB
033_letRed 👍 👍 486 ms 133.8 MB
034_empty 👍 👍 517 ms 134.2 MB
035_boolType 👍 👍 580 ms 133.8 MB
036_twoBool 👍 👍 672 ms 133.2 MB
037_andType 👍 👍 678 ms 132.5 MB
038_prodType 👍 👍 1.0 s 133.7 MB
039_pprodType 👍 👍 1.1 s 132.7 MB
040_pUnitType 👍 👍 548 ms 133.4 MB
041_eqType 👍 👍 882 ms 133.9 MB
042_natDef 👍 👍 641 ms 133.0 MB
043_rbTreeDef 👍 👍 5.7 s 135.3 MB
044_inductBadNonSort ✋ ✋ 501 ms 133.2 MB
045_inductBadNonSort2 ✋ ✋ 481 ms 135.8 MB
046_inductLevelParam ✋ ✋ 479 ms 133.9 MB
047_inductTooFewParams ✋ ✋ 482 ms 133.3 MB
048_inductWrongCtorParams ✋ ✋ 505 ms 133.8 MB
049_inductWrongCtorResParams ✋ ✋ 513 ms 133.2 MB
050_inductWrongCtorResLevel ✋ ✋ 518 ms 133.8 MB
051_inductInIndex ✋ ✋ 497 ms 133.8 MB
052_indNeg ✋ ✋ 492 ms 134.2 MB
053_reduceCtorParam.mk 👍 👍 825 ms 133.2 MB
054_reduceCtorType.mk ✋ ✋ 509 ms 134.1 MB
055_indNegReducible ✋ ✋ 523 ms 132.6 MB
056_predWithTypeField 👍 👍 547 ms 132.8 MB
057_typeWithTypeField 👍 👍 557 ms 133.2 MB
058_typeWithTypeFieldPoly 👍 👍 568 ms 132.4 MB
059_typeWithTooHighTypeField.mk ✋ ✋ 491 ms 133.4 MB
060_emptyRec 👍 👍 525 ms 133.4 MB
061_boolRec 👍 👍 652 ms 133.2 MB
062_twoBoolRec 👍 👍 726 ms 133.0 MB
063_andRec 👍 👍 746 ms 133.0 MB
064_prodRec 👍 👍 1.3 s 132.9 MB
065_pprodRec 👍 👍 1.3 s 133.7 MB
066_punitRec 👍 👍 577 ms 133.3 MB
067_eqRec 👍 👍 1.1 s 132.9 MB
068_nRec 👍 👍 668 ms 133.4 MB
069_rbTreeRef 👍 👍 8.1 s 135.5 MB
070_boolPropRec 👍 👍 567 ms 133.6 MB
071_BogusRecursor ✋ ✋ 525 ms 132.7 MB
072_existsRec 👍 👍 738 ms 133.1 MB
073_typeSingletonRecReduction 👍 👍 1.1 s 134.1 MB
074_sortElimPropRec 👍 👍 1.2 s 133.9 MB
075_sortElimProp2Rec 👍 👍 1.1 s 133.7 MB
076_boolRecEqns 👍 👍 2.0 s 133.0 MB
077_prodRecEqns 👍 👍 4.0 s 143.6 MB
078_nRecReduction 👍 👍 3.3 s 131.5 MB
079_listRecReduction 👍 👍 8.3 s 174.4 MB
080_RBTree.id_spec 👍 👍 37.4 s 316.1 MB
081_And.right 👍 👍 725 ms 132.9 MB
082_Prod.snd 👍 👍 1.2 s 133.2 MB
083_PProd.snd 👍 👍 1.1 s 133.2 MB
084_PSigma.snd 👍 👍 1.4 s 133.5 MB
085_projOutOfRange ✋ ✋ 699 ms 132.4 MB
086_projNotStruct ✋ ✋ 640 ms 132.7 MB
087_projProp1 👍 👍 1.2 s 133.5 MB
088_projProp2 ✋ ✋ 1.2 s 134.4 MB
089_projProp3 👍 👍 1.2 s 134.5 MB
090_projProp4 ✋ ✋ 1.2 s 133.1 MB
091_projProp5 ✋ ✋ 1.2 s 131.9 MB
092_projProp6 ✋ ✋ 1.2 s 132.7 MB
093_MaybeProp.mk 👍 👍 1.1 s 134.3 MB
094_projMaybeProp 👍 👍 1.1 s 134.0 MB
095_projMaybePropPast 👍 👍 1.1 s 132.9 MB
096_projDataIndexRec 👍 👍 824 ms 134.5 MB
097_projIndexData ✋ ✋ 783 ms 134.8 MB
098_projIndexData2 ✋ ✋ 781 ms 133.8 MB
099_projRed 👍 👍 1.7 s 133.3 MB
100_ruleK 👍 👍 1.1 s 134.1 MB
101_ruleKbad ✋ ✋ 1.1 s 133.9 MB
102_ruleKAcc ✋ ✋ 2.7 s 132.6 MB
103_aNatLit 👍 👍 633 ms 133.3 MB
104_natLitEq 👍 👍 1.0 s 133.4 MB
105_proofIrrelevance 👍 👍 965 ms 133.3 MB
106_proofIrrelevanceBad ✋ ✋ 978 ms 133.5 MB
107_proofIrrelevanceWhnf 👍 👍 1.1 s 133.4 MB
108_unitEta1 👍 👍 1.0 s 133.9 MB
109_unitEta2 👍 👍 1.0 s 132.8 MB
110_unitEta3 👍 👍 1.0 s 132.4 MB
111_indexedUnitEta ✋ ✋ 1.1 s 133.8 MB
112_structEta 👍 👍 2.4 s 132.0 MB
113_indexedStructEta ✋ ✋ 1.2 s 134.5 MB
114_funEta 👍 👍 1.0 s 132.8 MB
115_funEtaDep 👍 👍 1.1 s 133.4 MB
116_funEtaBad ✋ ✋ 1.1 s 133.4 MB
117_etaRuleK ✋ ✋ 1.2 s 133.4 MB
118_etaCtor ✋ ✋ 1.2 s 133.4 MB
119_reflOccLeft ✋ ✋ 644 ms 133.1 MB
120_reflOccInIndex ✋ ✋ 654 ms 133.7 MB
121_reduceCtorParamRefl.mk 👍 👍 921 ms 133.4 MB
122_reduceCtorParamRefl2.mk 👍 👍 905 ms 133.5 MB
123_rTreeRec 👍 👍 888 ms 133.7 MB
124_rtreeRecReduction 👍 👍 1.6 s 132.8 MB
125_accRecType 👍 👍 2.5 s 133.5 MB
126_accRecReduction 👍 👍 7.4 s 157.2 MB
127_accRecNoEta ✋ ✋ 2.6 s 132.8 MB
128_quotMkType 👍 👍 1.4 s 133.4 MB
129_quotIndType 👍 👍 1.4 s 133.4 MB
130_quotLiftType 👍 👍 1.7 s 133.1 MB
131_quotSoundType 👍 👍 1.4 s 132.8 MB
132_quotLiftReduction 👍 👍 2.4 s 133.6 MB
133_quotIndReduction 👍 👍 2.3 s 134.3 MB
134_dup_defs ✋ ✋ 469 ms 133.8 MB
135_dup_ind_def ✋ ✋ 491 ms 133.0 MB
136_dup_ctor_def ✋ ✋ 498 ms 132.8 MB
137_dup_rec_def ✋ ✋ 499 ms 133.5 MB
138_misnamed_rec_user ✋ ✋ 504 ms 133.3 MB
139_dup_rec_def2 ✋ ✋ 504 ms 133.3 MB
140_dup_ctor_rec ✋ ✋ 497 ms 132.2 MB
141_DupConCon ✋ ✋ 502 ms 133.2 MB
4 2.7 m (×785) 334.3 MB
alg-conv-trans-acc 🤷 ✋ 26.5 s 231.0 MB
alg-conv-trans-acc-left 👍 👍 22.1 s 222.6 MB
alg-conv-trans-acc-right 👍 👍 39.2 s 334.3 MB
alg-conv-trans-quot 🤷 ✋ 3.1 s 144.6 MB
alg-conv-trans-quot-left 🤷 ✋ 3.1 s 144.0 MB
alg-conv-trans-quot-left-def 🤷 👍 2.9 s 132.9 MB
alg-conv-trans-quot-right 👍 👍 2.4 s 132.8 MB
subject-reduction-redex 👍 👍 37.0 s 290.7 MB
subject-reduction-reduct 🤷 ✋ 26.0 s 204.1 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: 699 ms · instructions: 7.9 G · max rss memory: 133.5 MB

stderr:
evmlean: reject (decl 19, value/type mismatch); gas=5379309

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: 🚫 declined · exit code 2 · wall time: 0 ms · max rss memory: 0 B

stderr:
Declined via the `declines` field in the checker configuration; the checker was not run.

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: 824 ms · instructions: 10.4 G · max rss memory: 131.3 MB

stderr:
evmlean: reject (decl 23, universe count mismatch); gas=8181787

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: 🚫 declined · exit code 2 · wall time: 0 ms · max rss memory: 0 B

stderr:
Declined via the `declines` field in the checker configuration; the checker was not run.

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: 802 ms · instructions: 10.1 G · max rss memory: 133.1 MB

stderr:
evmlean: reject (decl 20, constructor result type); gas=7786091

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: 310 ms · instructions: 2.9 G · max rss memory: 133.3 MB

stderr:
evmlean: reject (decl 0, recursor shape); gas=251673

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: 🚫 declined · exit code 2 · wall time: 0 ms · max rss memory: 0 B

stderr:
Declined via the `declines` field in the checker configuration; the checker was not run.

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: 🚫 declined · exit code 2 · wall time: 0 ms · max rss memory: 0 B

stderr:
Declined via the `declines` field in the checker configuration; the checker was not run.

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: 984 ms · instructions: 12.5 G · max rss memory: 132.9 MB

stderr:
evmlean: reject (decl 19, value/type mismatch); gas=10423246

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: ✋ rejected · exit code 1 · wall time: 362 ms · instructions: 3.9 G · max rss memory: 133.4 MB

stderr:
evmlean: reject (decl 7, elimination universe violation); gas=1038200

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: ✋ rejected · exit code 1 · wall time: 1.4 s · instructions: 17.2 G · max rss memory: 135.6 MB

stderr:
evmlean: reject (decl 17, elimination universe violation); gas=15662938

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: 387 ms · instructions: 4.1 G · max rss memory: 133.7 MB

stderr:
evmlean: reject (decl 12, value/type mismatch); gas=1330237

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: 391 ms · instructions: 4.1 G · max rss memory: 133.8 MB

stderr:
evmlean: reject (decl 12, value/type mismatch); gas=1329120

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: 311 ms · instructions: 2.8 G · max rss memory: 133.6 MB

stderr:
evmlean: accept (decl 1, ok); gas=194462

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: 🚫 declined · exit code 2 · wall time: 0 ms · max rss memory: 0 B

stderr:
Declined via the `declines` field in the checker configuration; the checker was not run.

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: 373 ms · instructions: 3.7 G · max rss memory: 133.3 MB

stderr:
evmlean: reject (decl 3, invalid K flag); gas=888359

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: 467 ms · instructions: 5.1 G · max rss memory: 133.4 MB

stderr:
evmlean: reject (decl 12, recursor rule invalid); gas=2397552

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: 693 ms · instructions: 8.1 G · max rss memory: 134.5 MB

stderr:
evmlean: accept (decl 18, ok); gas=5594679

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: 6.0 s · instructions: 78.5 G · max rss memory: 196.5 MB

stderr:
evmlean: reject (decl 67, unknown constant); gas=89891064

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: ✋ rejected · exit code 1 · wall time: 350 ms · instructions: 2.9 G · max rss memory: 132.9 MB

stderr:
evmlean: reject (decl 0, constructor shape); gas=252326

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: 321 ms · instructions: 2.9 G · max rss memory: 133.1 MB

stderr:
evmlean: reject (decl 0, recursor shape); gas=251673

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: 🚫 declined · exit code 2 · wall time: 227 ms · instructions: 1.8 G · max rss memory: 106.9 MB

stderr:
evmlean: export is 1276513 bytes, above EVMLEAN_MAX_BYTES=512000; declining

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: 🚫 declined · exit code 2 · wall time: 777 ms · instructions: 9.8 G · max rss memory: 137.8 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 3.2 s · instructions: 42.8 G · max rss memory: 282.1 MB

stderr:
evmlean: error (decl 23, depth limit); gas=49085379
evmlean: contract resource budget exhausted; declining

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: 🚫 declined · exit code 2 · wall time: 18.9 s · instructions: 259.5 G · max rss memory: 408.2 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 683 ms · instructions: 7.8 G · max rss memory: 133.0 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 1.8 s · instructions: 22.2 G · max rss memory: 136.9 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 1.1 s · instructions: 13.7 G · max rss memory: 139.1 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 1.0 s · instructions: 13.7 G · max rss memory: 140.6 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 223 ms · instructions: 1.8 G · max rss memory: 107.3 MB

stderr:
evmlean: export is 10184724 bytes, above EVMLEAN_MAX_BYTES=512000; declining

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: 592 ms · instructions: 6.9 G · max rss memory: 131.2 MB

stderr:
evmlean: accept (decl 15, ok); gas=4253294

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: 🚫 declined · exit code 2 · wall time: 739 ms · instructions: 8.4 G · max rss memory: 135.5 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 3.7 s · instructions: 49.1 G · max rss memory: 283.8 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 936 ms · instructions: 11.3 G · max rss memory: 135.2 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 🚫 declined · exit code 2 · wall time: 931 ms · instructions: 11.2 G · max rss memory: 135.7 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 5.3 m · instructions: 4.6 T · max rss memory: 177.3 MB

stderr:
evmlean: accept (decl 16, ok); gas=5196142304

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: 🚫 declined · exit code 2 · wall time: 833 ms · instructions: 12.0 G · max rss memory: 137.6 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: 3.5 s · instructions: 53.5 G · max rss memory: 188.9 MB

stderr:
evmlean: accept (decl 12, ok); gas=56822668

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: 🚫 declined · exit code 2 · wall time: 710 ms · instructions: 9.9 G · max rss memory: 137.7 MB

stderr:
evmlean: EVM resource exhaustion (stack overflow); declining

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: ✋ rejected · exit code 1 · wall time: 330 ms · instructions: 4.1 G · max rss memory: 133.2 MB

stderr:
evmlean: reject (decl 12, projection violation); gas=1257375

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: 675 ms · instructions: 9.4 G · max rss memory: 132.0 MB

stderr:
evmlean: reject (decl 30, projection violation); gas=7023235

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: ✋ rejected · exit code 1 · wall time: 329 ms · instructions: 3.8 G · max rss memory: 133.3 MB

stderr:
evmlean: reject (decl 11, application argument type mismatch); gas=1029716

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

  1. 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.

  2. 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.

  3. 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: 41.5 s · instructions: 593.3 G · max rss memory: 385.3 MB

stderr:
evmlean: reject (decl 163, inductive shape); gas=1210274424

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

  1. 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).

  2. 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.

  3. 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: 39.7 s · instructions: 576.8 G · max rss memory: 378.6 MB

stderr:
evmlean: reject (decl 154, inductive shape); gas=1136805404

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: 294 ms · instructions: 3.3 G · max rss memory: 132.4 MB

stderr:
evmlean: accept (decl 7, ok); gas=551084

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: 309 ms · instructions: 3.5 G · max rss memory: 133.1 MB

stderr:
evmlean: reject (decl 0, invalid K flag); gas=731594

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

  1. 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).

  2. 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).

  3. 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: 55.1 s · instructions: 758.6 G · max rss memory: 438.6 MB

stderr:
evmlean: reject (decl 168, positivity violation); gas=1532438671

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:

  1. 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.

  2. 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: 45.5 s · instructions: 568.3 G · max rss memory: 430.3 MB

stderr:
evmlean: reject (decl 158, inductive shape); gas=1144346992

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.

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 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: 413 ms · instructions: 2.8 G · max rss memory: 133.5 MB

stderr:
evmlean: accept (decl 1, ok); gas=194199

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: 🚫 declined · exit code 2 · wall time: 0 ms · max rss memory: 0 B

stderr:
Declined via the `declines` field in the checker configuration; the checker was not run.

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: 347 ms · instructions: 2.8 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 1, ok); gas=200073

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: 367 ms · instructions: 2.9 G · max rss memory: 133.6 MB

stderr:
evmlean: reject (decl 0, value/type mismatch); gas=219074

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: 360 ms · instructions: 2.9 G · max rss memory: 133.0 MB

stderr:
evmlean: accept (decl 1, ok); gas=234856

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: 446 ms · instructions: 2.9 G · max rss memory: 133.8 MB

stderr:
evmlean: accept (decl 1, ok); gas=211254

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: 375 ms · instructions: 3.0 G · max rss memory: 133.6 MB

stderr:
evmlean: accept (decl 1, ok); gas=272376

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: 396 ms · instructions: 3.1 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 2, ok); gas=383329

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: 378 ms · instructions: 3.2 G · max rss memory: 133.6 MB

stderr:
evmlean: accept (decl 2, ok); gas=417825

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: 371 ms · instructions: 3.1 G · max rss memory: 133.7 MB

stderr:
evmlean: accept (decl 2, ok); gas=385214

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: 360 ms · instructions: 3.1 G · max rss memory: 134.2 MB

stderr:
evmlean: reject (decl 1, binder domain is not a sort); gas=356585

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: 352 ms · instructions: 3.0 G · max rss memory: 133.1 MB

stderr:
evmlean: reject (decl 1, type is not a sort); gas=294760

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: 357 ms · instructions: 3.0 G · max rss memory: 135.8 MB

stderr:
evmlean: reject (decl 1, type is not a sort); gas=290483

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: 332 ms · instructions: 2.8 G · max rss memory: 133.4 MB

stderr:
evmlean: reject (decl 0, theorem type not a Prop); gas=201806

Test "tutorial/013_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: 325 ms · instructions: 2.9 G · max rss memory: 133.3 MB

stderr:
evmlean: accept (decl 1, ok); gas=235558

Test "tutorial/014_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: 385 ms · instructions: 2.9 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 1, ok); gas=245673

Test "tutorial/015_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: 353 ms · instructions: 2.9 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 1, ok); gas=265104

Test "tutorial/016_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: 385 ms · instructions: 3.1 G · max rss memory: 133.9 MB

stderr:
evmlean: accept (decl 2, ok); gas=399682

Test "tutorial/017_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: 321 ms · instructions: 2.8 G · max rss memory: 133.7 MB

stderr:
evmlean: reject (decl 0, duplicate universe param); gas=194428

Test "tutorial/018_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: 432 ms · instructions: 2.9 G · max rss memory: 134.2 MB

stderr:
evmlean: accept (decl 1, ok); gas=207560

Test "tutorial/019_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: 361 ms · instructions: 2.9 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 1, ok); gas=207425

Test "tutorial/020_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: 407 ms · instructions: 2.9 G · max rss memory: 133.0 MB

stderr:
evmlean: accept (decl 1, ok); gas=258131

Test "tutorial/021_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: 391 ms · instructions: 3.1 G · max rss memory: 134.9 MB

stderr:
evmlean: accept (decl 1, ok); gas=352225

Test "tutorial/022_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: 394 ms · instructions: 3.0 G · max rss memory: 133.5 MB

stderr:
evmlean: accept (decl 1, ok); gas=279533

Test "tutorial/023_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: 363 ms · instructions: 3.0 G · max rss memory: 133.8 MB

stderr:
evmlean: accept (decl 1, ok); gas=322530

Test "tutorial/024_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: 356 ms · instructions: 2.9 G · max rss memory: 133.7 MB

stderr:
evmlean: accept (decl 1, ok); gas=242823

Test "tutorial/025_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: 385 ms · instructions: 3.0 G · max rss memory: 132.9 MB

stderr:
evmlean: accept (decl 1, ok); gas=291576

Test "tutorial/026_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: 444 ms · instructions: 2.9 G · max rss memory: 133.9 MB

stderr:
evmlean: accept (decl 1, ok); gas=242617

Test "tutorial/027_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: 402 ms · instructions: 3.2 G · max rss memory: 133.0 MB

stderr:
evmlean: accept (decl 1, ok); gas=433582

Test "tutorial/028_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: 422 ms · instructions: 3.9 G · max rss memory: 133.3 MB

stderr:
evmlean: accept (decl 7, ok); gas=1072303

Test "tutorial/029_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: 567 ms · instructions: 5.8 G · max rss memory: 133.1 MB

stderr:
evmlean: accept (decl 8, ok); gas=3120846

Test "tutorial/030_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: 697 ms · instructions: 7.3 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 10, ok); gas=4762034

Test "tutorial/031_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: 420 ms · instructions: 2.9 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 1, ok); gas=217180

Test "tutorial/032_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: 457 ms · instructions: 3.0 G · max rss memory: 133.7 MB

stderr:
evmlean: accept (decl 3, ok); gas=339441

Test "tutorial/033_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: 429 ms · instructions: 2.9 G · max rss memory: 133.8 MB

stderr:
evmlean: accept (decl 2, ok); gas=237061

Test "tutorial/034_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: 372 ms · instructions: 3.1 G · max rss memory: 134.2 MB

stderr:
evmlean: accept (decl 4, ok); gas=367355

Test "tutorial/035_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: 437 ms · instructions: 3.5 G · max rss memory: 133.8 MB

stderr:
evmlean: accept (decl 6, ok); gas=734339

Test "tutorial/036_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: 507 ms · instructions: 4.0 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 10, ok); gas=1254502

Test "tutorial/037_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: 516 ms · instructions: 4.1 G · max rss memory: 132.5 MB

stderr:
evmlean: accept (decl 5, ok); gas=1275628

Test "tutorial/038_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: 618 ms · instructions: 6.2 G · max rss memory: 133.7 MB

stderr:
evmlean: accept (decl 5, ok); gas=3537021

Test "tutorial/039_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: 651 ms · instructions: 6.3 G · max rss memory: 132.7 MB

stderr:
evmlean: accept (decl 5, ok); gas=3788837

Test "tutorial/040_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: 511 ms · instructions: 3.3 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 5, ok); gas=555880

Test "tutorial/041_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: 613 ms · instructions: 5.3 G · max rss memory: 133.9 MB

stderr:
evmlean: accept (decl 5, ok); gas=2613394

Test "tutorial/042_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: 427 ms · instructions: 3.8 G · max rss memory: 133.0 MB

stderr:
evmlean: accept (decl 6, ok); gas=1039879

Test "tutorial/043_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: 3.2 s · instructions: 33.9 G · max rss memory: 135.3 MB

stderr:
evmlean: accept (decl 17, ok); gas=34543331

Test "tutorial/044_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: 395 ms · instructions: 3.0 G · max rss memory: 133.2 MB

stderr:
evmlean: reject (decl 1, inductive shape); gas=297739

Test "tutorial/045_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: 337 ms · instructions: 2.9 G · max rss memory: 135.8 MB

stderr:
evmlean: reject (decl 1, inductive shape); gas=220093

Test "tutorial/046_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: 307 ms · instructions: 2.9 G · max rss memory: 133.9 MB

stderr:
evmlean: reject (decl 0, duplicate universe param); gas=200781

Test "tutorial/047_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: 302 ms · instructions: 2.9 G · max rss memory: 133.3 MB

stderr:
evmlean: reject (decl 0, inductive shape); gas=216670

Test "tutorial/048_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: 303 ms · instructions: 3.0 G · max rss memory: 133.8 MB

stderr:
evmlean: reject (decl 1, constructor shape); gas=316617

Test "tutorial/049_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: 315 ms · instructions: 3.1 G · max rss memory: 133.2 MB

stderr:
evmlean: reject (decl 0, constructor result type); gas=351558

Test "tutorial/050_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: 352 ms · instructions: 3.1 G · max rss memory: 133.8 MB

stderr:
evmlean: reject (decl 0, constructor result levels); gas=377040

Test "tutorial/051_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: 310 ms · instructions: 3.0 G · max rss memory: 133.8 MB

stderr:
evmlean: reject (decl 1, constructor result type); gas=286739

Test "tutorial/052_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: 304 ms · instructions: 2.9 G · max rss memory: 134.2 MB

stderr:
evmlean: reject (decl 0, positivity violation); gas=267602

Test "tutorial/053_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: 436 ms · instructions: 5.0 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 6, ok); gas=2212781

Test "tutorial/054_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: 304 ms · instructions: 3.1 G · max rss memory: 134.1 MB

stderr:
evmlean: reject (decl 1, constructor result type); gas=350080

Test "tutorial/055_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: 302 ms · instructions: 3.1 G · max rss memory: 132.6 MB

stderr:
evmlean: reject (decl 2, positivity violation); gas=410892

Test "tutorial/056_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: 322 ms · instructions: 3.3 G · max rss memory: 132.8 MB

stderr:
evmlean: accept (decl 5, ok); gas=547578

Test "tutorial/057_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: 353 ms · instructions: 3.3 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 5, ok); gas=614945

Test "tutorial/058_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: 328 ms · instructions: 3.4 G · max rss memory: 132.4 MB

stderr:
evmlean: accept (decl 5, ok); gas=669460

Test "tutorial/059_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: 308 ms · instructions: 2.9 G · max rss memory: 133.4 MB

stderr:
evmlean: reject (decl 0, field universe too large); gas=269742

Test "tutorial/060_emptyRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 312 ms · instructions: 3.1 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 4, ok); gas=448257

Test "tutorial/061_boolRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 380 ms · instructions: 3.9 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 6, ok); gas=1131443

Test "tutorial/062_twoBoolRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 389 ms · instructions: 4.4 G · max rss memory: 133.0 MB

stderr:
evmlean: accept (decl 10, ok); gas=1602490

Test "tutorial/063_andRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 410 ms · instructions: 4.5 G · max rss memory: 133.0 MB

stderr:
evmlean: accept (decl 5, ok); gas=1750002

Test "tutorial/064_prodRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 652 ms · instructions: 7.7 G · max rss memory: 132.9 MB

stderr:
evmlean: accept (decl 5, ok); gas=5142041

Test "tutorial/065_pprodRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 696 ms · instructions: 7.7 G · max rss memory: 133.7 MB

stderr:
evmlean: accept (decl 5, ok); gas=5233557

Test "tutorial/066_punitRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 348 ms · instructions: 3.5 G · max rss memory: 133.3 MB

stderr:
evmlean: accept (decl 5, ok); gas=735632

Test "tutorial/067_eqRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 583 ms · instructions: 6.8 G · max rss memory: 132.9 MB

stderr:
evmlean: accept (decl 5, ok); gas=4288510

Test "tutorial/068_nRec"

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

Asserting the type of the generated recursor

Test result: 👍 accepted · exit code 0 · wall time: 357 ms · instructions: 4.0 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 6, ok); gas=1254100

Test "tutorial/069_rbTreeRef"

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

Asserting the type of the generated recursor

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

stderr:
evmlean: accept (decl 17, ok); gas=50839318

Test "tutorial/070_boolPropRec"

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

Inductive predicates eliminate into Prop if they have more than one constructor.

Test result: 👍 accepted · exit code 0 · wall time: 361 ms · instructions: 3.4 G · max rss memory: 133.6 MB

stderr:
evmlean: accept (decl 6, ok); gas=657203

Test "tutorial/071_BogusRecursor"

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

A kernel must not blindly trust the recursors it is handed. If we write

inductive BogusRecursor : Type where
  | mk : BogusRecursor

then the recursor BogusRecursor.rec will be correctly derived with type {motive : BogusRecursor → Sort u} → motive .mk → (t : BogusRecursor) → motive t.

This test instead claims that the recursor is a constant of type False, and then uses it to prove bogusRecursorFalse : False. A kernel that validates the recursors it is handed rejects the bogus recursor itself; a kernel that ignores them and derives the recursors anew rejects the proof of False (the derived recursor neither has type False nor zero universe parameters). Either way, this test must be rejected.

Test result: ✋ rejected · exit code 1 · wall time: 344 ms · instructions: 3.1 G · max rss memory: 132.7 MB

stderr:
evmlean: reject (decl 3, recursor shape); gas=415551

Test "tutorial/072_existsRec"

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

Inductive predicates eliminate into Prop if they have one constructors and it carries data.

Test result: 👍 accepted · exit code 0 · wall time: 426 ms · instructions: 4.4 G · max rss memory: 133.1 MB

stderr:
evmlean: accept (decl 5, ok); gas=1638735

Test "tutorial/073_typeSingletonRecReduction"

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

Because NewSingleton is a singleton, NewSingleton.rec true x reduces to true even though x is a variable.

Test result: 👍 accepted · exit code 0 · wall time: 612 ms · instructions: 6.8 G · max rss memory: 134.1 MB

stderr:
evmlean: accept (decl 15, ok); gas=4235157

Test "tutorial/074_sortElimPropRec"

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

Inductive predicates eliminate into Sort if they have one constructors and it carries data, but the data is known from the type, e.g. a parameter or an index

Test result: 👍 accepted · exit code 0 · wall time: 730 ms · instructions: 7.1 G · max rss memory: 133.9 MB

stderr:
evmlean: accept (decl 10, ok); gas=4619558

Test "tutorial/075_sortElimProp2Rec"

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

Inductive predicates eliminate into Sort if they have one constructors and it carries data, but the data is known from the type, e.g. a parameter or an index. However, it must occur directly in the result type, with no intervening reduction.

Test result: 👍 accepted · exit code 0 · wall time: 579 ms · instructions: 6.6 G · max rss memory: 133.7 MB

stderr:
evmlean: accept (decl 11, ok); gas=4025502

Test "tutorial/076_boolRecEqns"

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

Reduction behavior of Bool.rec

Test result: 👍 accepted · exit code 0 · wall time: 958 ms · instructions: 11.9 G · max rss memory: 133.0 MB

stderr:
evmlean: accept (decl 14, ok); gas=9750635

Test "tutorial/077_prodRecEqns"

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

Reduction behavior of Prod.rec

Test result: 👍 accepted · exit code 0 · wall time: 1.8 s · instructions: 24.0 G · max rss memory: 143.6 MB

stderr:
evmlean: accept (decl 9, ok); gas=23181210

Test "tutorial/078_nRecReduction"

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

A proof relying on the reduction behavior of N.rec

Test result: 👍 accepted · exit code 0 · wall time: 1.5 s · instructions: 19.9 G · max rss memory: 131.5 MB

stderr:
evmlean: accept (decl 16, ok); gas=18559660

Test "tutorial/079_listRecReduction"

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

Reduction behavior of List.rec

Test result: 👍 accepted · exit code 0 · wall time: 3.8 s · instructions: 49.9 G · max rss memory: 174.4 MB

stderr:
evmlean: accept (decl 17, ok); gas=55345470

Test "tutorial/080_RBTree.id_spec"

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

Reduction behavior of RBTree.rec

Test result: 👍 accepted · exit code 0 · wall time: 16.0 s · instructions: 224.5 G · max rss memory: 316.1 MB

stderr:
evmlean: accept (decl 23, ok); gas=406852869

Test "tutorial/081_And.right"

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

Type-checking simple projection functions

Test result: 👍 accepted · exit code 0 · wall time: 381 ms · instructions: 4.3 G · max rss memory: 132.9 MB

stderr:
evmlean: accept (decl 6, ok); gas=1584904

Test "tutorial/082_Prod.snd"

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

Type-checking projection functions with parameters

Test result: 👍 accepted · exit code 0 · wall time: 543 ms · instructions: 6.9 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 6, ok); gas=4330483

Test "tutorial/083_PProd.snd"

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

Type-checking projection functions

Test result: 👍 accepted · exit code 0 · wall time: 525 ms · instructions: 6.7 G · max rss memory: 133.2 MB

stderr:
evmlean: accept (decl 6, ok); gas=4260714

Test "tutorial/084_PSigma.snd"

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

Type-checking dependent projection functions

Test result: 👍 accepted · exit code 0 · wall time: 666 ms · instructions: 8.4 G · max rss memory: 133.5 MB

stderr:
evmlean: accept (decl 6, ok); gas=6042300

Test "tutorial/085_projOutOfRange"

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

Out of range projection

Test result: ✋ rejected · exit code 1 · wall time: 353 ms · instructions: 4.2 G · max rss memory: 132.4 MB

stderr:
evmlean: reject (decl 4, projection violation); gas=1432684

Test "tutorial/086_projNotStruct"

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

Projection out something that is not a structure

Test result: ✋ rejected · exit code 1 · wall time: 333 ms · instructions: 3.8 G · max rss memory: 132.7 MB

stderr:
evmlean: reject (decl 5, projection violation); gas=1069504

Test "tutorial/087_projProp1"

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

Projecting out of a proposition

The lean kernel allows projections out of propositions if they precede all dependent data fields.

Test result: 👍 accepted · exit code 0 · wall time: 521 ms · instructions: 6.9 G · max rss memory: 133.5 MB

stderr:
evmlean: accept (decl 13, ok); gas=4363327

Test "tutorial/088_projProp2"

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

Projecting out of a proposition

The lean kernel disallows data projections out of propositional structures.

Test result: ✋ rejected · exit code 1 · wall time: 539 ms · instructions: 7.0 G · max rss memory: 134.4 MB

stderr:
evmlean: reject (decl 12, projection violation); gas=4385127

Test "tutorial/089_projProp3"

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

Projecting out of a proposition

The lean kernel allows projections out of propositions if they precede all dependent data fields. Non-dependent data fields are not relevant.

Test result: 👍 accepted · exit code 0 · wall time: 520 ms · instructions: 7.0 G · max rss memory: 134.5 MB

stderr:
evmlean: accept (decl 13, ok); gas=4407341

Test "tutorial/090_projProp4"

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

Projecting out of a proposition

The lean kernel disallows data projections out of propositional structures.

Test result: ✋ rejected · exit code 1 · wall time: 532 ms · instructions: 7.0 G · max rss memory: 133.1 MB

stderr:
evmlean: reject (decl 12, projection violation); gas=4424285

Test "tutorial/091_projProp5"

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

Projecting out of a proposition

The lean kernel disallows proof projections out of propositional structures that depend on data.

Test result: ✋ rejected · exit code 1 · wall time: 553 ms · instructions: 7.1 G · max rss memory: 131.9 MB

stderr:
evmlean: reject (decl 12, projection violation); gas=4445699

Test "tutorial/092_projProp6"

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

Projecting out of a proposition.

The lean kernel rejects any projections out of a proposition that come after a dependent data field, even if that is not used by the present projection.

Test result: ✋ rejected · exit code 1 · wall time: 557 ms · instructions: 7.0 G · max rss memory: 132.7 MB

stderr:
evmlean: reject (decl 12, projection violation); gas=4425793

Test "tutorial/093_MaybeProp.mk"

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

A structure that is a proposition for one instantiation of its universe parameter.

All of the above concerns structures that are propositions. A structure whose sort is a bare level parameter is 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. Sort (max u v) poses the same question, which is why PProd and PSigma land in Sort (max 1 u v) — a dependent pair kept at the exact maximum of its components has to be declared this way.

The recursor eliminates into Prop only, since the kernel cannot rule out that MaybeProp is a proposition. Whichever way a kernel answers that question while checking this declaration, it has to answer it the same way when the fields are projected out again (projMaybeProp) — the exemption that lets a proposition carry fields from any universe and the ban on projecting data out of one are a matched pair.

Test result: 👍 accepted · exit code 0 · wall time: 518 ms · instructions: 6.6 G · max rss memory: 134.3 MB

stderr:
evmlean: accept (decl 16, ok); gas=4024373

Test "tutorial/094_projMaybeProp"

Expected: 👍 accept · 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.

The field MaybeProp.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 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.

That argument only holds if both checks answer "is this a proposition?" the same way. Waiving the field universe bound (predWithTypeField) and forbidding data projections (projProp2) are two halves of one rule, and a kernel that is generous when declaring the inductive and strict when checking the projection admits a data field into a proposition — which proof irrelevance then collapses, giving a proof of False.

Erring in the other direction is safe but incomplete, and that is what happens here: a kernel that asks "could this be a proposition?" and then demands that the field be definitely a proof rejects a legitimate declaration.

Test result: 👍 accepted · exit code 0 · wall time: 482 ms · instructions: 6.7 G · max rss memory: 134.0 MB

stderr:
evmlean: accept (decl 17, ok); gas=4115503

Test "tutorial/095_projMaybePropPast"

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

The same, 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 mistaken reading. But reaching it means walking past field, which proof depends on, and that is where the check on a genuine proposition (projProp6) fires. A kernel that rejects projMaybeProp therefore rejects this one as well, at field 0 rather than at field 2.

Test result: 👍 accepted · exit code 0 · wall time: 563 ms · instructions: 6.7 G · max rss memory: 132.9 MB

stderr:
evmlean: accept (decl 17, ok); gas=4129329

Test "tutorial/096_projDataIndexRec"

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

The recursor for ProjDataIndex allows elimination into sort.

Test result: 👍 accepted · exit code 0 · wall time: 389 ms · instructions: 4.9 G · max rss memory: 134.5 MB

stderr:
evmlean: accept (decl 14, ok); gas=2152064

Test "tutorial/097_projIndexData"

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

Projecting out data is not allowed, even if this data appears as an index and the recursor would allow it.

Test result: ✋ rejected · exit code 1 · wall time: 379 ms · instructions: 4.7 G · max rss memory: 134.8 MB

stderr:
evmlean: reject (decl 13, unknown constant); gas=1921591

Test "tutorial/098_projIndexData2"

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

Projecting out data is not allowed, even if this data appears as an index and the recursor would allow it.

This also forbids projecting out proofs that follow such fields.

Test result: ✋ rejected · exit code 1 · wall time: 394 ms · instructions: 4.7 G · max rss memory: 133.8 MB

stderr:
evmlean: reject (decl 13, unknown constant); gas=1922796

Test "tutorial/099_projRed"

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

Projection reductions

Test result: 👍 accepted · exit code 0 · wall time: 720 ms · instructions: 10.0 G · max rss memory: 133.3 MB

stderr:
evmlean: accept (decl 16, ok); gas=7729726

Test "tutorial/100_ruleK"

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

Rule k for Eq: The recursor reduces even if the major argument is not a constructor, as long replacing the major argument with a constructor is type correct.

Test result: 👍 accepted · exit code 0 · wall time: 509 ms · instructions: 6.7 G · max rss memory: 134.1 MB

stderr:
evmlean: accept (decl 10, ok); gas=4094645

Test "tutorial/101_ruleKbad"

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

Rule k for Eq should not fire if the types of the major argument do not match that of the constructor.

Test result: ✋ rejected · exit code 1 · wall time: 521 ms · instructions: 6.9 G · max rss memory: 133.9 MB

stderr:
evmlean: reject (decl 9, value/type mismatch); gas=4338073

Test "tutorial/102_ruleKAcc"

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

Rule k should not fire for Acc.

Test result: ✋ rejected · exit code 1 · wall time: 1.1 s · instructions: 16.0 G · max rss memory: 132.6 MB

stderr:
evmlean: reject (decl 13, value/type mismatch); gas=14348957

Test "tutorial/103_aNatLit"

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

Type checking Nat literals

Test result: 👍 accepted · exit code 0 · wall time: 334 ms · instructions: 3.8 G · max rss memory: 133.3 MB

stderr:
evmlean: accept (decl 6, ok); gas=1005457

Test "tutorial/104_natLitEq"

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

Reducing Nat literals

Test result: 👍 accepted · exit code 0 · wall time: 540 ms · instructions: 6.3 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 10, ok); gas=3683993

Test "tutorial/105_proofIrrelevance"

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

Proof irrelevance: every Prop is a subsingleton, if p : Prop then all elements of p are definitionally equal.

Test result: 👍 accepted · exit code 0 · wall time: 437 ms · instructions: 5.8 G · max rss memory: 133.3 MB

stderr:
evmlean: accept (decl 6, ok); gas=3161849

Test "tutorial/106_proofIrrelevanceBad"

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

Proof irrelevance is limited to Prop: if p : Type, then all elements of p are not definitionally equal.

Test result: ✋ rejected · exit code 1 · wall time: 459 ms · instructions: 5.9 G · max rss memory: 133.5 MB

stderr:
evmlean: reject (decl 5, value/type mismatch); gas=3223410

Test "tutorial/107_proofIrrelevanceWhnf"

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

Proof irrelevance: if p : A and A is definitionally equal to Prop, then all elements of p are still definitionally equal. Just applying proof irrelevance at Sort 0 isn't sufficient.

Test result: 👍 accepted · exit code 0 · wall time: 486 ms · instructions: 6.5 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 7, ok); gas=3918923

Test "tutorial/108_unitEta1"

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

Unit eta

Test result: 👍 accepted · exit code 0 · wall time: 492 ms · instructions: 6.1 G · max rss memory: 133.9 MB

stderr:
evmlean: accept (decl 11, ok); gas=3451759

Test "tutorial/109_unitEta2"

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

Unit eta

Test result: 👍 accepted · exit code 0 · wall time: 479 ms · instructions: 6.0 G · max rss memory: 132.8 MB

stderr:
evmlean: accept (decl 10, ok); gas=3403071

Test "tutorial/110_unitEta3"

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

Unit eta

Test result: 👍 accepted · exit code 0 · wall time: 475 ms · instructions: 6.0 G · max rss memory: 132.4 MB

stderr:
evmlean: accept (decl 10, ok); gas=3395643

Test "tutorial/111_indexedUnitEta"

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

The unit-like rule, which makes any two elements of a single-constructor type with no fields definitionally equal, is also restricted to non-recursive structures without indices (is_def_eq_unit_like goes through is_non_rec_structure), so it does not fire for IndexedUnit.

Test result: ✋ rejected · exit code 1 · wall time: 501 ms · instructions: 6.7 G · max rss memory: 133.8 MB

stderr:
evmlean: reject (decl 13, value/type mismatch); gas=4172145

Test "tutorial/112_structEta"

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

Structure eta

Test result: 👍 accepted · exit code 0 · wall time: 973 ms · instructions: 14.3 G · max rss memory: 132.0 MB

stderr:
evmlean: accept (decl 16, ok); gas=12383822

Test "tutorial/113_indexedStructEta"

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

Structure eta applies only to non-recursive structures without indices: the official kernel's is_non_rec_structure requires nindices == 0, so it does not fire for IndexedSingleton even though that has a single constructor.

Every field of IndexedSingleton.mk is a proof, so a kernel that checks only "has a single constructor" and then compares the fields against projections would have proof irrelevance discharge the remaining goals, and would wrongly accept this.

Test result: ✋ rejected · exit code 1 · wall time: 556 ms · instructions: 7.2 G · max rss memory: 134.5 MB

stderr:
evmlean: reject (decl 17, value/type mismatch); gas=4688140

Test "tutorial/114_funEta"

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

Function eta for non-dependent functions.

Test result: 👍 accepted · exit code 0 · wall time: 458 ms · instructions: 6.1 G · max rss memory: 132.8 MB

stderr:
evmlean: accept (decl 6, ok); gas=3474167

Test "tutorial/115_funEtaDep"

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

Function eta for dependent functions (pi types).

Test result: 👍 accepted · exit code 0 · wall time: 486 ms · instructions: 6.3 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 6, ok); gas=3740958

Test "tutorial/116_funEtaBad"

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

Eta should not identify functions with different bodies.

Test result: ✋ rejected · exit code 1 · wall time: 523 ms · instructions: 6.6 G · max rss memory: 133.4 MB

stderr:
evmlean: reject (decl 4, value/type mismatch); gas=4067395

Test "tutorial/117_etaRuleK"

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

Corner case for function eta: Does a defeq between a partially applied recursor with rule k and a free variable trigger eta expansion?

Taking the official kernel as the specification, the answer is no. See https://github.com/leanprover/lean4/issues/12520 for a discussion.

Test result: ✋ rejected · exit code 1 · wall time: 551 ms · instructions: 7.4 G · max rss memory: 133.4 MB

stderr:
evmlean: reject (decl 9, value/type mismatch); gas=4912551

Test "tutorial/118_etaCtor"

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

Corner case for function eta: Does a defeq between a partially applied constructor trigger eta expansion?

Taking the official kernel as the specification, the answer is no. See https://github.com/leanprover/lean4/issues/12520 for a discussion.

Test result: ✋ rejected · exit code 1 · wall time: 567 ms · instructions: 7.3 G · max rss memory: 133.4 MB

stderr:
evmlean: reject (decl 18, value/type mismatch); gas=4739945

Test "tutorial/119_reflOccLeft"

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

Rejection: recursive occurrence on the left of an arrow, behind further arrows inside a constructor argument.

The constructor argument is a function type Nat → (I → Nat).

Test result: ✋ rejected · exit code 1 · wall time: 349 ms · instructions: 3.9 G · max rss memory: 133.1 MB

stderr:
evmlean: reject (decl 5, positivity violation); gas=1095279

Test "tutorial/120_reflOccInIndex"

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

Rejection: recursive occurrence in index position, behind a further arrow.

We build an indexed inductive I : Type → Type with a constructor argument Nat → I (I α), so the recursive occurrence appears as an index argument.

Test result: ✋ rejected · exit code 1 · wall time: 327 ms · instructions: 3.9 G · max rss memory: 133.7 MB

stderr:
evmlean: reject (decl 5, application argument type mismatch); gas=1136059

Test "tutorial/121_reduceCtorParamRefl.mk"

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

When checking inductives, we expect the kernel to reduce the types of constructor arguments in all positive positions.

Test result: 👍 accepted · exit code 0 · wall time: 452 ms · instructions: 5.5 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 6, ok); gas=2870207

Test "tutorial/122_reduceCtorParamRefl2.mk"

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

When checking inductives, we expect the kernel to reduce the types of constructor arguments in all positive positions.

Test result: 👍 accepted · exit code 0 · wall time: 411 ms · instructions: 5.4 G · max rss memory: 133.5 MB

stderr:
evmlean: accept (decl 6, ok); gas=2777338

Test "tutorial/123_rTreeRec"

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

Asserting the type of the generated recursor.

Test result: 👍 accepted · exit code 0 · wall time: 420 ms · instructions: 5.3 G · max rss memory: 133.7 MB

stderr:
evmlean: accept (decl 11, ok); gas=2669755

Test "tutorial/124_rtreeRecReduction"

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

Reduction behavior of RTree.rec on RTree.mk.

Test result: 👍 accepted · exit code 0 · wall time: 684 ms · instructions: 9.5 G · max rss memory: 132.8 MB

stderr:
evmlean: accept (decl 17, ok); gas=7176870

Test "tutorial/125_accRecType"

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

Asserting the type of Acc.rec.

Test result: 👍 accepted · exit code 0 · wall time: 1.1 s · instructions: 15.3 G · max rss memory: 133.5 MB

stderr:
evmlean: accept (decl 5, ok); gas=13686486

Test "tutorial/126_accRecReduction"

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

Acc.rec reduces on Acc.intro.

Test result: 👍 accepted · exit code 0 · wall time: 3.0 s · instructions: 44.4 G · max rss memory: 157.2 MB

stderr:
evmlean: accept (decl 14, ok); gas=47891772

Test "tutorial/127_accRecNoEta"

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

Acc.rec does not have structure eta.

Test result: ✋ rejected · exit code 1 · wall time: 1.1 s · instructions: 15.8 G · max rss memory: 132.8 MB

stderr:
evmlean: reject (decl 13, value/type mismatch); gas=14198533

Test "tutorial/128_quotMkType"

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

Asserting the type of Quot.mk.

Test result: 👍 accepted · exit code 0 · wall time: 639 ms · instructions: 8.1 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 9, ok); gas=5706284

Test "tutorial/129_quotIndType"

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

Asserting the type of Quot.ind.

Test result: 👍 accepted · exit code 0 · wall time: 934 ms · instructions: 8.3 G · max rss memory: 133.4 MB

stderr:
evmlean: accept (decl 9, ok); gas=5884836

Test "tutorial/130_quotLiftType"

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

Asserting the type of Quot.lift.

Test result: 👍 accepted · exit code 0 · wall time: 777 ms · instructions: 10.0 G · max rss memory: 133.1 MB

stderr:
evmlean: accept (decl 9, ok); gas=7762986

Test "tutorial/131_quotSoundType"

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

Asserting the type of Quot.sound.

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

stderr:
evmlean: accept (decl 10, ok); gas=6288484

Test "tutorial/132_quotLiftReduction"

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

Reduction behavior of Quot.lift on Quot.mk.

Test result: 👍 accepted · exit code 0 · wall time: 999 ms · instructions: 14.4 G · max rss memory: 133.6 MB

stderr:
evmlean: accept (decl 9, ok); gas=12531323

Test "tutorial/133_quotIndReduction"

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

Reduction behavior of Quot.ind on Quot.mk.

Test result: 👍 accepted · exit code 0 · wall time: 948 ms · instructions: 13.6 G · max rss memory: 134.3 MB

stderr:
evmlean: accept (decl 9, ok); gas=11737843

Test "tutorial/134_dup_defs"

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

Two definitions with the same name

Test result: ✋ rejected · exit code 1 · wall time: 280 ms · instructions: 2.8 G · max rss memory: 133.8 MB

stderr:
evmlean: reject (decl 1, duplicate name); gas=202074

Test "tutorial/135_dup_ind_def"

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

A definition and a constructor with the same name

Test result: ✋ rejected · exit code 1 · wall time: 268 ms · instructions: 2.9 G · max rss memory: 133.0 MB

stderr:
evmlean: reject (decl 1, duplicate name); gas=270674

Test "tutorial/136_dup_ctor_def"

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

A definition and a constructor with the same name

Test result: ✋ rejected · exit code 1 · wall time: 283 ms · instructions: 3.0 G · max rss memory: 132.8 MB

stderr:
evmlean: reject (decl 1, duplicate name); gas=287209

Test "tutorial/137_dup_rec_def"

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

A definition and a recursor with the same name

Test result: ✋ rejected · exit code 1 · wall time: 272 ms · instructions: 3.0 G · max rss memory: 133.5 MB

stderr:
evmlean: reject (decl 1, duplicate name); gas=311501

Test "tutorial/138_misnamed_rec_user"

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

The name of the recursor for misnamed_rec must be misnamed_rec.rec: another name (like misnamed_rec.not_rec) should be rejected. dupRecUser is included so that checkers that recreate the recursor (as misnamed_rec.rec) rather than validating it still fail, because misnamed_rec_user references misnamed_rec.not_rec.

Test result: ✋ rejected · exit code 1 · wall time: 280 ms · instructions: 3.0 G · max rss memory: 133.3 MB

stderr:
evmlean: reject (decl 0, recursor shape); gas=315661

Test "tutorial/139_dup_rec_def2"

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

Even if a kernel doesn't catch a recursor for dup_rec_def2 that is misnamed as dup_rec_def2.not_rec, it should catch some other constant being given the name dup_rec_def2.rec that is reserved for the recursor.

Test result: ✋ rejected · exit code 1 · wall time: 279 ms · instructions: 3.0 G · max rss memory: 133.3 MB

stderr:
evmlean: reject (decl 1, recursor shape); gas=316909

Test "tutorial/140_dup_ctor_rec"

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

A constructor and a recursor with the same name

Test result: ✋ rejected · exit code 1 · wall time: 282 ms · instructions: 3.0 G · max rss memory: 132.2 MB

stderr:
evmlean: reject (decl 0, duplicate name); gas=285932

Test "tutorial/141_DupConCon"

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

An inductive with two constructors with the same name

Test result: ✋ rejected · exit code 1 · wall time: 280 ms · instructions: 3.0 G · max rss memory: 133.2 MB

stderr:
evmlean: reject (decl 0, duplicate name); gas=304810

Test "undecidability/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: 10.8 s · instructions: 159.2 G · max rss memory: 231.0 MB

stderr:
evmlean: reject (decl 77, value/type mismatch); gas=196177457

Test "undecidability/alg-conv-trans-acc-left"

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

The creative half of undecidability/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: 👍 accepted · exit code 0 · wall time: 8.8 s · instructions: 132.7 G · max rss memory: 222.6 MB

stderr:
evmlean: accept (decl 79, ok); gas=162560121

Test "undecidability/alg-conv-trans-acc-right"

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

The mechanical half of undecidability/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: 15.8 s · instructions: 235.2 G · max rss memory: 334.3 MB

stderr:
evmlean: accept (decl 79, ok); gas=329095574

Test "undecidability/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: 1.3 s · instructions: 18.6 G · max rss memory: 144.6 MB

stderr:
evmlean: reject (decl 8, value/type mismatch); gas=17298493

Test "undecidability/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: 1.3 s · instructions: 18.7 G · max rss memory: 144.0 MB

stderr:
evmlean: reject (decl 8, value/type mismatch); gas=17669572

Test "undecidability/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: 👍 accepted · exit code 0 · wall time: 1.2 s · instructions: 17.4 G · max rss memory: 132.9 MB

stderr:
evmlean: accept (decl 11, ok); gas=15886093

Test "undecidability/alg-conv-trans-quot-right"

Expected: 👍 accept · 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: 1.0 s · instructions: 14.7 G · max rss memory: 132.8 MB

stderr:
evmlean: accept (decl 10, ok); gas=12813336

Test "undecidability/subject-reduction-redex"

Expected: 👍 accept · 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 undecidability/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: 👍 accepted · exit code 0 · wall time: 14.9 s · instructions: 222.2 G · max rss memory: 290.7 MB

stderr:
evmlean: accept (decl 77, ok); gas=312939777

Test "undecidability/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 undecidability/subject-reduction-redex, and with it the middle term, leaving the two endpoints to compare: the conversion of undecidability/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: 10.6 s · instructions: 155.8 G · max rss memory: 204.1 MB

stderr:
evmlean: reject (decl 75, application argument type mismatch); gas=193892725