Lean Kernel Arena / ind-models

Checker "ind-models"

Version: main (b3df02d) · 📄 Declaration · 🔗 Source

lean-inductive-models is a Lean 4 NDJSON-to-NDJSON filter and standalone model checker. It adds an ordinary-declaration model of each supported inductive while retaining the original declaration, and structurally checks that the generated models correspond to their source declarations.

In the arena it runs as a checker: the input declarations are replayed through Lean's kernel (--type-check-input), models are generated for all supported inductives and kernel-checked as they are produced, and the structural checker validates the model-to-source correspondence. The transformed output is discarded (--no-output).

Since it is built on the official Lean kernel, it is not an independent kernel implementation. However, by re-deriving each inductive's recursor and reduction behavior from first principles and verifying the result, it can catch a large class of potential implementation bugs in the kernel's handling of inductives.

Completeness (rightfully accepted tests)

124/124

Soundness (rightfully rejected tests)

63/63

Declined tests

4

Test Expected Result ⏱️ 🧠
bogus1 ✋ ✋ 59 ms 107.3 MB
cedar 👍 👍 3.5 m (+45%) 1.2 GB (-21%)
constlevels ✋ ✋ 59 ms 106.7 MB
cslib 👍 👍 8.3 m (+17%) 3.2 GB (-12%)
ctor-num-fields ✋ ✋ 61 ms 107.4 MB
extra-rec ✋ ✋ 58 ms 104.0 MB
init 👍 👍 1.2 m (+8%) 517.3 MB (-6%)
init-prelude 👍 👍 827 ms (×2.2) 119.6 MB (+66%)
k-rec-conv ✋ ✋ 59 ms 106.7 MB
large-elim-param ✋ ✋ 58 ms 100.9 MB
level-imax-leq ✋ ✋ 58 ms 104.0 MB
level-imax-normalization ✋ ✋ 58 ms 102.6 MB
level-index-out-of-order 👍 👍 58 ms 102.3 MB
mathlib 👍 👍 31.7 m (+8%) 7.9 GB (-13%)
nat-rec-k-lie ✋ ✋ 58 ms 101.4 MB
nat-rec-rules ✋ ✋ 60 ms 104.3 MB
nested-nonuniform-param 🤷 👍 74 ms 106.0 MB
nested-unused-param ✋ ✋ 63 ms 106.0 MB
proj-non-structure ✋ ✋ 58 ms 104.1 MB
proj-of-imax-prop ✋ ✋ 59 ms 103.2 MB
proj-of-prop ✋ ✋ 58 ms 104.7 MB
proj-of-stuck-prop ✋ 💥 119 ms 108.4 MB
proj-of-subst-prop ✋ 💥 114 ms 102.9 MB
proof-irrel 👍 👍 58 ms 99.5 MB
rec-k-lie ✋ ✋ 58 ms 100.7 MB
rec-missing-ih ✋ 💥 121 ms 101.8 MB
rec-of-subst-prop ✋ 💥 118 ms 102.0 MB
sparse-name-index 👍 👍 58 ms 100.9 MB
std 👍 👍 2.1 m (+10%) 861.8 MB (-14%)
18 21.8 s (+8%) 1.4 GB
app-lam 👍 👍 4.9 s (+1%) 1.4 GB (+2%)
args-before-unfold 👍 👍 70 ms (+92%) 107.3 MB (+62%)
beta-ladder 👍 👍 1.7 s (+2%) 532.0 MB (+7%)
church-numerals 👍 👍 81 ms (+61%) 108.7 MB (+46%)
discarded-argument 👍 👍 696 ms (+5%) 104.5 MB (+59%)
discarded-argument-match 👍 👍 8.6 s (0%) 106.0 MB (+56%)
folded-constant-first 👍 👍 79 ms (+93%) 111.4 MB (+61%)
folded-constant-last 👍 👍 79 ms (+93%) 108.5 MB (+58%)
grind-ring-5 👍 👍 3.0 s (+33%) 268.3 MB (+17%)
identical-nesting 👍 👍 62 ms (×2.2) 104.4 MB (+64%)
irrelevance-before-evaluation 👍 👍 63 ms (×2.2) 104.7 MB (+65%)
let-ladder 👍 👍 1.1 s (+4%) 351.7 MB (+12%)
refute-cheap-first ✋ ✋ 72 ms 109.5 MB
refute-cheap-last ✋ ✋ 723 ms 105.3 MB
repeated-subproblem 👍 👍 185 ms (×6.5) 109.0 MB (+71%)
shared-subterm 👍 👍 216 ms (×3.7) 113.3 MB (+61%)
shift-cascade 👍 👍 79 ms (+70%) 102.6 MB (+56%)
unroll-versus-evaluate 👍 👍 65 ms (×2.1) 108.9 MB (+65%)
141 9.1 s (×2.5) 110.9 MB
001_basicDef 👍 👍 58 ms 102.8 MB
002_badDef ✋ ✋ 58 ms 104.5 MB
003_arrowType 👍 👍 58 ms 100.4 MB
004_dependentType 👍 👍 58 ms 101.9 MB
005_constType 👍 👍 58 ms 100.9 MB
006_betaReduction 👍 👍 58 ms 100.7 MB
007_betaReduction2 👍 👍 58 ms 100.0 MB
008_forallSortWhnf 👍 👍 58 ms 99.9 MB
009_forallSortBad ✋ ✋ 58 ms 103.7 MB
010_nonTypeType ✋ ✋ 58 ms 101.0 MB
011_nonTypeAxiom ✋ ✋ 58 ms 104.8 MB
012_nonPropThm ✋ ✋ 58 ms 100.7 MB
013_levelComp1 👍 👍 58 ms 103.1 MB
014_levelComp2 👍 👍 58 ms 103.0 MB
015_levelComp3 👍 👍 58 ms 103.3 MB
016_levelParams 👍 👍 58 ms 100.9 MB
017_tut06_bad01 ✋ ✋ 58 ms 103.7 MB
018_levelComp4 👍 👍 58 ms 103.0 MB
019_levelComp5 👍 👍 58 ms 103.4 MB
020_imax1 👍 👍 58 ms 100.9 MB
021_imax2 👍 👍 58 ms 103.1 MB
022_levelMaxComm 👍 👍 58 ms 100.7 MB
023_levelMaxAssoc 👍 👍 58 ms 102.7 MB
024_levelMaxIdem 👍 👍 58 ms 102.7 MB
025_levelMaxAbsorb 👍 👍 58 ms 100.9 MB
026_inferVar 👍 👍 58 ms 103.6 MB
027_defEqLambda 👍 👍 58 ms 103.2 MB
028_peano1 👍 👍 58 ms 103.5 MB
029_peano2 👍 👍 58 ms 102.7 MB
030_peano3 👍 👍 58 ms 103.4 MB
031_letType 👍 👍 58 ms 100.4 MB
032_letTypeDep 👍 👍 58 ms 101.7 MB
033_letRed 👍 👍 58 ms 100.8 MB
034_empty 👍 👍 59 ms 104.8 MB
035_boolType 👍 👍 60 ms 101.6 MB
036_twoBool 👍 👍 63 ms 105.9 MB
037_andType 👍 👍 59 ms 104.9 MB
038_prodType 👍 👍 62 ms 105.0 MB
039_pprodType 👍 👍 62 ms 105.4 MB
040_pUnitType 👍 👍 58 ms 99.6 MB
041_eqType 👍 👍 58 ms 102.6 MB
042_natDef 👍 👍 61 ms 105.3 MB
043_rbTreeDef 👍 👍 207 ms 110.9 MB
044_inductBadNonSort ✋ ✋ 58 ms 101.2 MB
045_inductBadNonSort2 ✋ ✋ 58 ms 104.9 MB
046_inductLevelParam ✋ ✋ 58 ms 100.0 MB
047_inductTooFewParams ✋ ✋ 58 ms 99.8 MB
048_inductWrongCtorParams ✋ ✋ 58 ms 100.1 MB
049_inductWrongCtorResParams ✋ ✋ 58 ms 99.9 MB
050_inductWrongCtorResLevel ✋ ✋ 58 ms 102.4 MB
051_inductInIndex ✋ ✋ 58 ms 100.3 MB
052_indNeg ✋ ✋ 58 ms 102.9 MB
053_reduceCtorParam.mk 👍 👍 60 ms 105.4 MB
054_reduceCtorType.mk ✋ ✋ 58 ms 100.1 MB
055_indNegReducible ✋ ✋ 58 ms 103.7 MB
056_predWithTypeField 👍 👍 58 ms 101.2 MB
057_typeWithTypeField 👍 👍 58 ms 104.3 MB
058_typeWithTypeFieldPoly 👍 👍 58 ms 105.4 MB
059_typeWithTooHighTypeField.mk ✋ ✋ 58 ms 104.6 MB
060_emptyRec 👍 👍 59 ms 101.8 MB
061_boolRec 👍 👍 60 ms 101.8 MB
062_twoBoolRec 👍 👍 63 ms 105.7 MB
063_andRec 👍 👍 59 ms 103.2 MB
064_prodRec 👍 👍 62 ms 104.2 MB
065_pprodRec 👍 👍 62 ms 105.1 MB
066_punitRec 👍 👍 58 ms 103.4 MB
067_eqRec 👍 👍 58 ms 99.8 MB
068_nRec 👍 👍 61 ms 101.7 MB
069_rbTreeRef 👍 👍 207 ms 109.3 MB
070_boolPropRec 👍 👍 58 ms 104.2 MB
071_BogusRecursor ✋ ✋ 58 ms 103.9 MB
072_existsRec 👍 👍 59 ms 102.1 MB
073_typeSingletonRecReduction 👍 👍 62 ms 104.9 MB
074_sortElimPropRec 👍 👍 61 ms 104.9 MB
075_sortElimProp2Rec 👍 👍 61 ms 104.7 MB
076_boolRecEqns 👍 👍 62 ms 104.0 MB
077_prodRecEqns 👍 👍 62 ms 102.2 MB
078_nRecReduction 👍 👍 63 ms 104.4 MB
079_listRecReduction 👍 👍 67 ms 104.5 MB
080_RBTree.id_spec 👍 👍 210 ms 108.7 MB
081_And.right 👍 👍 59 ms 102.1 MB
082_Prod.snd 👍 👍 62 ms 102.0 MB
083_PProd.snd 👍 👍 62 ms 105.4 MB
084_PSigma.snd 👍 👍 62 ms 106.1 MB
085_projOutOfRange ✋ ✋ 58 ms 104.3 MB
086_projNotStruct ✋ ✋ 58 ms 104.2 MB
087_projProp1 👍 👍 59 ms 104.0 MB
088_projProp2 ✋ ✋ 58 ms 104.4 MB
089_projProp3 👍 👍 59 ms 103.8 MB
090_projProp4 ✋ ✋ 58 ms 104.0 MB
091_projProp5 ✋ ✋ 58 ms 101.3 MB
092_projProp6 ✋ ✋ 58 ms 104.8 MB
093_MaybeProp.mk 👍 👍 63 ms 103.1 MB
094_projMaybeProp 👍 👍 63 ms 106.0 MB
095_projMaybePropPast 👍 👍 63 ms 104.8 MB
096_projDataIndexRec 👍 👍 63 ms 101.9 MB
097_projIndexData ✋ ✋ 58 ms 102.1 MB
098_projIndexData2 ✋ ✋ 58 ms 104.2 MB
099_projRed 👍 👍 64 ms 105.9 MB
100_ruleK 👍 👍 60 ms 104.6 MB
101_ruleKbad ✋ ✋ 59 ms 104.2 MB
102_ruleKAcc ✋ ✋ 60 ms 101.2 MB
103_aNatLit 👍 👍 58 ms 103.2 MB
104_natLitEq 👍 👍 58 ms 99.3 MB
105_proofIrrelevance 👍 👍 58 ms 103.5 MB
106_proofIrrelevanceBad ✋ ✋ 58 ms 103.2 MB
107_proofIrrelevanceWhnf 👍 👍 58 ms 99.7 MB
108_unitEta1 👍 👍 58 ms 102.7 MB
109_unitEta2 👍 👍 58 ms 102.8 MB
110_unitEta3 👍 👍 58 ms 100.2 MB
111_indexedUnitEta ✋ ✋ 59 ms 104.8 MB
112_structEta 👍 👍 64 ms 105.8 MB
113_indexedStructEta ✋ ✋ 59 ms 102.2 MB
114_funEta 👍 👍 58 ms 102.0 MB
115_funEtaDep 👍 👍 58 ms 99.8 MB
116_funEtaBad ✋ ✋ 59 ms 101.1 MB
117_etaRuleK ✋ ✋ 59 ms 100.9 MB
118_etaCtor ✋ ✋ 59 ms 101.8 MB
119_reflOccLeft ✋ ✋ 58 ms 103.0 MB
120_reflOccInIndex ✋ ✋ 58 ms 103.4 MB
121_reduceCtorParamRefl.mk 👍 👍 183 ms 109.2 MB
122_reduceCtorParamRefl2.mk 👍 👍 183 ms 106.8 MB
123_rTreeRec 👍 👍 184 ms 109.1 MB
124_rtreeRecReduction 👍 👍 184 ms 108.4 MB
125_accRecType 👍 👍 67 ms 102.5 MB
126_accRecReduction 👍 👍 69 ms 102.8 MB
127_accRecNoEta ✋ ✋ 60 ms 104.2 MB
128_quotMkType 👍 👍 58 ms 103.6 MB
129_quotIndType 👍 👍 58 ms 102.2 MB
130_quotLiftType 👍 👍 58 ms 103.3 MB
131_quotSoundType 👍 👍 58 ms 101.6 MB
132_quotLiftReduction 👍 👍 58 ms 100.2 MB
133_quotIndReduction 👍 👍 58 ms 103.3 MB
134_dup_defs ✋ ✋ 27 ms 98.2 MB
135_dup_ind_def ✋ ✋ 27 ms 100.2 MB
136_dup_ctor_def ✋ ✋ 27 ms 97.8 MB
137_dup_rec_def ✋ ✋ 27 ms 100.6 MB
138_misnamed_rec_user ✋ ✋ 58 ms 102.2 MB
139_dup_rec_def2 ✋ ✋ 58 ms 100.1 MB
140_dup_ctor_rec ✋ ✋ 27 ms 97.2 MB
141_DupConCon ✋ ✋ 27 ms 97.5 MB
4 620 ms (×2.4) 108.7 MB
alg-conv-trans-acc 🤷 ✋ 65 ms 107.2 MB
alg-conv-trans-acc-left 👍 👍 84 ms 105.0 MB
alg-conv-trans-acc-right 👍 👍 84 ms 108.7 MB
alg-conv-trans-quot 🤷 ✋ 60 ms 103.2 MB
alg-conv-trans-quot-left 🤷 ✋ 61 ms 101.2 MB
alg-conv-trans-quot-left-def 🤷 👍 59 ms 100.1 MB
alg-conv-trans-quot-right 👍 👍 59 ms 100.9 MB
subject-reduction-redex 👍 👍 84 ms 105.1 MB
subject-reduction-reduct 🤷 ✋ 64 ms 104.3 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: 248 ms · instructions: 351.8 M · max rss memory: 107.3 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/bogus1.ndjson: input kernel check rejected: [thm]: (kernel) declaration type mismatch, 'thm' has type
  True
