31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
Debugging
|
|
=========
|
|
|
|
Some notes on how to debug Lean, which may also be applicable to debugging Lean programs in general.
|
|
|
|
## Tracing
|
|
|
|
In `CoreM` and derived monads, we use `trace![traceCls] "msg with {interpolations}"` to fill the structured trace viewable with `set_option trace.traceCls true`.
|
|
New trace classes have to be registered using `registerTraceClass` first.
|
|
|
|
Notable trace classes:
|
|
* `Elab.command`/`Elab.step`: command/term macro expansion/elaboration steps
|
|
|
|
Useful options modifying these traces for debugging syntax trees:
|
|
```
|
|
set_option pp.raw true
|
|
set_option pp.raw.maxDepth 10
|
|
```
|
|
* `Meta.synthInstance`: typeclass resolution
|
|
* `Meta.isDefEq`: unification
|
|
* `interpreter`: full execution trace of the interpreter. Only available in debug builds.
|
|
|
|
In pure contexts or when execution is aborted before the messages are finally printed, one can instead use the term `dbg_trace "msg with {interpolations}"; val` (`;` can also be replaced by a newline), which will print the message directly to stderr before evaluating `val`. `dbgTraceVal val` can be used as a shorthand for `dbg_trace "{val}"; val`.
|
|
Note that if the return value is not actually used, the trace code is silently dropped as well.
|
|
|
|
## Debuggers
|
|
|
|
`gdb`/`lldb` can be used to inspect stack traces of compiled Lean code, though they cannot print values of Lean variables and terms in any legible way yet.
|
|
For example, `b lean_panic_fn` can be used to look at the stack trace of a panic.
|
|
|
|
The [`rr` reverse debugger](https://github.com/rr-debugger/rr) is an amazing tool for investigating e.g. segfaults from reference counting errors, though better hope you will never need it...
|