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>
46 lines
1.6 KiB
Text
46 lines
1.6 KiB
Text
import Lean.Server.Test.Cancel
|
|
import Lean.Elab.Tactic.Try
|
|
open Lean Lean.Meta Lean.Elab Lean.Elab.Term Lean.Elab.Tactic
|
|
open Lean.Server.Test.Cancel
|
|
|
|
/-!
|
|
Test cancellation propagation through plain `try?` (no `=>`, no
|
|
`wrapAsyncAsSnapshot` wrapping). Plain `try?` calls
|
|
`mkTryEvalSuggestStx`, which calls `expandUserTactic` for each
|
|
`[try_suggestion]` candidate. `expandUserTactic` runs the candidate via
|
|
`Tactic.run + evalTactic` on the *main* elaboration thread. Cancellation
|
|
must reach the candidate's body promptly via `Core.checkInterrupted`
|
|
embedded in `evalTactic` and inside the candidate.
|
|
|
|
We register a `[try_suggestion]` whose tactic is `wait_for_cancel_once_async`.
|
|
The first invocation (in the outer theorem body) spawns a snapshot task
|
|
that polls the cancel token; the second invocation (inside
|
|
`expandUserTactic`) waits on the first invocation's promise. On
|
|
re-elaboration the snapshot task observes its cancel token, resolves the
|
|
shared promise, and the inner `IO.wait` returns. After re-elaboration the
|
|
chain construction continues, the user attempt-all is built and run, and
|
|
the further nested invocations wait on the already-resolved promise. If
|
|
cancellation propagation is broken at any step, the test runner times out.
|
|
-/
|
|
|
|
namespace TestTryPlain
|
|
|
|
opaque UnsolvableProp : Prop
|
|
|
|
@[try_suggestion]
|
|
def waitSuggestion (_goal : MVarId) (_info : Try.Info) :
|
|
MetaM (Array (TSyntax `tactic)) := do
|
|
let stx ← `(tactic| wait_for_cancel_once_async)
|
|
return #[stx]
|
|
|
|
end TestTryPlain
|
|
|
|
example : True := by
|
|
trivial
|
|
--^ waitFor: blocked
|
|
--^ insert: "; skip"
|
|
--^ sync
|
|
|
|
theorem t : TestTryPlain.UnsolvableProp := by
|
|
wait_for_cancel_once_async
|
|
try?
|