but it is expected to have type
  @Eq Nat 0 1

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: 👍 accepted · exit code 0 · wall time: 1.7 m · instructions: 1.3 T · max rss memory: 1.2 GB

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: 62 ms · instructions: 353.2 M · max rss memory: 106.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/constlevels.ndjson: input kernel check rejected: [_test]: (kernel) let-declaration type mismatch 'x'

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: 👍 accepted · exit code 0 · wall time: 4.5 m · instructions: 3.0 T · max rss memory: 3.2 GB

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: 68 ms · instructions: 364.7 M · max rss memory: 107.4 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/ctor-num-fields.ndjson: input kernel check rejected: [_private.Test.0.h]: (kernel) declaration type mismatch, '_private.Test.0.h' has type
  @Eq _private.Test.0.S (_private.Test.0.S.mk Bool.true) (_private.Test.0.S.mk Bool.true)
but it is expected to have type
  @Eq _private.Test.0.S (_private.Test.0.S.mk Bool.true) (_private.Test.0.S.mk Bool.false)

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: 56 ms · instructions: 346.5 M · max rss memory: 104.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/extra-rec.ndjson: input kernel check rejected: [inconsistent]: (kernel) unknown constant 'rogue'

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: 👍 accepted · exit code 0 · wall time: 35.1 s · instructions: 436.4 G · max rss memory: 517.3 MB

