Commit graph

5 commits

Author SHA1 Message Date
Joachim Breitner
7d60d8b563
feat: safer #eval, and #eval! (#4810)
previously, `#eval` would happily evaluate expressions that contain
`sorry`, either explicitly or because of failing tactics. In conjunction
with operations like array access this can lead to the lean process
crashing, which isn't particularly great.

So how `#eval` will refuse to run code that (transitively) depends on
the `sorry` axiom (using the same code as `#print axioms`).

If the user really wants to run it, they can use `#eval!`.

Closes #1697
2024-07-23 15:26:56 +00:00
Leonardo de Moura
40c8db7494 feat: improve argument type mismatch error position, and do not stop at application type mismatch errors 2022-04-25 16:30:40 -07:00
Gabriel Ebner
ab276a5ae3 chore: show declaration with sorry in #eval 2022-01-17 13:18:22 -08:00
Leonardo de Moura
5d3f0606d2 feat: include type of type in "mismatch errors"
@Kha we do that in Lean 3. It helps when the error is due to incorrect universe levels.

BTW, I had to update `tests/lean/server/content_diag.json` since the
error message is different, but a few other stuff changed too.
Could you please take a look whether the test is still correct?
2021-03-08 09:30:34 -08:00
Leonardo de Moura
31680c1255 fix: do not evaluate code containing sorry
closes #277
2021-01-26 15:01:53 -08:00