| Age | Commit message (Collapse) | Author |
|---|
|
We move gitlab runners to Ubuntu 18.04 "Bionic"; this allows us to
install most base dependencies using APT, and opens up the door to
saving quite a bit of time by creating a custom docker image
[c.f. #7383]
This change comes with an update of dependencies; we tweak them. Also:
- we add a more precise cache `key` constraint; this is still done
manually, we should develop an automated way in another PR. The
format is "$image-v$date-$hour-$minute"
- we export DEBIAN_FRONTEND=noninteractive as to avoid problems with
package installs that ask for interactive input.
- we install Sphinx Python packages using `apt` save for
python3-antlr4, which is still unpackaged [see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897129]
|
|
Closes #7345.
[skip ci]
|
|
Mitigates #7346.
[skip ci]
|
|
|
|
|
|
AFAICS `imagemagick` `hacha` and `transfig` are not used anymore.
|
|
|
|
|
|
Newer versions don't have the latex packages we want.
see eg https://gitlab.com/SkySkimmer/coq/-/jobs/65498131
|
|
|
|
|
|
|
|
|
|
|
|
It begs things to break when the cache is out of sync with the system packages.
|
|
of evars
|
|
Flags.univ_print
|
|
|
|
|
|
There was recently a spurious failure on AppVeyor (I've forgotten which
PR). This commit fixes that particular failure.
|
|
|
|
|
|
```
$ dev/tools/check-owners-pr.sh 6809 --show-patterns --owner '@MSoegtropIMC'
remote: Counting objects: 93, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 93 (delta 47), reused 50 (delta 47), pack-reused 43
Unpacking objects: 100% (93/93), done.
From github.com:coq/coq
* branch refs/pull/6809/head -> FETCH_HEAD
* branch master -> FETCH_HEAD
/dev/build/windows: @MSoegtropIMC
```
|
|
`hint_info_expr`, `hint_info_gen` do conceptually belong to the
typeclasses modules and should be able to be used without a dependency
on the concrete vernacular syntax.
|
|
|
|
|
|
This removes the Flags.univ_print in the kernel, making it possible to
put the univ printing flag ownership back in Detyping.
The lazyness is because getting an explanation may be costly and we
may discard it without printing.
See benches
- with lazy
https://ci.inria.fr/coq/view/benchmarking/job/benchmark-part-of-the-branch/406/console
- without lazy
https://ci.inria.fr/coq/view/benchmarking/job/benchmark-part-of-the-branch/405/console
Notably without lazy mathcomp odd_order is +1.26% with some lines
showing significant changes, eg PFsection11 line 874 goes from 11.76s
to 13.23s (+12%).
(with lazy the same development has -1% overall and the same line goes
from 11.76s to 11.23s (-4%) which may be within noise range)
|
|
|
|
|
|
indirect uses of tactic `clear`.
|
|
come, misc improvements
|
|
Putting `assert false` in the successful recursive case
never triggered. Apparently all users use `split_lib_at_opening`
to find open at current nesting level? `split_lib` appears to
be dead code currently, might also be candidate for removal.
Doing so would allow to simplify `split_lib_gen`, since we only
expect one matching element.
|
|
This has been around for at least 16 years, with the comment
"this won't last long I hope".
https://github.com/coq/coq/commit/12965209478bd99dfbe57f07d5b525e51b903f22#diff-1a3a6f7bd5b2cf1bc6dd43ee04bbc3eaR112
|
|
hypotheses.
|
|
Fix another typo in the documentation's grammar for open variants
|
|
|
|
- Be more precise when trying to clear an hypothesis which
occurs implicitly in a global constant.
- Warns if destruct/induction cannot clear an hypothesis occurring
implicitly in a global.
In the first case, the change in situation
Section A. Variable a:nat. Definition b:=a=a. Goal b=b. clear a.
is:
- before: "a is used in conclusion"
- after: "a is used implicitly in b in conclusion"
In the second case:
Section A. Variable a:nat. Definition b:=a=a. Goal b=b. destruct a.
produces a warning: "Cannot remove a, it is used implicitly in b".
|
|
Four modes currently supported to deal with clashes:
1. Failing in case of clash
2. Renaming the most recent one
3. Renaming the previous hypothesis of same name if not a section variable
4. Renaming the previous hypothesis of same name even if a section variable
The current mode is 3. Keeping it active by default
|
|
In a component-based source code organization of Coq `intf` doesn't
fit very well, as it sits in bit of "limbo" between different
components, and indeed, encourages developers to place types in
sometimes random places wrt the hierarchy. For example, lower parts of
the system reference `Vernacexpr`, which morally lives in a pretty
higher part of the system.
We move all the files in `intf` to the lowest place their dependencies
can accommodate:
- `Misctypes`: is used by Declaremod, thus it has to go in `library`
or below. Ideally, this file would disappear.
- `Evar_kinds`: it is used by files in `engine`, so that seems its
proper placement.
- `Decl_kinds`: used in `library`, seems like the right place. [could
also be merged.
- `Glob_term`: belongs to pretyping, where it is placed.
- `Locus`: ditto.
- `Pattern`: ditto.
- `Genredexpr`: depended by a few modules in `pretyping`, seems like
the righ place.
- `Constrexpr`: used in `pretyping`, the use is a bit unfortunate and
could be fixed, as this module should be declared in `interp` which
is the one eliminating it.
- `Vernacexpr`: same problem than `Constrexpr`; this one can be fixed
as it contains stuff it shouldn't. The right place should be `parsing`.
- `Extend`: Is placed in `pretyping` due to being used by `Vernacexpr`.
- `Notation_term`: First place used is `interp`, seems like the right place.
Additionally, for some files it could be worth to merge files of the
form `Foo` with `Foo_ops` in the medium term, as to create proper ADT
modules as done in the kernel with `Name`, etc...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NB: I made .aux be cleaned only with distclean imitating the main Makefile.
|
|
ie you might see
make
TEST bugs/closed/1337.v
TEST bugs/closed/3263.v
TEST bugs/closed/7777.v
FAILED bugs/closed/3263.v.log
TEST bugs/opened/1.v
...
report: 3263 failed (should be closed)
|
|
|
|
Warnings are just too hard to see. Also there is no point keeping a
noop option except to point people at the replacement, which does not
require configure to succeed.
|
