2229b077d6
This PR makes an empty `by` block run `try?` in the background and surface its suggestions, while still producing the usual unsolved-goals diagnostic. The implicit `try?` is informational only — it does not change elaboration behavior beyond emitting messages. Behaviour is controlled by a new option `tactic.tryOnEmptyBy`, disabled by default for now; set it to `true` to opt in. The default may flip in a future release. Behaviour summary, when the option is enabled: * The empty `by` reports unsolved goals immediately, before the (possibly slow) `try?` has finished. * The `try?` work is spawned as an asynchronous snapshot task (`Term.wrapAsyncAsSnapshot` + `Core.logSnapshotTask`), so subsequent elaboration is not blocked and the suggestions arrive when ready. * `try?` is gated on its parser infrastructure being available, so working on the prelude (before `Init.Try` is imported) keeps the regular empty-`by` behaviour. * No effect when the empty `by` appears inside a backtracking combinator (e.g. `first | exact (by) | …`) or when `try?` finds no applicable suggestion. Implementation notes: * `elabEmptyByAsTry` (in `Lean.Elab.Tactic.Try`) is registered as a second `@[builtin_term_elab byTactic]`, alongside the existing `elabByTactic` in `Lean.Elab.BuiltinTerm`. The gate `shouldElabEmptyByAsTry` is checked in both elaborators so the empty-`by` path takes the `try?` route while non-empty `by` follows the regular path. The body shared between them is factored as `elabByTacticCore`. The two-elaborator setup avoids a circular module dependency between `BuiltinTerm.lean` and `Tactic/Try.lean`; an inline comment in `Try.lean` explains this. * A latent bug from #13229 is fixed along the way: `evalSepTactics` returned at the very top for an empty tactic sequence without resolving the `tacSnap` promise that `MutualDef.mkTacTask` sets up for `:= by …` bodies. The dangling promise was harmless in typical use because the cmd's cancellation token would fire shortly after elaboration and drop it, but with a slow async snapshot task in the same command (as the implicit `try?` here) the language-server info-tree walk would block on it and the editor's Messages view would only update once the task finished. Resolved at the early-return in `evalSepTactics`. * The test infrastructure in `Lean.Server.Test.Cancel` gains a label-keyed `testTasksRef` registry plus `mkTestTask` / `wait_for_test_task`. The pre-existing `block_until_cancelled` is reimplemented on top of `mkTestTask` and the redundant `blockUntilCancelledOnce` ref is removed. Tests: * `tests/elab/tryOnEmptyBy.lean`, `tests/elab/try_prelude.lean` — feature behaviour and prelude gating. * `tests/server_interactive/cancellation_empty_by.lean` — verifies that on document re-elaboration `cancelRec` reaches the empty-`by` snapshot's cancel token registered with `Core.logSnapshotTask`. A `[try_suggestion]` generator wires the outer cancel token's `onSet` to resolve a `mkTestTask "T_outer"` promise, and the candidate `wait_for_test_task "T_outer"` waits on it. If `cancelTk? := none` is passed to `Core.logSnapshotTask`, `cancelRec` cannot reach the token, the wait blocks, and the runner times out. If `cancelTk? := none` is also passed to `wrapAsyncAsSnapshot`, no `onSet` resolver is registered, the promise drops without resolution, and `wait_for_test_task` surfaces a `"task dropped"` diagnostic on stderr. * `tests/server_interactive/cancellation_try_plain.lean` — verifies cancellation of plain `try?` (no `=>`) when its `[try_suggestion]` candidate runs synchronously inside `expandUserTactic`, by chaining through `wait_for_cancel_once_async`'s shared promise. Breaking `SnapshotTask.cancelRec` to skip walking children causes a runner timeout. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
68 lines
1.6 KiB
Text
68 lines
1.6 KiB
Text
/-
|
|
Tests for `tactic.tryOnEmptyBy`: empty `by` blocks run `try?` and suggest proofs.
|
|
-/
|
|
|
|
set_option tactic.tryOnEmptyBy true
|
|
|
|
-- Basic: empty by reports unsolved goals first (so the user sees it immediately
|
|
-- even when `try?` is slow), then `try?` emits its suggestions as a single info
|
|
-- message with the option-disabling hint at the end.
|
|
/--
|
|
error: unsolved goals
|
|
⊢ True
|
|
---
|
|
info: Try these:
|
|
[apply] by solve_by_elim
|
|
[apply] by simp
|
|
[apply] by simp only
|
|
[apply] by grind
|
|
[apply] by grind only
|
|
[apply] by simp_all
|
|
|
|
(Disable this with `set_option tactic.tryOnEmptyBy false`.)
|
|
-/
|
|
#guard_msgs in
|
|
example : True := by
|
|
|
|
-- Disabled: empty by gives unsolved goals
|
|
/--
|
|
error: unsolved goals
|
|
⊢ True
|
|
-/
|
|
#guard_msgs in
|
|
set_option tactic.tryOnEmptyBy false in
|
|
example : True := by
|
|
|
|
-- Non-empty by is not affected
|
|
example : True := by
|
|
trivial
|
|
|
|
-- by { } (braces) is not affected
|
|
example : True := by { trivial }
|
|
|
|
-- by { } (empty braces) does not trigger try?
|
|
/--
|
|
error: unsolved goals
|
|
⊢ True
|
|
-/
|
|
#guard_msgs in
|
|
example : True := by { }
|
|
|
|
-- Unprovable goal: try? finds no suggestions, so the implicit mode is fully silent
|
|
-- (no "Try this", no error or warning from try? itself — only the unsolved-goals error).
|
|
/--
|
|
error: unsolved goals
|
|
⊢ False
|
|
-/
|
|
#guard_msgs in
|
|
example : False := by
|
|
|
|
-- Nested in a backtracking combinator (`errToSorry = false`): try? must stay silent.
|
|
-- We only assert the absence of the try? info message; the unsolved-goals error is expected
|
|
-- because `exact (by)` succeeds at term-elab time (the empty tactic block fails later).
|
|
/--
|
|
error: unsolved goals
|
|
⊢ True
|
|
-/
|
|
#guard_msgs in
|
|
example : True := by first | exact (by) | trivial
|