Test "init-prelude"

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

The Init.Prelude module export.

Test result: 👍 accepted · exit code 0 · wall time: 448 ms · instructions: 5.0 G · max rss memory: 119.6 MB

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: 60 ms · instructions: 353.6 M · max rss memory: 106.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/k-rec-conv.ndjson: input kernel check rejected: [bad]: (kernel) declaration type mismatch, 'bad' has type
  @Eq T t1 t1
but it is expected to have type
  @Eq T t1 t2

Test "large-elim-param"

Expected: ✋ reject · Size: 3.1 KB · Lines: 48 · 📄 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: 57 ms · instructions: 347.5 M · max rss memory: 100.9 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/large-elim-param.ndjson: input kernel check rejected: [false_proof]: (kernel) incorrect number of universe levels parameters for 'MyBool.rec', #1 expected, #2 provided

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: 56 ms · instructions: 349.4 M · max rss memory: 104.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/level-imax-leq.ndjson: input kernel check rejected: [down]: (kernel) declaration type mismatch, 'down' has type
  Type (imax u v) → Type (imax u v)
but it is expected to have type
  Type (imax u v) → Sort (imax u v)

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: 55 ms · instructions: 349.5 M · max rss memory: 102.6 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/level-imax-normalization.ndjson: input kernel check rejected: [down]: (kernel) declaration type mismatch, 'down' has type
  Type (imax 0 v) → Type (imax 0 v)
but it is expected to have type
  Type (imax 0 v) → Sort (imax 0 v)

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: 58 ms · instructions: 346.0 M · max rss memory: 102.3 MB

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: 👍 accepted · exit code 0 · wall time: 17.0 m · instructions: 11.4 T · max rss memory: 7.9 GB

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: 60 ms · instructions: 349.6 M · max rss memory: 101.4 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/nat-rec-k-lie.ndjson: input kernel check rejected: [k1]: (kernel) declaration type mismatch, 'k1' has type
  Nat → True
but it is expected to have type
  (n : Nat) → g n

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: 61 ms · instructions: 361.1 M · max rss memory: 104.3 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/nat-rec-rules.ndjson: input kernel check rejected: [proof_of_false]: (kernel) application type mismatch
  @Nat.rec (fun n => @Bool.rec (fun x => Prop) False True (Nat.beq n 0)) True.intro fun n ih => True.intro
argument has type
  (n : Nat) → (@fun n => @Bool.rec (fun x => Prop) False True (Nat.beq n 0)) n → True
but function has type
  ((n : Nat) →
      (@fun n => @Bool.rec (fun x => Prop) False True (Nat.beq n 0)) n →
        (@fun n => @Bool.rec (fun x => Prop) False True (Nat.beq n 0)) (Nat.succ n)) →
    (t : Nat) → (@fun n => @Bool.rec (fun x => Prop) False True (Nat.beq n 0)) t

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: 70 ms · instructions: 444.2 M · max rss memory: 106.0 MB

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: 68 ms · instructions: 375.7 M · max rss memory: 106.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/nested-unused-param.ndjson: input kernel check rejected: [E, E.mk, E.rec_1, E.rec]: (kernel) invalid projection
  w.1

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: 👍 accepted · exit code 0 · wall time: 3.2 s · instructions: 29.7 G · max rss memory: 1.4 GB

