| Commit message (Collapse) | Author | Age |
| |
|
|\ |
|
|\ \ |
|
|\ \ \ |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We used to recompute all fresh named contexts for evars before this patch in
the push_rel_context_to_named_context function. This was incurring a linear
penalty and a memory explosion due to the reallocation of many arrays. Now, we
rather remember the context between evar creations by sharing it in the pretyping
environment.
This can be considered as a fix for bug #4964 even though we might do better.
|
| | |\ \ \ |
|
| | |/ / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In Coqide 8.5pl2, "forward one command" (down arrow) always repositions the insertion point at the end of the phrase being executed, just after the final ".".
In Coqide 8.4, the insertion point is not moved if it is after the end of the executed phrase. The insertion point is moved only if it falls behind the phrase being executed.
I find the 8.5 behavior to be a regression over the lot more useful 8.4 behavior. This commit restores the 8.4 behavior of "forward one command".
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
While the performance gain should go unnoticed in most cases, in some
degenerate situations, e.g. the evar-stressing test-case of bug #4964,
this commit speeds up coq by 10% since most of the time is spent scanning
long lists with most of the elements filtered out.
Note that this commit also changes the scanning order to front-to-back,
which is a bit less surprising (though no code should ever depend on the
scanning order).
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
This saves a quadratic allocation by replacing arrays with maps.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In addition to sharing, we also delay the computation of the environment in
a by-need fashion.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We remove in particular a dubious use of an environment in fresh name
generation. The code was using the wrong environment in a function only
depending on the rel context which was resetted most of the time. This
might change the generated names in extremely rare occurences.
|
| | | | | |
|
|/ / / / |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Modulo delta for types should be fully transparent.
|
|\| | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
This partially reverts c14ccd1b8a3855d4eb369be311d4b36a355e46c1
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Fixes both bugs #4924 and #4437.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Apparently, in camlp4 (unlike camlp5) :
- Something like "[ kwd = IDENT "foobar" -> .... kwd ... ]"
produces a kwd of type token instead of string (which sounds reasonable ?).
For now, I've replaced kwd by the explicit strings. Not so nice, but works
with both camlp4 and camlp5
- A quotation of the form "let obj = ... in bar; baz" is not
interpreted in the usual OCaml way, but rather as
"(let obj = ... in bar); baz".
Let's use instead "let obj = ... in let () = bar in baz", which works fine.
|
| | | | |
|
| |\ \ \ |
|
| |/ / /
| | | |
| | | |
| | | |
| | | | |
when checking that the rewrite relation is homogeneous in
setoid_rewrite.
|
|\| | | |
|
| |\ \ \ |
|
|\ \ \ \ \ |
|
| | |/ / / |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
It should use evar instantiations eagerly during unification of
the lhs of the lemma, as in 8.4.
|
|\ \ \ \ \
| |/ / / /
|/| / / /
| |/ / / |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |_|/
|/| |
| | | |
This gives better behavior both when including the `coq_makefile` `Makefile` into other `Makefile`s and when setting `STDTIME` through an environment variable.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- typo in notation_ops.ml
- factorization of patterns in ppconstr.ml
- update of test-suite
- printing of cast of a binding pattern if in mode "printing all"
The question of whether or not to print the type of a binding pattern
by default seems open to me.
|
| | |
| | |
| | |
| | |
| | | |
Supporting accordingly printing of sequences of binders including binding
patterns.
|
| | | |
|
| | |
| | |
| | |
| | | |
(In agreement with Daniel.)
|