| Age | Commit message (Collapse) | Author |
|---|
|
Reviewed-by: erikmd
Reviewed-by: silene
|
|
parameters in safe_env
Reviewed-by: herbelin
|
|
Reviewed-by: mattam82
Ack-by: Janno
Ack-by: gares
|
|
Reviewed-by: ejgallego
Reviewed-by: silene
|
|
This fixes #12623 (bidirectionality breaks impredicativity).
|
|
Reviewed-by: ppedrot
|
|
The safe environment features two different sets of delta resolvers, one for
module parameters and one for the actual body of the module being built. The
purpose of this separations seems to have been to reduce the number of name
equations being added to the environment, since the one from the parameters
would already be present at instanciation time.
Semantically, required modules behave like parameters in this respect, i.e.
delta resolvers that come from modules dependend upon are guaranteed to be added
when that module is actually required. As such, there is no need to store the
quotient coming from the dependencies inside the vo file of a given library.
Yet, the previous code would precisely do that, leading to a potential quadratic
blowup in vo file size, similarly to the issue with vio files storing the whole
chain of dependency. This patch fixes the issue simply by segregating those
redundant constraints in the dedicated field, thus dropping them from the vo.
|
|
An h-box inhibits the breaking semantics of any cut/spc/brk in the
enclosed box.
We tentatively replace its occurrence by an h or hv, assuming in
particular that if the indentation is not 0, an hv box was intended.
|
|
C functions were used for floating-point arithmetic operations, by
fear of double rounding that could happen on old x87 on 32 bits
architecture. This commit uses OCaml floating-point operations on 64
bits architectures.
The following snippet is made 17% faster by this commit.
From Coq Require Import Int63 BinPos PrimFloat.
Definition foo n :=
let eps := sub (next_up one) one in
Pos.iter (fun x => add x eps) two n.
Time Eval native_compute in foo 1000000000.
|
|
I believe this renaming makes it easier for new contributors to discover
the code of `ring`.
|
|
Fix #13086.
|
|
The first field of accumulators points out of the OCaml heap, so using
closures instead of tag-0 objects is better for the GC.
Accumulators are distinguished from closures because their code pointer
necessarily is the "accumulate" address, which points to an ACCUMULATE
instruction.
|
|
That way, accumulators again can be used directly as execution
environments by the bytecode interpreter. This fixes the issue of the
first argument of accumulators being dropped when strongly normalizing.
|
|
The second field of a closure can no longer be the value of the first free
variable (or another closure of a mutually recursive block) but must be an
offset to the first free variable.
This commit makes the bytecode compiler and interpreter agnostic to the
actual representation of closures. To do so, the execution environment
(variable coq_env) no longer points to the currently executed closure but
to the last one. This has the following consequences:
- OFFSETCLOSURE(n) now always loads the n-th closure of a recursive block
(counted from last to first);
- ENVACC(n) now always loads the value of the n-th free variable.
These two changes make the bytecode compiler simpler, since it no
longer has to track the relative position of closures and free variables.
The last change makes the interpreter a bit slower, since it has to adjust
coq_env when executing GRABREC. Hopefully, cache locality will make the
overhead negligible.
|
|
Reviewed-by: mattam82
Reviewed-by: ppedrot
|
|
This should save us a lot of useless hashconsing. This change should not be
observable because outside of the proof, the abstracted definition will be
either inlined or redefined with the body coming from the side-effect.
|
|
Reviewed-by: gares
Reviewed-by: ppedrot
Reviewed-by: silene
|
|
Close #12909
|
|
Reviewed-by: mattam82
Ack-by: ppedrot
|
|
Fix #7015
|
|
|
|
|
|
This is not pretty but I do not see how to do this in a way that is both
backwards compatible and efficient.
|
|
Reviewed-by: SkySkimmer
Ack-by: silene
|
|
No need to store the case_info, all the data is reconstructible from the
context. Furthermore, this reconstruction is performed in a context where
we already access the environment, so performance is not at stake.
Hopefully this will also reduce the number of globally allocated VM values,
since the switch representation now only depends on the shape of the inductive
type.
|
|
|
|
The default value of the delta-resolver for name aliasing was
reinitialized at Module and Module Type starting time. The existing
resolver was saved but the saved value was not used in
Safe_typing.constant_of_delta_kn_senv and
Safe_typing.mind_of_delta_kn_senv.
A possible fix could have been to take the saved resolver into account
in Safe_typing.constant_of_delta_kn_senv and
Safe_typing.mind_of_delta_kn_senv. We just try instead not to
reinitialize it.
This incidentally fixes #12525 (Search unable to see through an
"Include" when in an ongoing "Module").
|
|
Persistent arrays expose a functional interface but are implemented
using an imperative data structure. The OCaml implementation is based on
Jean-Christophe Filliâtre's.
Co-authored-by: Benjamin Grégoire <Benjamin.Gregoire@inria.fr>
Co-authored-by: Gaëtan Gilbert <gaetan.gilbert@skyskimmer.net>
|
|
|
|
Reviewed-by: SkySkimmer
|
|
Instead of costly linear reallocations, we share as much as possible of the
prefixes of the various environment subcomponents.
|
|
|
|
Reviewed-by: ejgallego
Reviewed-by: ppedrot
|
|
Ack-by: SkySkimmer
Reviewed-by: ppedrot
|
|
|
|
|
|
Re-raising inside exception handlers must be done with care in order
to preserve backtraces; even if newer OCaml versions do a better job
in automatically spilling `%reraise` in places that matter, there is
no guarantee for that to happen.
I've done a best-effort pass of places that were re-raising
incorrectly, hopefully I got the logic right.
There is the special case of `Nametab.error_global_not_found` which is
raised many times in response to a `Not_found` error; IMHO this error
should be converted to something more specific, however the scope of
that change would be huge as to do easily...
|
|
This makes the invariants in the code clearer, and also highlight this is
only required to implement template polymorphic inductive types.
|
|
Useful for guarding calls to `unfold` or `cbv` to ensure that, e.g.,
`Opaque foo` doesn't break some automation which tries to unfold `foo`.
We have some timeouts in the strategy success file. We should not run
into issues, because we are not really testing how long these take. We
could just as well use `Timeout 60` or longer, we just want to make sure
the file dies more quickly rather than taking over 10^100 steps.
Note that this tactic does not play well with `abstract`; I have a
potentially controversial change that fixes this issue.
One of the lines in the doc comes from
https://github.com/coq/coq/pull/12129#issuecomment-619771556
Co-Authored-By: Pierre-Marie Pédrot <pierre-marie.pedrot@irif.fr>
Co-Authored-By: Théo Zimmermann <theo.zimmermann@inria.fr>
Co-Authored-By: Michael Soegtrop <7895506+MSoegtropIMC@users.noreply.github.com>
|
|
Ack-by: SkySkimmer
Reviewed-by: maximedenes
|
|
Reviewed-by: ppedrot
|
|
line -sprop-cumulative
Reviewed-by: Zimmi48
Reviewed-by: ppedrot
|
|
|
|
Ack-by: SkySkimmer
Reviewed-by: maximedenes
|
|
|
|
Ack-by: Zimmi48
Reviewed-by: ppedrot
|
|
|
|
Reviewed-by: Zimmi48
Reviewed-by: jfehrle
Reviewed-by: maximedenes
Ack-by: ppedrot
|
|
Ack-by: Zimmi48
Reviewed-by: ppedrot
|
|
|