Test "perf/args-before-unfold"

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

The declaration to check compares

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

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

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

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

Test result: 👍 accepted · exit code 0 · wall time: 67 ms · instructions: 420.2 M · max rss memory: 107.3 MB

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: 👍 accepted · exit code 0 · wall time: 1.0 s · instructions: 10.3 G · max rss memory: 532.0 MB

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: 👍 accepted · exit code 0 · wall time: 71 ms · instructions: 483.4 M · max rss memory: 108.7 MB

Test "perf/discarded-argument"

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

The declaration to check compares

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

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

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

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

Test result: 👍 accepted · exit code 0 · wall time: 248 ms · instructions: 4.2 G · max rss memory: 104.5 MB

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: 👍 accepted · exit code 0 · wall time: 2.8 s · instructions: 51.6 G · max rss memory: 106.0 MB

Test "perf/folded-constant-first"

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

The declaration to check compares

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

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

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

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

Test result: 👍 accepted · exit code 0 · wall time: 71 ms · instructions: 471.3 M · max rss memory: 111.4 MB

Test "perf/folded-constant-last"

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

The declaration to check compares

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

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

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

Test result: 👍 accepted · exit code 0 · wall time: 73 ms · instructions: 471.3 M · max rss memory: 108.5 MB

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: 👍 accepted · exit code 0 · wall time: 1.6 s · instructions: 17.9 G · max rss memory: 268.3 MB

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: 63 ms · instructions: 369.6 M · max rss memory: 104.4 MB

Test "perf/irrelevance-before-evaluation"

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

The declaration to check is

slowTriv (count #n) = True.intro

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

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

N=200 in the Lean source.

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

Test "perf/let-ladder"

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

The declaration to check has type Nat and value

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

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

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

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

N=2000 in the Lean source.

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

Test "perf/refute-cheap-first"

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

The declaration to check claims

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

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

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

Test result: ✋ rejected · exit code 1 · wall time: 67 ms · instructions: 432.9 M · max rss memory: 109.5 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/perf/refute-cheap-first.ndjson: input kernel check rejected: [kernel_refute_cheap_first]: (kernel) declaration type mismatch, 'kernel_refute_cheap_first' has type
  @Eq (@Prod Bool N)
    (@Prod.mk Bool N Bool.false
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯))))))))))))))))))))))))))))))))))))))))))))))))))
    (@Prod.mk Bool N Bool.false
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯))))))))))))))))))))))))))))))))))))))))))))))))))
but it is expected to have type
  @Eq (@Prod Bool N)
    (@Prod.mk Bool N Bool.false
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯))))))))))))))))))))))))))))))))))))))))))))))))))
    (@Prod.mk Bool N Bool.true
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯))))))))))))))))))))))))))))))))))))))))))))))))))

Test "perf/refute-cheap-last"

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

The declaration to check claims

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

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

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

Test result: ✋ rejected · exit code 1 · wall time: 258 ms · instructions: 4.3 G · max rss memory: 105.3 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/perf/refute-cheap-last.ndjson: input kernel check rejected: [kernel_refute_cheap_last]: (kernel) declaration type mismatch, 'kernel_refute_cheap_last' has type
  @Eq (@Prod N Bool)
    (@Prod.mk N Bool
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯)))))))))))))))))))))))))))))))))))))))))))))))))
      Bool.false)
    (@Prod.mk N Bool
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯)))))))))))))))))))))))))))))))))))))))))))))))))
      Bool.false)
but it is expected to have type
  @Eq (@Prod N Bool)
    (@Prod.mk N Bool
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯)))))))))))))))))))))))))))))))))))))))))))))))))
      Bool.false)
    (@Prod.mk N Bool
      (count
        (N.S
          (N.S
            (N.S
              (N.S
                (N.S
                  (N.S
                    (N.S
                      (N.S
                        (N.S
                          (N.S
                            (N.S
                              (N.S
                                (N.S
                                  (N.S
                                    (N.S
                                      (N.S
                                        (N.S
                                          (N.S
                                            (N.S
                                              (N.S
                                                (N.S
                                                  (N.S
                                                    (N.S
                                                      (N.S
                                                        (N.S
                                                          (N.S
                                                            (N.S
                                                              (N.S
                                                                (N.S
                                                                  (N.S
                                                                    (N.S
                                                                      (N.S
                                                                        (N.S
                                                                          (N.S
                                                                            (N.S
                                                                              (N.S
                                                                                (N.S
                                                                                  (N.S
                                                                                    (N.S
                                                                                      (N.S
                                                                                        (N.S
                                                                                          (N.S
                                                                                            (N.S
                                                                                              (N.S
                                                                                                (N.S
                                                                                                  (N.S
                                                                                                    (N.S
                                                                                                      (N.S
                                                                                                        ⋯)))))))))))))))))))))))))))))))))))))))))))))))))
      Bool.true)

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: 128 ms · instructions: 1.1 G · max rss memory: 109.0 MB

Test "perf/shared-subterm"

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

The declaration to check compares

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

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

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

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

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

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: 70 ms · instructions: 471.3 M · max rss memory: 102.6 MB

Test "perf/unroll-versus-evaluate"

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

The declaration to check compares

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

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

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

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

Test result: 👍 accepted · exit code 0 · wall time: 69 ms · instructions: 387.4 M · max rss memory: 108.9 MB

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: 62 ms · instructions: 348.6 M · max rss memory: 104.1 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/proj-non-structure.ndjson: input kernel check rejected: [bad]: (kernel) invalid projection
  (Bad.mk2 True.intro).1

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: 64 ms · instructions: 354.4 M · max rss memory: 103.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/proj-of-imax-prop.ndjson: input kernel check rejected: [imaxProjBool]: (kernel) invalid projection
  p.1

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: 62 ms · instructions: 348.5 M · max rss memory: 104.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/proj-of-prop.ndjson: input kernel check rejected: [badFalse]: (kernel) application type mismatch
  Wrapper.mk True.intro
argument has type
  True
