| Commit message (Collapse) | Author | Age |
... | |
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
It breaks test-suite of trunk since Matthieu's fixes for the soundness of
polymorphic universes, and I am unsure of the expected semantics. We should
reintroduce it later on when we understand better the issue of simply fix it
once and for all.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The detection of new hypothesis was bugged.
Now infoH behaves like "Show Intros": it performs tac, grab
information on hypothesis names but let the state unchanged.
FTR: infoH is fundamentally unable to be correct in presence of
tactics that delete hypothesis and reuse there names. Like destruct or
induction. Fortunately destruct and induction now come with a variant
asking that the hypothesis is not deleted. To guess for the right
as-close for [induction H], do [infoH induction !H]. This will not
create the same names as induction would have by itself but at least
there will be the right number of hypothesis.
|
| |
| |
| |
| |
| |
| | |
Update the evar_source of the solution evar in evar/evar problems to
propagate the information that it does not necessarily have to be solved
in Program mode.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This is not perfect though, some primitives are unsound, and some
higher-order API should use polymorphic functions so as not to depend
on a given level.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\| |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
presence of dependent types with only superficial dependency).
See discussion at https://coq.inria.fr/bugs/show_bug.cgi?id=4372.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
variables of the context of an evar in debugging mode.
|
| |
| |
| |
| | |
starting a sentence with a symbolic expression.
|
| |
| |
| |
| |
| |
| |
| | |
of the return clause and of the branches (what assumed that the
implementation preserves the invariant that the return predicate and
the branches are in canonical [fun Δ => t] form, with Δ possibly
containing let-ins).
|
| |
| |
| |
| |
| |
| |
| |
| | |
dealing with "match".
Contrastingly, "fix" is considered not to count let-ins for finding
the recursive argument (which is ok because the last argument is
necessarily a lambda).
|
| |
| |
| |
| |
| |
| |
| | |
to compensate decompose_lam_n_assum which does not count let-ins.
Any idea on a uniform and clear naming scheme for this kind of
decomposition functions?
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This allows to remove a lot of independent code from Evd which was put
into the UState module. The API is not perfect yet, but this is a first
pass. Names of data structures should be thought about too because they
are way too similar.
|
| |
| |
| |
| | |
This was a trivial overlook.
|
| | |
|
| | |
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Was introduced by seemingly unrelated commit
fd62149f9bf40b3f309ebbfd7497ef7c185436d5.
The currently policy is to avoid exposing global references in the kernel
interface when easily doable.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using the same hack as in the kernel: VM conversion is a reference to
a function, updated when modules using C code are actually linked.
This hack should one day go away, but always linking C code may produce some
other trouble (with the OCaml debugger for instance), so better be safe
for now.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Previously, the kernel was silently switching back to the standard conversion.
|
| | |
|