A very simple try? tactic implementation.
Instances For
evalSuggest is a evalTactic variant that returns suggestions after executing a tactic built using
combinators such as first, attempt_all, <;>, ;, and try.
Executes tac in the saved state. This function is used to validate a tactic before suggesting it.
Instances For
- root : TSyntax `tactic
- terminal : Bool
- config : Try.Config
- originalMaxHeartbeats : Nat
Instances For
Instances For
User-extensible try suggestion generators
A user-defined generator that proposes tactics for try? to attempt.
Takes the goal MVarId and collected info, returns array of tactics to try.
Instances For
Entry in the try suggestion registry
Instances For
Environment extension for user try suggestion generators (supports local scoping)
Elaborate register_try?_tactic command
Instances For
Instances For
Instances For
Executes a tactic with heartbeat management:
- Restores the original maxHeartbeats limit (recorded at try? start)
- Gives the tactic a fresh heartbeat budget via withCurrHeartbeats
- Catches heartbeat exceptions and converts them to regular errors
Instances For
Executes code with unlimited heartbeats (maxHeartbeats set to 0). Used by try? infrastructure itself so it doesn't timeout while testing tactics.
Instances For
@[builtin_try_tactic] registrations for the built-in combinators and trace wrappers.
evalSuggest dispatcher.
evalAndSuggest frontend
Instances For
Helper functions
grind tactic syntax generator based on collected information.
Other generators
Function induction generators
Vanilla induction generators
Main code
When the by body is empty and tactic.tryOnEmptyBy is set, run try? for its
informational side effect (the "Try this" suggestions) and then delegate to the normal
by elaborator so the empty body still produces an unsolved-goals error. The implicit
mode must not change elaboration behavior beyond emitting messages.
Disabled when errToSorry is false (nested in a combinator like first),
or when try? infrastructure is not yet available (e.g. while building the prelude).
We register a second builtin_term_elab for byTactic (rather than folding the
gate-and-dispatch into elabByTactic directly) because Lean.Elab.Tactic.Try already
imports Lean.Elab.BuiltinTerm, so the try? infrastructure can't be referenced
from BuiltinTerm.lean without breaking the dependency direction. The gate in
elabByTactic skips this elaborator (via throwUnsupportedSyntax) when the try?
path doesn't apply. This could be cleaned up later, e.g. via a registered handler ref
in BuiltinTerm.lean populated by Try.lean.