but function has type
  False → Wrapper

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: 💥 error · exit code 3 · wall time: 99 ms · instructions: 712.3 M · max rss memory: 108.4 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/proj-of-stuck-prop.ndjson: internal error: the declaration does not land in a sort, even after unfolding its result type

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: 💥 error · exit code 3 · wall time: 97 ms · instructions: 683.2 M · max rss memory: 102.9 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/proj-of-subst-prop.ndjson: internal error: 2 generated statements differ from their exact exported owner interface; no output written
  ! model of PR14806Subst.Owner is missing PR14806Subst.Owner._model.proj_0
  ! model of PR14806Subst.Owner is missing PR14806Subst.Owner._model.eta

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: 68 ms · instructions: 347.0 M · max rss memory: 99.5 MB

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: 61 ms · instructions: 348.7 M · max rss memory: 100.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/rec-k-lie.ndjson: input kernel check rejected: [bad]: (kernel) declaration type mismatch, 'bad' has type
  True
but it is expected to have type
  disc MyBool.true

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: 💥 error · exit code 3 · wall time: 93 ms · instructions: 728.5 M · max rss memory: 101.8 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/rec-missing-ih.ndjson: internal error: a field of Native64TwoHashOwner mentions it other than as `∀ z⃗, Native64TwoHashOwner p⃗ e⃗` after full head normalisation (nested: Native64TwoHashOwner.step has a recursive occurrence that is not an application of Native64TwoHashOwner), so an occurrence of Native64TwoHashOwner survives reduction in a position the kernel's positivity check refuses and the input's numNested = 0 does not describe the declaration it is attached to; run with --type-check-input

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: 💥 error · exit code 3 · wall time: 93 ms · instructions: 706.5 M · max rss memory: 102.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/rec-of-subst-prop.ndjson: internal error: 2 generated statements differ from their exact exported owner interface; no output written
  ! model of Issue.Owner is missing Issue.Owner._model.proj_0
  ! model of Issue.Owner is missing Issue.Owner._model.eta

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: 62 ms · instructions: 346.0 M · max rss memory: 100.9 MB

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: 👍 accepted · exit code 0 · wall time: 1.1 m · instructions: 747.0 G · max rss memory: 861.8 MB

Test "tutorial/001_basicDef"

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

Basic definition

Test result: 👍 accepted · exit code 0 · wall time: 61 ms · instructions: 346.0 M · max rss memory: 102.8 MB

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: 65 ms · instructions: 346.2 M · max rss memory: 104.5 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/002_badDef.ndjson: input kernel check rejected: [badDef]: (kernel) declaration type mismatch, 'badDef' has type
  Type 1
