aboutsummaryrefslogtreecommitdiff
path: root/test-suite/bugs
AgeCommit message (Collapse)Author
2016-07-01Fixing #4882 (anomaly with Declare Implicit Tactic on hole of type with evars).Hugo Herbelin
But there are still bugs with Declare Implicit Tactic, which should probably rather be reimplemented with ltac:(tac). Indeed, it does support evars in the type of the term, and solve_by_implicit_tactic should transfer universe constraints to the main goal. E.g., the following still fails, at Qed time. Definition Foo {T}{a : T} : T := a. Declare Implicit Tactic eassumption. Goal forall A (x : A), A. intros. apply Foo. Qed.
2016-06-30Goal selectors now use the keyword [only].Cyprien Mangin
This fixes some parsing problems when doing things like [let n := 2 in idtac n]. See bug #4877.
2016-06-29Fixing #4865 (deciding on which arguments to recompute scopes was not robust).Hugo Herbelin
See 4865.v for details.
2016-06-29Univs: Fix bug #4726Matthieu Sozeau
When using Record and an explicit sort constraint, the universe was wrongly made flexible and minimized.
2016-06-29Fix issues in test-suite revealed by warnings.Maxime Dénès
2016-06-27Univs: allowing notations to take univ instancesMatthieu Sozeau
They can apply to the head reference under a notation.
2016-06-27Forbidding silently dropped universes instances inMatthieu Sozeau
internalization. Patch by PMP, test-suite fix by MS.
2016-06-27Shrink Proofs/Obligations by default and deprecateMatthieu Sozeau
Fix bug in Shrink obligations with Program in the process. Fix implementation of shrink for abstract proofs - Update doc in term.mli to reflect the fact that let-in's are part of what is returned by [decompose_lam_assum].
2016-06-27Merge branch 'v8.5'Pierre-Marie Pédrot
2016-06-27More on f9695eb4b, 827663982 on resolving #4782, #4813 (typing "with" clause).Hugo Herbelin
When typing a "with clause fails, type classes are used to possibly help to insert coercions. If this heuristic fails, do not consider it anymore to be the best failure since it has made type classes choices which may be inconsistent with other constraints and on which no backtracking is possible anymore (see new example in test suite file 4782.v). This does not mean that using type classes at this point is good. It may find an instance which help to find a coercion, but which might still be a choice of instance and coercion which is incompatible with other constraints. I tend to think that a convenient way to go to deal with the absence of backtracking in inserting coercions would be to have special For the record, here is a some comments of what happens regarding f9695eb4b and 827663982. In the presence of an instance (x:=t) given in a "with" clause, with t:T, and x expected of type T', the situation is the following: Before f9695eb4b: - If T and T' are closed and T <= T' is not satisfiable (no coercion or not convertible), the test for possible insertion of a coercion is postponed to w_merge, even though there is no way to get more information since T ant T' are closed. As a result, t may be ill-typed and the unification may try to unify ill-formed terms, leading to #4872. - If T and T' are not closed and contains evars of type a type class, inference of type classes is tried. If it fails, e.g. because a wrong type class instance is found, it was postponed to w_merge as above, and the test for coercion is retried now interleaved with type classes. After f9695eb4b and 827663982e: - If T and T' are closed and T <= T' is not satisfiable (no coercion or not convertible), the test for possible insertion of a coercion is an immediate failure. This fixes #4872. - However, If T and T' are not closed and contains evars of type a type class, inference of type classes is tried. If it gives closed terms and fails, this is immediate failure without backtracking on type classes, resulting in the problem added here to file 4872.v. The current fix does not consider the result of the use of type classes while trying to insert a coercion to be the last word on it. So, it fails with an error which is not the error for conversion of closed terms (ConversionFailed), therefore in a way expected by f9695eb4b and 827663982e, and the "with" typing problem is then postponed again.
2016-06-18Giving a more natural semantics to injection by default.Hugo Herbelin
There were three versions of injection: 1. "injection term" without "as" clause: was leaving hypotheses on the goal in reverse order 2. "injection term as ipat", first version: was introduction hypotheses using ipat in reverse order without checking that the number of ipat was the size of the injection (activated with "Unset Injection L2R Pattern Order") 3. "injection term as ipat", second version: was introduction hypotheses using ipat in left-to-right order checking that the number of ipat was the size of the injection and clearing the injecting term by default if an hypothesis (activated with "Set Injection L2R Pattern Order", default one from 8.5) There is now: 4. "injection term" without "as" clause, new version: introducing the components of the injection in the context in left-to-right order using default intro-patterns "?" and clearing the injecting term by default if an hypothesis (activated with "Set Structural Injection") The new versions 3. and 4. are the "expected" ones in the sense that they have the following good properties: - introduction in the context is in the natural left-to-right order - "injection" behaves the same with and without "as", always introducing the hypotheses in the goal what corresponds to the natural expectation as the changes I made in the proof scripts for adaptation confirm - clear the "injection" hypothesis when an hypothesis which is the natural expectation as the changes I made in the proof scripts for adaptation confirm The compatibility can be preserved by "Unset Structural Injection" or by calling "simple injection". The flag is currently off.
2016-06-16Refine 9cc95f5, unification of Let-In's, bug #3929Matthieu Sozeau
We unify types of let-ins in FO heuristic before their bodies, using cumulativity in either direction. This maintains the invariant that we are comparing terms in related types throughout unification. Also adapt test-suite file for bug #3929.
2016-06-15Fix test-suite for opened bug #4813.Pierre-Marie Pédrot
2016-06-14Merge branch 'bug4450' into v8.5Matthieu Sozeau
2016-06-14Merge branch 'bug4725' into v8.5Matthieu Sozeau
2016-06-14Admitted: fix #4818 return initial stmt and univsMatthieu Sozeau
2016-06-13Univs: more robust Universe/Constraint decls #4816Matthieu Sozeau
This fixes the declarations of constraints, universes and assumptions: - global constraints can refer to global universes only, - polymorphic universes, constraints and assumptions can only be declared inside sections, when all the section's variables/universes are polymorphic as well. - monomorphic assumptions may only be declared in section contexts which are not parameterized by polymorphic universes/assumptions. Add fix for part 1 of bug #4816
2016-06-13Fix test-suite file, only part 2 is fixed in 8.5Matthieu Sozeau
2016-06-13Merge branch 'v8.5'Pierre-Marie Pédrot
2016-06-13Univs: fix for part #2 of bug #4816.Matthieu Sozeau
Check that the polymorphic status of everything that is parameterized in nested sections is coherent.
2016-06-12For the record, an example one would like to see working.Hugo Herbelin
2016-06-12Another fix to #4782 (a typing error not captured when dealing with bindings).Hugo Herbelin
The tentative fix in f9695eb4b (which I was afraid it might be too strong, since it was implying failing more often) indeed broke other things (see #4813).
2016-06-11Fixing #4782 (a typing error not captured when dealing with bindings).Hugo Herbelin
Trying to now catch all unification errors, but without a clear view at whether some errors could be tolerated at the point of checking the type of the binding.
2016-06-09Unbreak singleton list-like notation (-compat 8.4)Jason Gross
With this commit, it is possible to write notations so that singleton lists are usable in both 8.4 and 8.5pl1 -compat. Longer lists await the ability to remove notations from the parser.
2016-06-09Merge branch 'v8.5'Pierre-Marie Pédrot
2016-06-09Fixing #4644 (regression of unification on evar-evar problems with a match).Hugo Herbelin
Typically, a problem of the form "?x args = match ?y with ... end" was a failure even if miller-unification was applicable.
2016-06-09Univs/(e)auto: fix bug #4450 polymorphic exact hintsMatthieu Sozeau
The exact and e_exact tactics were not registering the universes and constraints of the hint correctly. Now using the same connect_hint_clenv as unify_resolve, they do. Also correct the implementation of prepare_hint to normalize the universes of the hint before abstracting its undefined universes. They are going to be refreshed at each application. This means that eauto using term can use multiple different instantiations of the universes of term if term introduces new universes. If we want just one instantiation then the term should be abbreviated in the goal first.
2016-06-07Test for #4787.Hugo Herbelin
2016-06-03Removing "exact" from the tactic AST.Pierre-Marie Pédrot
2016-06-01Merge branch 'v8.5'Pierre-Marie Pédrot
2016-05-29Fix bug #4746: Anomaly: Evar ?X10 was not declared.Pierre-Marie Pédrot
Some dubious evarmap manipulation is going on in destruct because of the use of clenv primitives. Here, building a clenv was introducing new evars that were not taken into account in the remainder of the tactic. We plug them back using a local workaround. Eventually, this code should be replaced by an evar-based one, but meanwhile, we rely on what is probably a hack.
2016-05-26rewrite/Univs: Fix bug # 4498.Matthieu Sozeau
2016-05-26Univs/Program/Function: Fix bug #4725Matthieu Sozeau
- In Program, a check_evars_are_solved was introduced too early. Program does it's checking of evars by itself. - In Function, the universe environments were not threaded correctly.
2016-05-23Extraction/Projections: Fix bug #4710Matthieu Sozeau
Use the compatibility match construction to extract the compatibility constant associated to a primitive projection.
2016-05-23Hints/Univs: fix bug #4628 anomaliesMatthieu Sozeau
Fix handling of non-polymorphic hints built from polymorphic values, or simply producing new universes. We have to record the side effects of global hints built from constrs which are not polymorphic when they declare global universes, which might need to be discharged at the end of sections too. Also issue a warning when a Hint is declared for a polymorphic reference but the Hint isn't polymorphic itself (this used to produce an anomaly). For [using] hints, treat all lemmas as polymorphic, refreshing their universes at each use, as is done for their existentials (also used to produce an anomaly).
2016-05-20Merge branch 'v8.5'Pierre-Marie Pédrot
2016-05-16Fix bug #4737: cycle tactic doesn't like zero goals.Pierre-Marie Pédrot
2016-05-09Merge branch 'v8.5'Pierre-Marie Pédrot
2016-05-08Fix bug #4713: Anomaly: Assertion Failed for incorrect usage of Module.Pierre-Marie Pédrot
2016-05-04Merge branch 'v8.5'Pierre-Marie Pédrot
2016-05-04Handle primitive projections inside types when extracting (bug #4616).Guillaume Melquiond
Note that extracting terms containing primitive projections is still utterly broken, so don't use them.
2016-05-03Fix bug #3825: Universe annotations on notations should pass through or be ↵Pierre-Marie Pédrot
rejected.
2016-05-03Test file for #4695: Slow Qed.Maxime Dénès
2016-05-03Fix bug #4292: Unexpected functor objects.Pierre-Marie Pédrot
2016-05-03Use the canonical name when looking for an eliminator (bug #4670).Guillaume Melquiond
Disclaimer: I have no idea what I am doing.
2016-05-03Call hooks when terminating a definition proof (bug #4663).Guillaume Melquiond
Also register properly the kind of definition.
2016-05-02Properly handle notations containing spaces (bug #4538).Guillaume Melquiond
When a notation was starting or ending a space, Coq assumed the notation had no terminal symbol in either places. Coq also considered a notation containing only spaces to be productive. As stated in the documentation, extraneous spaces are only meant as printing hints, they are not meant to have any influence on parsing.
2016-05-02Avoid infinite loop/stack overflow when using "simpl nomatch" (bug #4576).Guillaume Melquiond
When encountering a "simpl nomatch" constant, the reduction machinery tries to unfold it. If the subsequent partial reduction does not produce any match construct, it keeps going from the reduced term. Unfortunately, the reduced term has been refolded in the meantime, which means that some of the previous reduction steps have been canceled, thus causing an infinite loop. This patch delays the refolding till the very end, so that reduction always progresses. Disclaimer: I have no idea what I am doing here. The patch compiles the standard library and the test suite properly, so hopefully they contain enough tests to exercise the reduction machinery.
2016-05-02Merge branch 'v8.5'Pierre-Marie Pédrot
2016-04-29Fix incorrect cbv reduction of primitive projections. (Bug #4634)Guillaume Melquiond
As noticed by Cyprien Mangin, projected terms cannot directly be used as head values. Indeed, they might be applications (e.g. constructors as in the bug report) whose arguments would thus be missing from the evaluation stack when doing any iota-reduction step. The only case where it would make sense is when the evaluation stack is empty, as an optimization. Indeed, in that case, the arguments are put on the stack, and then immediately put back inside the term.