Instead of relying on the internal SBV portfolio mechanism, we simply
do it ourselves "from the outside". The SBV portfolio solver now works
in essentially the same way as the What4 one: if the first result we
get is an error, we continue waiting for other solvers and only
present exceptions to the user if all provers fail.
Fixes#798Fixes#693
This turned out to be relatively straightforward. Using
a simliar strategy to SBV, we simply spawn off all the solvers
in separate threads and wait using the `async` package.
Some minor fixes in `What4` allow the threads to respond properly
to being interrupted.
Some care is required to install the necessary solver options
_before_ spawning off the threads to avoid race conditions
in the configuration datastructure itself; such race conditions should
be fixed in What4 at some point.
When configuring the SBV `yices` solver, search for both
spellings of the SMTLib2 executable for `yices`. Different
environments/packaging, for some reason, use different names
for this.
Fixes#592
Rather than looking up prover information by name every
time we do a proof, we fetch the prover configuration as soon
as the user selects a prover using `:set prover=` and remember
it as part of the REPL state. This will allow us to
do some work at configuration time and remember the results.
As part of this refactoring, we now print the list of solvers
that SBV found when using `:set prover=any`.
This changes the way the special "Error" type is used. The error
message now contains only an explanation of what happened,
and the actual malformed type is the parameter of the error function,
which is always used at kind `k -> k` where `k` is the malformed kind.
This fixes (or at least improves) #768
This type stores records as a finite map from field names to
values, while also remembering the original order of the fields
from when the record was generated (usually, from the program source).
For all "semantic" purposes, the fields are treated as appearing in
a canoical order (in sorted order of the field names). However, for
user display purposes, records are presented in the order in which
the fields were originally stated.
In the course of implementing this, I discovered that we were not
previously checking for repeated fields in the parser or typechecker,
which would result in some rather strange situations and could probably
be used to break the type safety. This is now fixed and repeated fields
will result in either a parse error or a panic (for records generated
internally).
Fixes#706
* Add docstrings for all prelude functions and fix minor style issues.
Fixes#771
* Update `CryptolPrims` documentation
* Minor updates to the prelude
* Update CHANGES
* Updates to the cryptol book and CryptolPrims
* Fix several additional docstrings
* Specify and document properties of signed bitvector division.
Fixes#677
* Fixup test
* typos and style
* Regenerate PDFs
is safe for all inputs.
This is similiar to the `:prove` command, except that it ignores
the computed value and only checks for safety condition violations.
Because the value is ignored, a wider variety of types can be
checked with `:safe`. Instead of just `Bit`, any finite return
type is allowed.
This allows us to distinguish cases where counterexamples find inputs
that violate safety conditions from cases where inputs cause the
predicate to be false.