but it is expected to have type
  Prop

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: 59 ms · instructions: 346.1 M · max rss memory: 100.4 MB

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: 57 ms · instructions: 346.1 M · max rss memory: 101.9 MB

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: 58 ms · instructions: 346.2 M · max rss memory: 100.9 MB

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: 57 ms · instructions: 346.5 M · max rss memory: 100.7 MB

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: 58 ms · instructions: 346.5 M · max rss memory: 100.0 MB

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: 57 ms · instructions: 346.5 M · max rss memory: 99.9 MB

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: 61 ms · instructions: 346.6 M · max rss memory: 103.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/009_forallSortBad.ndjson: input kernel check rejected: [forallSortBad]: (kernel) type expected
  x

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: 58 ms · instructions: 346.5 M · max rss memory: 101.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/010_nonTypeType.ndjson: input kernel check rejected: [nonTypeType]: (kernel) type expected
  constType

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: 62 ms · instructions: 346.5 M · max rss memory: 104.8 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/011_nonTypeAxiom.ndjson: input kernel check rejected: [nonTypeAxiom]: (kernel) type expected
  constType

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: 60 ms · instructions: 346.2 M · max rss memory: 100.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/012_nonPropThm.ndjson: input kernel check rejected: [nonPropThm]: (kernel) type of theorem 'nonPropThm' is not a proposition
  Prop

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: 61 ms · instructions: 346.1 M · max rss memory: 103.1 MB

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: 71 ms · instructions: 346.1 M · max rss memory: 103.0 MB

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: 60 ms · instructions: 346.1 M · max rss memory: 103.3 MB

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: 58 ms · instructions: 346.5 M · max rss memory: 100.9 MB

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: 58 ms · instructions: 346.1 M · max rss memory: 103.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/017_tut06_bad01.ndjson: input kernel check rejected: [tut06_bad01]: (kernel) failed to add declaration to environment, duplicate universe level parameter: 'u'

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: 57 ms · instructions: 346.1 M · max rss memory: 103.0 MB

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: 60 ms · instructions: 346.1 M · max rss memory: 103.4 MB

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: 58 ms · instructions: 346.2 M · max rss memory: 100.9 MB

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: 58 ms · instructions: 346.2 M · max rss memory: 103.1 MB

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: 57 ms · instructions: 346.1 M · max rss memory: 100.7 MB

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: 60 ms · instructions: 346.2 M · max rss memory: 102.7 MB

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: 60 ms · instructions: 346.1 M · max rss memory: 102.7 MB

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: 61 ms · instructions: 346.1 M · max rss memory: 100.9 MB

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: 59 ms · instructions: 346.2 M · max rss memory: 103.6 MB

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: 58 ms · instructions: 346.5 M · max rss memory: 103.2 MB

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: 57 ms · instructions: 347.9 M · max rss memory: 103.5 MB

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: 57 ms · instructions: 348.5 M · max rss memory: 102.7 MB

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: 58 ms · instructions: 349.0 M · max rss memory: 103.4 MB

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: 57 ms · instructions: 346.1 M · max rss memory: 100.4 MB

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: 57 ms · instructions: 346.5 M · max rss memory: 101.7 MB

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: 58 ms · instructions: 346.2 M · max rss memory: 100.8 MB

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: 61 ms · instructions: 356.1 M · max rss memory: 104.8 MB

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: 64 ms · instructions: 361.1 M · max rss memory: 101.6 MB

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: 63 ms · instructions: 376.1 M · max rss memory: 105.9 MB

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: 60 ms · instructions: 355.0 M · max rss memory: 104.9 MB

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: 64 ms · instructions: 370.9 M · max rss memory: 105.0 MB

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: 62 ms · instructions: 372.2 M · max rss memory: 105.4 MB

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: 58 ms · instructions: 347.0 M · max rss memory: 99.6 MB

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: 57 ms · instructions: 348.2 M · max rss memory: 102.6 MB

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: 61 ms · instructions: 366.9 M · max rss memory: 105.3 MB

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: 135 ms · instructions: 1.2 G · max rss memory: 110.9 MB

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: 58 ms · instructions: 346.8 M · max rss memory: 101.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/044_inductBadNonSort.ndjson: input kernel check rejected: [inductBadNonSort]: (kernel) type expected
  fun x y => x

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: 58 ms · instructions: 346.4 M · max rss memory: 104.9 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/045_inductBadNonSort2.ndjson: input kernel check rejected: [inductBadNonSort2]: (kernel) type expected
  aType

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: 56 ms · instructions: 346.2 M · max rss memory: 100.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/046_inductLevelParam.ndjson: input kernel check rejected: [inductLevelParam]: (kernel) failed to add declaration to environment, duplicate universe level parameter: 'u'

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: 59 ms · instructions: 346.1 M · max rss memory: 99.8 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/047_inductTooFewParams.ndjson: input kernel check rejected: [inductTooFewParams]: (kernel) invalid inductive datatype declaration, incorrect number of parameters

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: 60 ms · instructions: 346.5 M · max rss memory: 100.1 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/048_inductWrongCtorParams.ndjson: input kernel check rejected: [inductWrongCtorParams, inductWrongCtorParams.mk, inductWrongCtorParams.rec]: (kernel) arg #1 of 'inductWrongCtorParams.mk' does not match inductive datatypes parameters'

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: 62 ms · instructions: 346.5 M · max rss memory: 99.9 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/049_inductWrongCtorResParams.ndjson: input kernel check rejected: [inductWrongCtorResParams, inductWrongCtorResParams.mk, inductWrongCtorResParams.rec]: (kernel) invalid return type for 'inductWrongCtorResParams.mk'

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: 63 ms · instructions: 346.6 M · max rss memory: 102.4 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/050_inductWrongCtorResLevel.ndjson: input kernel check rejected: [inductWrongCtorResLevel, inductWrongCtorResLevel.mk, inductWrongCtorResLevel.rec]: (kernel) invalid return type for 'inductWrongCtorResLevel.mk'

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: 61 ms · instructions: 346.4 M · max rss memory: 100.3 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/051_inductInIndex.ndjson: input kernel check rejected: [inductInIndex, inductInIndex.mk, inductInIndex.rec]: (kernel) invalid return type for 'inductInIndex.mk'

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: 59 ms · instructions: 346.4 M · max rss memory: 102.9 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/052_indNeg.ndjson: input kernel check rejected: [indNeg, indNeg.mk, indNeg.rec]: (kernel) arg #1 of 'indNeg.mk' has a non positive occurrence of the datatypes being declared

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: 61 ms · instructions: 363.0 M · max rss memory: 105.4 MB

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: 57 ms · instructions: 346.6 M · max rss memory: 100.1 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/054_reduceCtorType.mk.ndjson: input kernel check rejected: [reduceCtorType, reduceCtorType.mk, reduceCtorType.rec]: (kernel) invalid return type for 'reduceCtorType.mk'

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: 57 ms · instructions: 346.8 M · max rss memory: 103.7 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/055_indNegReducible.ndjson: input kernel check rejected: [indNegReducible, indNegReducible.mk, indNegReducible.rec]: (kernel) arg #1 of 'indNegReducible.mk' has a non positive occurrence of the datatypes being declared

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: 58 ms · instructions: 349.8 M · max rss memory: 101.2 MB

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: 59 ms · instructions: 350.8 M · max rss memory: 104.3 MB

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: 61 ms · instructions: 351.0 M · max rss memory: 105.4 MB

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: 58 ms · instructions: 346.4 M · max rss memory: 104.6 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/059_typeWithTooHighTypeField.mk.ndjson: input kernel check rejected: [typeWithTooHighTypeField, typeWithTooHighTypeField.mk, typeWithTooHighTypeField.rec]: (kernel) universe level of type_of(arg #1) of 'typeWithTooHighTypeField.mk' is too big for the corresponding inductive datatype

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: 58 ms · instructions: 356.2 M · max rss memory: 101.8 MB

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: 61 ms · instructions: 361.4 M · max rss memory: 101.8 MB

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: 65 ms · instructions: 376.4 M · max rss memory: 105.7 MB

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: 63 ms · instructions: 355.1 M · max rss memory: 103.2 MB

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: 61 ms · instructions: 371.0 M · max rss memory: 104.2 MB

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: 62 ms · instructions: 372.4 M · max rss memory: 105.1 MB

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: 57 ms · instructions: 347.2 M · max rss memory: 103.4 MB

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: 57 ms · instructions: 348.3 M · max rss memory: 99.8 MB

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: 59 ms · instructions: 367.0 M · max rss memory: 101.7 MB

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: 130 ms · instructions: 1.2 G · max rss memory: 109.3 MB

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: 60 ms · instructions: 350.6 M · max rss memory: 104.2 MB

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: 60 ms · instructions: 346.8 M · max rss memory: 103.9 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/071_BogusRecursor.ndjson: input kernel check rejected: [bogusRecursorFalse]: (kernel) incorrect number of universe levels parameters for 'BogusRecursor.rec', #1 expected, #0 provided

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: 61 ms · instructions: 353.4 M · max rss memory: 102.1 MB

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: 64 ms · instructions: 370.4 M · max rss memory: 104.9 MB

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: 66 ms · instructions: 367.8 M · max rss memory: 104.9 MB

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: 62 ms · instructions: 368.8 M · max rss memory: 104.7 MB

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: 62 ms · instructions: 372.7 M · max rss memory: 104.0 MB

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: 61 ms · instructions: 375.0 M · max rss memory: 102.2 MB

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: 62 ms · instructions: 379.3 M · max rss memory: 104.4 MB

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: 64 ms · instructions: 399.3 M · max rss memory: 104.5 MB

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: 135 ms · instructions: 1.3 G · max rss memory: 108.7 MB

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: 60 ms · instructions: 355.6 M · max rss memory: 102.1 MB

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: 64 ms · instructions: 371.3 M · max rss memory: 102.0 MB

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: 63 ms · instructions: 372.6 M · max rss memory: 105.4 MB

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: 66 ms · instructions: 374.9 M · max rss memory: 106.1 MB

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: 63 ms · instructions: 347.9 M · max rss memory: 104.3 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/085_projOutOfRange.ndjson: input kernel check rejected: [projOutOfRange]: (kernel) invalid projection
  z.3

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: 60 ms · instructions: 347.6 M · max rss memory: 104.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/086_projNotStruct.ndjson: input kernel check rejected: [projNotStruct]: (kernel) invalid projection
  x.1

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: 59 ms · instructions: 356.4 M · max rss memory: 104.0 MB

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: 89 ms · instructions: 349.9 M · max rss memory: 104.4 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/088_projProp2.ndjson: input kernel check rejected: [projProp2]: (kernel) invalid projection
  x.2

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: 61 ms · instructions: 356.4 M · max rss memory: 103.8 MB

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: 59 ms · instructions: 349.9 M · max rss memory: 104.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/090_projProp4.ndjson: input kernel check rejected: [projProp4]: (kernel) invalid projection
  x.4

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: 59 ms · instructions: 350.1 M · max rss memory: 101.3 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/091_projProp5.ndjson: input kernel check rejected: [projProp5]: (kernel) invalid projection
  x.4

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: 58 ms · instructions: 349.9 M · max rss memory: 104.8 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/092_projProp6.ndjson: input kernel check rejected: [projProp6]: (kernel) invalid projection
  x.6

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: 61 ms · instructions: 375.9 M · max rss memory: 103.1 MB

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: 62 ms · instructions: 376.1 M · max rss memory: 106.0 MB

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: 63 ms · instructions: 376.1 M · max rss memory: 104.8 MB

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: 65 ms · instructions: 375.1 M · max rss memory: 101.9 MB

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: 61 ms · instructions: 349.1 M · max rss memory: 102.1 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/097_projIndexData.ndjson: input kernel check rejected: [projIndexData]: (kernel) invalid projection
  x.1

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: 59 ms · instructions: 349.1 M · max rss memory: 104.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/098_projIndexData2.ndjson: input kernel check rejected: [projIndexData2]: (kernel) invalid projection
  x.2

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: 62 ms · instructions: 382.4 M · max rss memory: 105.9 MB

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: 61 ms · instructions: 362.9 M · max rss memory: 104.6 MB

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: 59 ms · instructions: 353.8 M · max rss memory: 104.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/101_ruleKbad.ndjson: input kernel check rejected: [ruleKbad]: (kernel) declaration type mismatch, 'ruleKbad' has type
  @Eq Bool Bool.true Bool.false → (a : Bool) → @Eq Bool a a
but it is expected to have type
  (h : @Eq Bool Bool.true Bool.false) →
    (a : Bool) → @Eq Bool (@Eq.rec Bool Bool.true (fun x x_1 => Bool) a Bool.false h) a

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: 61 ms · instructions: 359.5 M · max rss memory: 101.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/102_ruleKAcc.ndjson: input kernel check rejected: [ruleKAcc]: (kernel) declaration type mismatch, 'ruleKAcc' has type
  (α : Sort u) → (p : α → α → Prop) → (x : α) → @Acc α p x → (a : Bool) → @Eq Bool a a
but it is expected to have type
  (α : Sort u) →
    (p : α → α → Prop) →
      (x : α) → (h : @Acc α p x) → (a : Bool) → @Eq Bool (@Acc.rec α p (fun x x_1 => Bool) (fun x x_1 x_2 => a) x h) a

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: 59 ms · instructions: 347.9 M · max rss memory: 103.2 MB

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: 58 ms · instructions: 350.1 M · max rss memory: 99.3 MB

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: 59 ms · instructions: 349.0 M · max rss memory: 103.5 MB

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: 60 ms · instructions: 350.2 M · max rss memory: 103.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/106_proofIrrelevanceBad.ndjson: input kernel check rejected: [proofIrrelevanceBad]: (kernel) declaration type mismatch, 'proofIrrelevanceBad' has type
  (p : Type) → (h1 : p) → p → @Eq p h1 h1
but it is expected to have type
  (p : Type) → (h1 h2 : p) → @Eq p h1 h2

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: 60 ms · instructions: 349.4 M · max rss memory: 99.7 MB

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: 60 ms · instructions: 349.9 M · max rss memory: 102.7 MB

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: 61 ms · instructions: 349.8 M · max rss memory: 102.8 MB

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: 59 ms · instructions: 349.8 M · max rss memory: 100.2 MB

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: 60 ms · instructions: 352.3 M · max rss memory: 104.8 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/111_indexedUnitEta.ndjson: input kernel check rejected: [indexedUnitEta]: (kernel) declaration type mismatch, 'indexedUnitEta' has type
  (x : IndexedUnit Bool.true) → IndexedUnit Bool.true → @Eq (IndexedUnit Bool.true) x x
but it is expected to have type
  (x y : IndexedUnit Bool.true) → @Eq (IndexedUnit Bool.true) x y

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: 63 ms · instructions: 382.9 M · max rss memory: 105.8 MB

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: 59 ms · instructions: 352.8 M · max rss memory: 102.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/113_indexedStructEta.ndjson: input kernel check rejected: [indexedStructEta]: (kernel) declaration type mismatch, 'indexedStructEta' has type
  (x : IndexedSingleton Bool.true) → @Eq (IndexedSingleton Bool.true) x x
but it is expected to have type
  (x : IndexedSingleton Bool.true) → @Eq (IndexedSingleton Bool.true) (IndexedSingleton.mk True.intro) x

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: 62 ms · instructions: 349.2 M · max rss memory: 102.0 MB

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: 58 ms · instructions: 349.3 M · max rss memory: 99.8 MB

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: 58 ms · instructions: 352.2 M · max rss memory: 101.1 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/116_funEtaBad.ndjson: input kernel check rejected: [funEtaBad]: (kernel) declaration type mismatch, 'funEtaBad' has type
  (x x_1 : Type) → (x → x) → (f : x → x_1) → @Eq (x → x_1) f f
but it is expected to have type
  (α β : Type) → (g : α → α) → (f : α → β) → @Eq (α → β) (fun x => f (g x)) f

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: 59 ms · instructions: 355.8 M · max rss memory: 100.9 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/117_etaRuleK.ndjson: input kernel check rejected: [etaRuleK]: (kernel) declaration type mismatch, 'etaRuleK' has type
  (a : @Eq Bool Bool.true Bool.true → Bool) → @Eq (@Eq Bool Bool.true Bool.true → Bool) a a
but it is expected to have type
  (a : @Eq Bool Bool.true Bool.true → Bool) →
    @Eq (@Eq Bool Bool.true Bool.true → Bool)
      (@Eq.rec Bool Bool.true (fun x x_1 => Bool) (a (@Eq.refl Bool Bool.true)) Bool.true) a

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: 59 ms · instructions: 353.4 M · max rss memory: 101.8 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/118_etaCtor.ndjson: input kernel check rejected: [etaCtor]: (kernel) declaration type mismatch, 'etaCtor' has type
  (x : True → T) → @Eq (True → T) x x
but it is expected to have type
  (x : True → T) → @Eq (True → T) (T.mk (T.val (x True.intro))) x

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: 58 ms · instructions: 347.6 M · max rss memory: 103.0 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/119_reflOccLeft.ndjson: input kernel check rejected: [reflOccLeft, reflOccLeft.mk, reflOccLeft.rec]: (kernel) arg #1 of 'reflOccLeft.mk' has a non positive occurrence of the datatypes being declared

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: 61 ms · instructions: 348.5 M · max rss memory: 103.4 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/120_reflOccInIndex.ndjson: input kernel check rejected: [reflOccInIndex, reflOccInIndex.mk, reflOccInIndex.rec]: (kernel) application type mismatch
  reflOccInIndex x
argument has type
  Nat
but function has type
  Type → Type

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: 135 ms · instructions: 1.1 G · max rss memory: 109.2 MB

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: 122 ms · instructions: 1.1 G · max rss memory: 106.8 MB

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: 121 ms · instructions: 1.1 G · max rss memory: 109.1 MB

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: 121 ms · instructions: 1.1 G · max rss memory: 108.4 MB

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: 65 ms · instructions: 401.7 M · max rss memory: 102.5 MB

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: 66 ms · instructions: 414.8 M · max rss memory: 102.8 MB

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: 59 ms · instructions: 359.4 M · max rss memory: 104.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/127_accRecNoEta.ndjson: input kernel check rejected: [accRecNoEta]: (kernel) declaration type mismatch, 'accRecNoEta' has type
  (α : Type) → (r : α → α → Prop) → (a : α) → @Acc α r a → (p : Bool) → @Eq Bool p p
but it is expected to have type
  {α : Type} →
    (r : α → α → Prop) →
      (a : α) → (h : @Acc α r a) → (p : Bool) → @Eq Bool (@Acc.rec α r (fun x x_1 => Bool) (fun x x_1 x_2 => p) a h) p

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: 60 ms · instructions: 349.8 M · max rss memory: 103.6 MB

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: 62 ms · instructions: 349.9 M · max rss memory: 102.2 MB

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: 61 ms · instructions: 349.9 M · max rss memory: 103.3 MB

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: 59 ms · instructions: 350.4 M · max rss memory: 101.6 MB

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: 59 ms · instructions: 350.9 M · max rss memory: 100.2 MB

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: 60 ms · instructions: 350.8 M · max rss memory: 103.3 MB

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: 27 ms · instructions: 164.1 M · max rss memory: 98.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/134_dup_defs.ndjson: invalid export: duplicate declaration dup_defs

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: 42 ms · instructions: 164.6 M · max rss memory: 100.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/135_dup_ind_def.ndjson: invalid export: duplicate declaration dup_ind_def

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: 38 ms · instructions: 164.6 M · max rss memory: 97.8 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/136_dup_ctor_def.ndjson: invalid export: duplicate declaration dup_ctor_def.mk

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: 38 ms · instructions: 164.6 M · max rss memory: 100.6 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/137_dup_rec_def.ndjson: invalid export: duplicate declaration dup_rec_def.rec

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: 76 ms · instructions: 346.8 M · max rss memory: 102.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/138_misnamed_rec_user.ndjson: input kernel check rejected: [misnamed_rec_user]: (kernel) unknown constant 'misnamed_rec.not_rec'

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: 66 ms · instructions: 346.7 M · max rss memory: 100.1 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/139_dup_rec_def2.ndjson: input kernel check rejected: [dup_rec_def2, dup_rec_def2.mk, dup_rec_def2.not_rec]: (kernel) constant has already been declared 'dup_rec_def2.rec'

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: 29 ms · instructions: 164.5 M · max rss memory: 97.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/140_dup_ctor_rec.ndjson: invalid export: duplicate declaration dup_ctor_rec.rec

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: 28 ms · instructions: 164.7 M · max rss memory: 97.5 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/tutorial/bad/141_DupConCon.ndjson: invalid export: duplicate declaration dup_ind_con_con.mk

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: 64 ms · instructions: 389.9 M · max rss memory: 107.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/undecidability/alg-conv-trans-acc.ndjson: input kernel check rejected: [trans]: (kernel) declaration type mismatch, 'trans' has type
  (a : @Acc Nat (fun x1 x2 => @LT.lt Nat instLTNat x1 x2) 1) → @Eq Bool (f 1 a) (f 1 a)
but it is expected to have type
  (a : @Acc Nat (fun x1 x2 => @LT.lt Nat instLTNat x1 x2) 1) →
    @Eq Bool (f 1 a) (f 0 (@Acc.inv Nat (fun x1 x2 => @LT.lt Nat instLTNat x1 x2) 1 0 a (Nat.lt_succ_self 0)))

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: 78 ms · instructions: 505.0 M · max rss memory: 105.0 MB

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: 91 ms · instructions: 505.8 M · max rss memory: 108.7 MB

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: 66 ms · instructions: 362.0 M · max rss memory: 103.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/undecidability/alg-conv-trans-quot.ndjson: input kernel check rejected: [trans]: (kernel) declaration type mismatch, 'trans' has type
  {P : Prop} →
    {r : P → P → Prop} →
      {α : Type} →
        (f : P → α) →
          (h : (x y : P) → r x y → @Eq α (f x) (f y)) →
            (q : @Quot P r) → P → @Eq α (@Quot.lift P r α f h q) (@Quot.lift P r α f h q)
but it is expected to have type
  {P : Prop} →
    {r : P → P → Prop} →
      {α : Type} →
        (f : P → α) →
          (h : (x y : P) → r x y → @Eq α (f x) (f y)) → (q : @Quot P r) → (z : P) → @Eq α (@Quot.lift P r α f h q) (f z)

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: 59 ms · instructions: 363.1 M · max rss memory: 101.2 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/undecidability/alg-conv-trans-quot-left.ndjson: input kernel check rejected: [left]: (kernel) declaration type mismatch, 'left' has type
  {P : Prop} →
    {r : P → P → Prop} →
      {α : Type} →
        (f : P → α) →
          (h : (x y : P) → r x y → @Eq α (f x) (f y)) →
            (q : @Quot P r) → P → @Eq α (@Quot.lift P r α f h q) (@Quot.lift P r α f h q)
but it is expected to have type
  {P : Prop} →
    {r : P → P → Prop} →
      {α : Type} →
        (f : P → α) →
          (h : (x y : P) → r x y → @Eq α (f x) (f y)) →
            (q : @Quot P r) → (z : P) → @Eq α (@Quot.lift P r α f h q) (@Quot.lift P r α f h (@Quot.mk P r z))

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: 58 ms · instructions: 352.3 M · max rss memory: 100.1 MB

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: 59 ms · instructions: 351.5 M · max rss memory: 100.9 MB

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: 75 ms · instructions: 504.9 M · max rss memory: 105.1 MB

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: 62 ms · instructions: 383.5 M · max rss memory: 104.3 MB

stderr:
/home/runner/work/lean-kernel-arena/lean-kernel-arena/_build/tests/undecidability/subject-reduction-reduct.ndjson: input kernel check rejected: [reduct]: (kernel) application type mismatch
  k x0
argument has type
  D (f 1 a)
but function has type
  D (f 0 (redex._proof_1 a)) → Unit