84e46162b5
This is the groundwork for a tactic index in generated documentation, as there was in Lean 3. There are a few challenges to getting this to work well in Lean 4: * There's no natural notion of *tactic identity* - a tactic may be specified by multiple syntax rules (e.g. the pattern-matching version of `intro` is specified apart from the default version, but both are the same from a user perspective) * There's no natural notion of *tactic name* - here, we take the pragmatic choice of using the first keyword atom in the tactic's syntax specification, but this may need to be overridable someday. * Tactics are extensible, but we don't want to allow arbitrary imports to clobber existing tactic docstrings, which could become unpredictable in practice. For tactic identity, this PR introduces the notion of a *tactic alternative*, which is a `syntax` specification that is really "the same as" an existing tactic, but needs to be separate for technical reasons. This provides a notion of tactic identity, which we can use as the basis of a tactic index in generated documentation. Alternative forms of tactics are specified using a new `@[tactic_alt IDENT]` attribute, applied to the new tactic syntax. It is an error to declare a tactic syntax rule to be an alternative of another one that is itself an alternative. Documentation hovers now take alternatives into account, and display the docs for the canonical name. *Tactic tags*, created with the `register_tactic_tag` command, specify tags that may be applied to tactics. This is intended to be used by doc-gen and Verso. Tags may be applied using the `@[tactic_tag TAG1 TAG2 ...]` attribute on a canonical tactic parser, which may be used in any module to facilitate downstream projects introducing tags that apply to pre-existing tactics. Tags may not be removed, but it's fine to redundantly add them. The collection of tags, and the tactics to which they're applied, can be seen using the `#print tactic tags` command. *Extension documentation* provides a structured way to document extensions to tactics. The resulting documentation is gathered into a bulleted list at the bottom of the tactic's docstring. Extensions are added using the `tactic_extension TAC` command. This can be used when adding new interpretations of a tactic via `macro_rules`, when extending some table or search index used by the tactic, or in any other way. It is a command to facilitate its flexible use with various extension mechanisms.
61 lines
1.3 KiB
Text
61 lines
1.3 KiB
Text
|
|
|
|
|
|
/-!
|
|
Tests that docstring hovers are computed correctly for tactic extensions
|
|
-/
|
|
|
|
/-- Another `trivial` tactic -/
|
|
syntax (name := my_trivial) "my_trivial" : tactic
|
|
|
|
@[tactic_alt my_trivial]
|
|
syntax (name := very_trivial) "very_trivial" : tactic
|
|
macro_rules
|
|
| `(tactic|very_trivial) => `(tactic|my_trivial)
|
|
|
|
/-- It tries Lean's `trivial` -/
|
|
tactic_extension my_trivial
|
|
--^ textDocument/hover
|
|
macro_rules
|
|
| `(tactic|my_trivial) => `(tactic|trivial)
|
|
--^ textDocument/hover
|
|
|
|
/-- It tries `simp_all` -/
|
|
tactic_extension my_trivial
|
|
macro_rules
|
|
| `(tactic|my_trivial) => `(tactic|simp_all; done)
|
|
|
|
|
|
example : True := by
|
|
my_trivial
|
|
--^ textDocument/hover
|
|
|
|
/-- It tries `constructor` -/
|
|
tactic_extension my_trivial
|
|
--^ textDocument/hover
|
|
-- On the preceding line, it was not yet extended.
|
|
-- Here, it is:
|
|
macro_rules
|
|
| `(tactic|my_trivial) => `(tactic|constructor; done)
|
|
--^ textDocument/hover
|
|
|
|
/--
|
|
It tries some useful things:
|
|
* `omega`
|
|
* `simp_arith [*]`
|
|
-/
|
|
tactic_extension my_trivial
|
|
macro_rules
|
|
| `(tactic|my_trivial) => `(tactic|omega)
|
|
macro_rules
|
|
| `(tactic|my_trivial) => `(tactic|simp_arith [*]; done)
|
|
|
|
-- This tests that nested lists work
|
|
example : True := by
|
|
my_trivial
|
|
--^ textDocument/hover
|
|
|
|
-- This tests that alts are resolved
|
|
example : True := by
|
|
very_trivial
|
|
--^ textDocument/hover
|