| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The use of template polymorphism in constants was quite limited, as it
only applied to definitions that were exactly inductive types without any
parameter whatsoever. Furthermore, it seems that following the introduction
of polymorphic definitions, the code path enforced regular polymorphism as
soon as the type of a definition was given, which was in practice almost
always.
Removing this feature had no observable effect neither on the test-suite,
nor on any development that we monitor on Travis. I believe it is safe to
assume it was nowadays useless.
|
| |
|
|
| |
This ought to ease the understanding of the code.
|
| |
|
|
| |
This was an easy to prove property that I somehow overlooked.
|
| |
|
|
|
| |
This is actually useless, the code does not depend on the value of the
entry for side-effects.
|
| |
|
|
|
|
| |
Instead of relying on a mutable state in the object pushed on the libstack,
we export an API in the kernel that exports the side-effects of a given
entry in the global environment.
|
| |
|
|
|
| |
We sprinkle a few GADTs in the kernel in order to statically ensure that
entries are pure, so that we get stronger invariants.
|
| | |
|
| |
|
|
|
| |
We use an algebraic type instead of a pair of a boolean and the corresponding
data. For now, this is isomorphic, but this allows later change in the structure.
|
| |\ |
|
| |\ \ |
|
| |\ \ \ |
|
| |\ \ \ \ |
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
This rule is used by opam package coq-coqide
|
| | | | |_|/
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This ensures that the API is self-contained and is, well, an API.
Before this patch, the contents of `API.mli` bore little relation with
what was used by the plugins [example: `Metasyntax` in tacentries.ml].
Many missing types had to be added.
A sanity check of the `API.mli` file can be done with:
`ocamlfind ocamlc -rectypes -package camlp5 -I lib API/API.mli`
|
| | |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We sort the dependency graph of API by following a logical declaration
order in `API.{ml,mli}` related to the actual dependency order of Coq
modules.
Things are a bit tricky here as Coq itself relies on the fact that
OCaml treats module interface and implementation separately
dependency-wise; however, when resorting module alias the design seems
to become more coupled.
Currently, API exposes both "namespaces", asserting a large number of
type equality between them, however the `API` namespace is not
self-contained.
In particular, this is a first step to solve problems such as
`Summary.frozen` being used in `API.mli` but not declared by the
`API.Summary` module, etc... In general we follow the invariant that a
type used in `API` must have been declared before.
Keep in mind that OCaml upstream has warned that it maybe tricky to
alias objects in this way. In particular, after API the old `mli` only
files have become full compilation units so we may want to be more
careful here.
The more "correct" declaration order allows us to remove the
`API.Prelude` module, as well as some other declarations that I
consider as spurious.
We still maintain the large number of type aliases which will be
removed in a future patch.
We follow linking order except for files in `intf`, which are
conceptually wrongly placed in the linking hierarchy but this doesn't
matter as the files don't contain any implementation.
We also move a couple of `.mli` only files to `.ml` so we are
consistent, and correct their linking order in `mllib`, even if that
doesn't matter as such `.ml`-only files contain no implementations.
|
| |\ \ \ \ |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Avoid Anomaly (or Assert False) when a module signature contains
an applied functor followed by a "with Definition" or "with Module"
Also fix the dependency computation in presence of a "with Definition"
Concerning 4720, the code extracted out of this bug report was suboptimal
in Coq 8.4 (it was compilable, but could have probably been tweaked into a
real issue producing faulty code).
But the example of 4720 (and some variants of it) was broken since 8.5,
for the same reasons as 5177 and 5240. And the good news is that after
these repairs, the example of bug 4720 is now extracted to correct code
(the "with" is preserved).
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In unix one can concatenate a prefix with an absolute path in
order to obtain a valid path. This is not the case on Windows.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
In particular, find it under $(COQBIN)
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Replacing ; with && and enabling bash's pipefail option
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | |/ / /
|/| | | |
|
| |\ \ \ \ |
|
| |\ \ \ \ \ |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
persistent states.
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ \ \
| |_|_|_|/ / / / / /
|/| | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ |
|
| | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | | |
8.5.
|
| |\ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | |_|_|_|_|_|_|_|_|/ / / /
|/| | | | | | | | | | | | |
|
Pierre-Marie Pédrot
Maxime Dénès
Matej Košík
Pierre Letouzey
Emilio Jesus Gallego Arias
Enrico Tassi