Commit graph

7 commits

Author SHA1 Message Date
Leonardo de Moura
ff37e5d512
feat: add grind core module (#4249) 2024-05-22 03:50:36 +00:00
Leonardo de Moura
d6709eb157 feat: add [grind_cases] attribute 2024-05-21 21:46:23 +02:00
Leonardo de Moura
e6be8b90f5
feat: add grind.injection (#4243) 2024-05-21 17:57:02 +00:00
Leonardo de Moura
7c053259d3
feat: add grind.cases tactic (#4235) 2024-05-21 02:03:33 +00:00
Leonardo de Moura
f53b778c0d
feat: improve grind preprocessor (#4221) 2024-05-20 04:29:49 +00:00
Kim Morrison
3a457e6ad6
chore: use #guard_msgs in run tests (#4175)
Many of our tests in `tests/lean/run/` produce output from `#eval` (or
`#check`) statements, that is then ignored.

This PR tries to capture all the useful output using `#guard_msgs`. I've
only done a cursory check that the output is still sane --- there is a
chance that some "unchecked" tests have already accumulated regressions
and this just cements them!

In the other direction, I did identify two rotten tests:
* a minor one in `setStructInstNotation.lean`, where a comment says `Set
Nat`, but `#check` actually prints `?_`. Weird?
* `CompilerProbe.lean` is generating empty output, apparently indicating
that something is broken, but I don't know the signficance of this file.

In any case, I'll ask about these elsewhere.

(This started by noticing that a recent `grind` test file had an
untested `trace_state`, and then got carried away.)
2024-05-16 00:38:31 +00:00
Leonardo de Moura
3035d2f8f6
feat: grind preprocessor skeleton (#4170) 2024-05-15 04:25:22 +00:00