| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
is not defined while X_rect is, for example in HoTT/Coq.
|
|
kernel reduction.
|
|
In the case of conversion, postponing by preserving the
initial orientation.
Was wrong from its initial version in Jan 2014, but was not visible
because evar-evar subtyping was approximated by evar-evar conversion.
Thanks to Enrico for a very short example highlighting the problem. In
particular, this fixes Ergo.
|
|
test pattern-unification after restriction of the evars so as to
succeed earlier (no observational changes however in the examples at my
disposal).
|
|
|
|
|
|
e.g. for MTac.
|
|
|
|
Putting utf8 everywhere helps the maintainance of the online refman.
And anyway, this is the way to go. We should also chase and migrate
the few remaining iso-latin-1 files elsewhere in the sources.
|
|
|
|
Unfortunately, these ?uri=referer parameters do not work correctly
now that coq.inria.fr forces the switch to https before answering
any document. See: http://validator.w3.org/docs/help.html#faq-referer
I currently see no workaround for that, apart from generating links
like ?uri=http://the.real.url/of/my/page, which would be quite painful.
For now, users interested in checking the validity of our pages
will have to copy-paste the url they want to check after clicking
on the validator button.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from v8.4)
- For the style of identifiers, coqdoc was using a 'type' attribute of
tag <span>. But this attribute isn't a legal attribute of tag <span>
according to the xhtml norm. Instead, I propose to use 'title' for that.
The coqdoc.css now supports both approaches.
- The names of inner links (cross references #foo) were
containing arbitrary characters (in the case of a notation string).
For instance in Utf8_core : <a name=":type_scope:'∀'_x_'..'_x_','_x">
Instead, when strange characters are detected, we now hash the
string via Digest, and use this hexa hash as html label.
- And some whitespace before />
|
|
|
|
|
|
|
|
To be continued someday, those style files are full of redundancies...
|
|
documentation en ligne)
|
|
documentation)
This commit r14895 comes apparently itself from commit r12010 in branch v8.2
|
|
|
|
?n[...] = ?p[...;x:=?n[...];...]. Indeed, x could be a solution for ?p.
|
|
As their commit messages suggested it, these commits were not intended
to be committed at this time. They are part of a on-going merge of the
code of induction and functional induction. Together with the fix
here, they are supposingly transparent, semantically speaking.
|
|
|
|
[Proofview].
The primitives in [Tacticals] respect Ltac's error level, whereas the one in [Proofview] do not necessarily. In that case the error caught was ignored causing arbitrary error level after [constructor] to be canceled.
Needed the addition of an [ORD] variant to [OR] in [Tacticals.New] to avoid unnecessary precomputation (the 'D' stands for 'delay').
Fixes #3838.
|
|
|
|
|
|
|
|
|
|
buffer.
|
|
In particular, renouncing to original support for existing non .v
files in CoqIDE (hoping it is ok for anyone). Please amend if better
to propose.
|
|
similar optimization broke at some time some ssreflect code; we now
treat the easy case of a let-in to a rel - a pattern common in
pattern-matching compilation -; later on, we shall want to investigate
whether any let-in found to refer to out of scope rels or vars can be
filtered out).
|
|
|
|
|
|
propagate it. This allows C-zar to continue to work.
Don't know if it is the best way to do it.
|
|
the import of goal.ml and, afaiu, ocaml does not provide a way to
refer to a shadowed module.
|
|
|
|
|
|
status of #3278 (more precisely, it fixed a bug visible in the #3278
report, but a bug which arrived after #3278 was submitted).
|
|
|
|
|
|
- new function set_flags_for_type for setting flags when converting
types of the terms to unify
- it now sets all conversion flags, possibly restricting delta using
modulo_delta_types
- it is now used in w_unify_core_0 too
- fixing/improving documentation of options
- deprecating "Set Tactic Evars Pattern Unification"
|
|
Still to do:
- Decide between using SeveralInstancesFound or raising an error when
multiple instances exist.
- Use a proper printer for evars instead of the debugging
pr_evar_map_filter printer in pr_constraints.
|
|
types: we downcast the evar in the higher type to the lower type.
Then, we have the freedom to choose the order of instantiation
according to the instances of the evars (e.g. choosing the
instantiation for which pattern-unification is possible, if ever it is
possible in only one way - as shown by an example in contribution
Paco).
This still does not preserve compatibility because it happens that
type classes resolution is crucially dependent on the order of
presentation of the ?n=?p problems. Consider e.g. an example taken
from Containers. Both now and before e2fa65fccb9, one has this asymmetry:
Context `{Helt : OrderedType elt}.
Check forall x y r l h, @Equivalence.equiv _ _ _ x y -> In x (Node l x r h).
--> @Equivalence.equiv QArith_base.Q QArith_base.Qeq QArith_base.Q_Setoid x y
Context `{Helt : OrderedType elt}.
Check forall x y r l h, In x (Node l x r h) -> @Equivalence.equiv _ _ _ x y.
--> @Equivalence.equiv elt (@_eq elt Helt) (@OT_Equivalence elt Helt)
Then, embedding this example within a bigger one which relies on the
?n=?n' resolution order, one can get two incompatible resolution of
the same problem.
To be continued...
|
