aboutsummaryrefslogtreecommitdiff
path: root/plugins/ltac
AgeCommit message (Collapse)Author
2019-07-08[core] [api] Support OCaml 4.08Emilio Jesus Gallego Arias
The changes are large due to `Pervasives` deprecation: - the `Pervasives` module has been deprecated in favor of `Stdlib`, we have opted for introducing a few wrapping functions in `Util` and just unqualified the rest of occurrences. We avoid the shims as in the previous attempt. - a bug regarding partial application have been fixed. - some formatting functions have been deprecated, but previous versions don't include a replacement, thus the warning has been disabled. We may want to clean up things a bit more, in particular w.r.t. modules once we can move to OCaml 4.07 as the minimum required version. Note that there is a clash between 4.08.0 modules `Option` and `Int` and Coq's ones. It is not clear if we should resolve that clash or not, see PR #10469 for more discussion. On the good side, OCaml 4.08.0 does provide a few interesting functionalities, including nice new warnings useful for devs.
2019-07-07[error] Remove special error printing pre-processingEmilio Jesus Gallego Arias
We remove the special error printing pre-processing in favor of just calling the standard printers. Error printing has been a bit complex for a while due to an incomplete migration to a new printing scheme based on registering exception printers; this PR should alleviate that by completing the registration approach. After this cleanup, it should not be ever necessary for normal functions to worry a lot about catching errors and re-raising them, unless they have some very special needs. This change also allows to consolidate the `explainErr` and `himsg` modules into one, removing the need to export the error printing functions. Ideally we would make the contents of `himsg` more localized, but this can be done in a gradual way.
2019-07-01[decls] Remove goal_object_kind type.Emilio Jesus Gallego Arias
We can use logical kind for the same purpose, which is mainly dumpglob, so `goal_object_kind` was never matched against, making this transformation safe.
2019-07-01[declare] Separate kinds from entries in constant declarationEmilio Jesus Gallego Arias
They are clearly not at the same importance level, thus we use a named parameter and isolate the kinds as to allow further improvements and refactoring.
2019-07-01[api] Refactor most of `Decl_kinds`Emilio Jesus Gallego Arias
We move the bulk of `Decl_kinds` to a better place [namely `interp/decls`] and refactor the use of this information quite a bit. The information seems to be used almost only for `Dumpglob`, so it certainly should end there to achieve a cleaner core. Note the previous commits, as well as the annotations regarding the dubious use of the "variable" data managed by the `Decls` file. IMO this needs more work, but this should be a good start.
2019-06-26[declare] Fine tuning of Hook type.Emilio Jesus Gallego Arias
We turn the hook parameter into a record, making more explicit the capture of data in hooks as they only take one parameter now This is a fine-tuning but provides some small advantages, and allows us to tweak the hook type with less breakage.
2019-06-25Remove the internal_flag argument from Declare API.Pierre-Marie Pédrot
It was never used actually.
2019-06-24[api] Remove `polymorphic` type alias, use labels instead.Emilio Jesus Gallego Arias
This is more in-line with attributes and the rest of the API, and makes some code significantly clearer (as in `foo true false false`, etc...)
2019-06-24[lemmas] [proof] Split proof kinds into per-layer components.Emilio Jesus Gallego Arias
We split `{goal,declaration,assumption}_kind` into their components. This makes sense as each part of this triple is handled by a different layer, namely: - `polymorphic` status: necessary for the lower engine layers; - `locality`: only used in `vernac` top-level constants - `kind`: merely used for cosmetic purposes [could indeed be removed / pushed upwards] We also profit from this refactoring to add some named parameters to the top-level definition API which is quite parameter-hungry. More refactoring is possible and will come in further commits, in particular this is a step towards unifying the definition / lemma save path.
2019-06-24[proof] Remove duplicated universe polymorphic from decl_kindsEmilio Jesus Gallego Arias
This information is already present on `Proof.t`, so we extract it form there. Moreover, this information is essential to the lower-level proof, as opposed to the "kind" information which is only relevant to the vernac layer; we will move it thus to its proper layer in subsequent commits.
2019-06-24[lemmas] Turn Lemmas.info into a proper type with constructor.Emilio Jesus Gallego Arias
Lemmas.info was a bit out of hand, as well as the parameters to the `start_*` family. Most of the info is not needed and should hopefully remain constrained to special cases, most callers only set the hook, and obligations should be better served by a `start_obligation` function soon.
2019-06-24Duplicate the type of constant entries in Proof_global.Pierre-Marie Pédrot
This allows to desynchronize the kernel-facing API from the proof-facing one.
2019-06-20Merge PR #9645: [proof] Remove terminator type, unifying regular and ↵Pierre-Marie Pédrot
obligation ones. Ack-by: ejgallego Ack-by: gares Reviewed-by: ppedrot
2019-06-19Merge PR #10239: Deprecate grammar entry "intropattern" in tactic notations ↵Théo Zimmermann
in favor of "simple_intropattern" Reviewed-by: Zimmi48 Reviewed-by: ppedrot
2019-06-17Update ml-style headers to new year.Théo Zimmermann
2019-06-17[proof] Move declaration hooks to DeclareDef.Emilio Jesus Gallego Arias
This way both `Lemmas` and `DeclareObl` can depend on it, removing one more difficulty on the unification of terminators.
2019-06-16Deprecate "intro_pattern" in tactic notations in favor of "simple_intropattern".Hugo Herbelin
This is to prevent confusion with the terminology used in the grammar of tactic in the reference manual: "intropattern" in Tactic Notation and TACTIC EXTEND is actually bound to simple_intropattern and not to what is called intropattern in the reference manual After some deprecation phase, "intropattern" could be added back to mean the "intropattern" of the reference manual. Note that "simple_intropattern" is actually already available in "Tactic Notation" with the correct meaning as an entry. Only "intropattern" is misguiding.
2019-06-13Merge PR #10319: [STM] Only VtSideeff can be VtNow/VtLaterEnrico Tassi
Ack-by: ejgallego Reviewed-by: gares
2019-06-12Merge PR #10180: `deprecated` attribute support for notations and syntactic ↵Théo Zimmermann
definitions Ack-by: SkySkimmer Reviewed-by: Zimmi48 Ack-by: ggonthier Reviewed-by: herbelin
2019-06-11STM: encode in static types that vernac_when is only used when VtSideffGaëtan Gilbert
The stm.ml changes show that for the other classifications either the vernac_when was ignored, or there was an assert on it forcing it to be Now or Later depending on the vernac_type. One may also note that the classification used in top_printers `VtQuery,VtNow` would have failed those asserts...
2019-06-09[proof] Uniformize Proof_global APIEmilio Jesus Gallego Arias
We rename modify to map [more in line with the rest of the system] and make the endline function specific, as it is only used in one case.
2019-06-09[proof] Move proofs that have an associated constant to `Lemmas`Emilio Jesus Gallego Arias
The main idea of this PR is to distinguish the types of "proof object" `Proof_global.t` and the type of "proof object associated to a constant, the new `Lemmas.t`. This way, we can move the terminator setup to the higher layer in `vernac`, which is the one that really knows about constants, paving the way for further simplification and in particular for a unified handling of constant saving by removal of the control inversion here. Terminators are now internal to `Lemmas`, as it is the only part of the code applying them. As a consequence, proof nesting is now handled by `Lemmas`, and `Proof_global.t` is just a single `Proof.t` plus some environmental meta-data. We are also enable considerable simplification in a future PR, as this patch makes `Proof.t` and `Proof_global.t` essentially the same, so we should expect to handle them under a unified interface.
2019-06-08Cleaning the status of Local Definition and similar.Hugo Herbelin
Formerly, knowing if a declaration was to be discharged, to be global but invisible at import, or to be global but visible at import was obtained by combining the parser-level information (i.e. use of Variable/Hypothesis/Let vs use of Axiom/Parameter/Definition/..., use of Local vs Global) with the result of testing whether there were open sections. We change the meaning of the Discharge flag: it does not tell anymore that it was syntactically a Variable/Hypothesis/Let, but tells the expected semantics of the declaration (issuing a warning in the parser-to-interpreter step if the semantics is not the one suggested by the syntax). In particular, the interpretation/command engine becomes independent of the parser. The new "semantic" type is: type import_status = ImportDefaultBehavior | ImportNeedQualified type locality = Discharge | Global of import_status In the process, we found a couple of inconsistencies in the treatment of the locality status. See bug #8722 and test file LocalDefinition.v.
2019-06-07Merge PR #10205: Make discriminate tactic compatible with HoTTPierre-Marie Pédrot
Reviewed-by: Zimmi48 Reviewed-by: mattam82 Reviewed-by: ppedrot
2019-06-06Make discriminate tactic compatible with HoTTAndreas Lynge
2019-06-06`deprecated` attribute support for notations and syntactic definitionsMaxime Dénès
We also slightly change the semantics of the `compat` syntax modifier to re-express it in terms of the `deprecated` attribute, and we deprecate it in favor of the latter.
2019-06-04[rewrite] remove program_mode from attributes (unused)Enrico Tassi
2019-06-04[classes] remove program mode from the new_instance_* APIsEnrico Tassi
2019-06-04[vernac] more precise types for Add Morph, Instance, and FunctionEnrico Tassi
2019-06-04[rewrite] Add Morphism syntax made different for module type parametersEnrico Tassi
2019-06-04Rename Proof_global.{pstate -> t}Gaëtan Gilbert
2019-06-04Alternate syntax for ![]: VERNAC EXTEND Foo STATE proofGaëtan Gilbert
eg ![proof] becomes STATE proof This commits still supports the old ![] so there is redundancy: ~~~ VERNAC EXTEND Foo STATE proof | ... VERNAC EXTEND Foo | ![proof] ... ~~~ with the ![] form being local to the rule and the STATE form applying to the whole EXTEND except for the rules with a ![].
2019-06-04coqpp: add new ![] specifiers for structured proof interactionGaëtan Gilbert
![proof_stack] is equivalent to the old meaning of ![proof]: the body has type `pstate:Proof_global.t option -> Proof_global.t option` The other specifiers are for the following body types: ~~~ ![open_proof] `is_ontop:bool -> pstate` ![maybe_open_proof] `is_ontop:bool -> pstate option` ![proof] `pstate:pstate -> pstate` ![proof_opt_query] `pstate:pstate option -> unit` ![proof_query] `pstate:pstate -> unit` ~~~ The `is_ontop` is only used for the warning message when declaring a section variable inside a proof, we could also just stop warning. The specifiers look closely related to stm classifiers, but currently they're unconnected. Notably this means that a ![proof_query] doesn't have to be classified QUERY. ![proof_stack] is only used by g_rewrite/rewrite whose behaviour I don't fully understand, maybe we can drop it in the future. For compat we may want to consider keeping ![proof] with its old meaning and using some new name for the new meaning. OTOH fixing plugins to be stricter is easier if we change it as the errors tell us where it's used.
2019-06-04Proof_global: pass only 1 pstate when we don't want the proof stackGaëtan Gilbert
Typically instead of [start_proof : ontop:Proof_global.t option -> bla -> Proof_global.t] we have [start_proof : bla -> Proof_global.pstate] and the pstate is pushed on the stack by a caller around the vernacentries/mlg level. Naming can be a bit awkward, hopefully it can be improved (maybe in a followup PR). We can see some patterns appear waiting for nicer combinators, eg in mlg we often only want to work with the current proof, not the stack. Behaviour should be similar modulo bugs, let's see what CI says.
2019-06-04rewrite.ml: remove outdated commentGaëtan Gilbert
2019-06-04rewrite.ml: drop the id returned by new_instance earlierGaëtan Gilbert
We never use this id in rewrite.ml so don't bother threading it around.
2019-05-27Merge PR #10237: Fix some incorrect uses of proof-local environmentPierre-Marie Pédrot
Reviewed-by: gares Reviewed-by: ppedrot
2019-05-25Documenting syntax "injection ... as [= pat1 ... patn ]".Hugo Herbelin
To prevent confusion, forbidding a mix of the "injection term as pat1 ... patn" and of the "injection term as [= pat1 ... patn]" syntax: If a "[= ...]" occurs, this should be a singleton list of patterns.
2019-05-24Stop using pstate in global print queriesGaëtan Gilbert
Using pstate makes no sense for printing global stuff
2019-05-23Merge PR #10221: Fixing typos - Part 2 (reopening of #10218)Théo Zimmermann
2019-05-23Fixing typos - Part 2JPR
2019-05-21Remove undocumented Instance : ! syntaxGaëtan Gilbert
It's used a few times in the stdlib (a couple of which need no other change when removing the !) and not at all throughout our CI. Considering that I think it's fair enough to remove it.
2019-05-20Remove VtUnknown classificationMaxime Dénès
This clean-up removes the dependency of the current proof mode (and hence the parsing state) on unification. The current proof mode can now be known simply by parsing and elaborating attributes. We give access to attributes from the classifier for this purpose. We remove the infamous `VtUnknown` code path in the STM which is known to be buggy. Fixes #3632 #3890 #4638.
2019-05-20Remove Refine Instance Mode optionMaxime Dénès
2019-05-10Split the hypothesis conversion check in a conversion + ordering check.Pierre-Marie Pédrot
2019-05-10Make the check flag of conversion functions mandatory.Pierre-Marie Pédrot
The current situation is a mess, some functions set it by default, but other no. Making it mandatory ensures that the expected value is the correct one.
2019-04-30Deprecating convert_concl_no_check.Hugo Herbelin
2019-04-29Exposing a change_no_check tactic.Hugo Herbelin
2019-04-23Deprecate the *_no_check variants of conversion tactics.Pierre-Marie Pédrot
2019-04-10Remove calls to global env in InductiveopsMaxime Dénès