This disables RPC tests on Windows. They seem to hang instead of failing at the moment, so until we get them
working it seems like it's better to just leave them out.
Now the `NotThreaded` cabal flag can be used to
omit the `-threaded` flag when building the rpc
servers, which reduces the number of `fork`
invocations when running the servers.
We will need a better solution to getting CVC4 eventually, but unbreaking the builds, even temporarily, is high priority. And the right solution for CVC4, with the recent transition to CVC5, is somewhat tricky.
* feat: support for all solver backends for cryptol server/client
* chore: update server docs w.r.t. sat related functionality
* chore: reduce trailing whitespace
* chore: deduplicate usage of helper
* chore: misc build fixes
* chore: type annotation fixes
Add support for TLS connections in both the rpc server
and client. Allow the client to disable certificate validation
via the `verify` keyword argument, i.e.,
`cryptol.connect(verify=False)`. The docker container
for `cryptol-remote-api` also contains a self-signed
cert for testing purposes.
Co-authored-by: Andrew Kent <andrew@galois.com>
This lets the user reset the module search path. It is a bit of a
blunt instrument as it resets the entire path. Perhaps we should also
add the ability to add new paths to the front of the search order,
e.g. with a new `:prependpath` command?
Fixes#631
Unfortunately, the autogenerated documentation (now located in `Cryptol.rst`)
doesn't yet have all of the information contained within the hand-written
documentation (now located in `old-Cryptol.rst`—see #1206. In pursuit of
eventually fixing that issue, the CI now makes sure that any changes to the
autogenerated documentation are checked in.
This bumps the `argo` submodule to include commit
b9b3edd992,
which adds the ability to document the results of methods (in addition to
their parameters). In addition to dealing with the breaking API changes from
that commit, this adds missing documentation for each method's results.
This avoids expensive calls to `combineCallStacks` in the common case;
the actual call stack values are only computed in the case where they
need to be printed out.
For human consumers, it's usually nice to show record fields in the same
order they appear in the source (as sometimes programmers use the field
order as a communication channel to other programmers). However, for
machine consumers, sometimes it is nicer to adhere to a rigid,
predictable format. This commit adds a setting, `field-order`, to switch
between these two modes, with a backward-compatible default.