v0.8.4

This patch fixes a flaky test. There are no user visible changes.

v0.8.3

This release just contains internal refactoring and should have no user visible changes.

v0.8.2

Small internal refactors.

v0.8.1

This release implements DefaultGenerator for PathBuf.

v0.8.0

Add Mode::SingleTestCase setting for running exactly one test case with no shrinking or replay. Available via Settings::mode(), #[hegel::test(mode = Mode::SingleTestCase)], and the --single-test-case CLI flag.

This mode is mostly intended for long-running workloads, so in this mode, repeat becomes a simple infinite loop, and stateful testing will keep running rules indefinitely.

v0.7.6

This patch adds generators::deferred(), which creates a generator that can be declared before it is defined. This enables forward references, which are needed for defining mutually recursive or self-recursive generators.

use hegel::generators::{self as gs, Generator};

enum Tree {
    Leaf(i32),
    Branch(Box<Tree>, Box<Tree>),
}

let tree = gs::deferred::<Tree>();
let leaf = gs::integers::<i32>().map(Tree::Leaf);
let branch = hegel::tuples!(tree.generator(), tree.generator())
    .map(|(l, r)| Tree::Branch(Box::new(l), Box::new(r)));
tree.set(hegel::one_of!(leaf, branch));

Call .generator() to get handles that can be passed to other generators, then call .set() to provide the actual implementation. set consumes the definition, so it can only be called once.

v0.7.5

Bump our pinned hegel-core to 0.4.6, incorporating the following changes:

This release adds a new conformance test OriginDeduplicationConformance.

— v0.4.5

This patch fixes several concurrency bugs and improves error handling robustness in the protocol layer.

The server's reader loop no longer crashes when it receives a packet for an unknown or already-closed stream, or a malformed close-stream packet. Instead, it sends an error reply back to the client (for request packets) and continues processing. This means clients that make protocol mistakes will now get a clear ProtocolError response instead of the server silently dying.

Several race conditions in the protocol layer have been fixed. Connection.close() and Stream.close() now use dedicated locks to ensure their check-and-set guards are atomic, preventing concurrent callers from double-closing. Connection.close() holds the writer lock while closing the socket, so no write_packet call can be mid-flight when the fd is yanked. Stream.write_request protects the message ID increment with a lock so concurrent writers get unique IDs. Connection.new_stream allocates stream IDs under the writer lock. receive_handshake now sets _handshake_done after the handshake reply is sent rather than before.

Bare assert statements throughout the protocol and server code have been replaced with explicit error raises (ProtocolError, ValueError, ConnectionError) with descriptive messages. This prevents assertion-removal in optimized Python builds and gives clients and logs meaningful diagnostics.

StdioTransport.sendall now converts ValueError (from writing to a closed file descriptor) to OSError, so the existing error handling in the protocol layer catches it correctly. This fixes the "ValueError: I/O operation on closed file" error that could occur when the client disconnects while the server is still writing.

— v0.4.6

v0.7.4

This patch adds windows support for hegel-rust. It is somewhat experimental, but the full
feature set should work.

v0.7.3

This adds two new macros to allow more flexible use of hegel.

• #[hegel::main] wraps a function as a standalone binary entry point, exposing CLI flags for every Settings option.
• #[hegel::standalone_function] rewrites fn(tc: TestCase, args...) into fn(args...) so a property test can be invoked directly.

v0.7.2

This patch loosens restrictions on using threads in hegel-rust. TestCase now implements Send
(and already implemented Clone) so data generation can now occur from multiple threads.

Important

This feature should be used only with extreme caution at present. Please consult the TestCase
documentation for details, but it can only be correctly used with extreme care. We intend
for threading support to get significantly better over time without the API changing,
and this is an initial release of the intended API with the worst possible implementation
of it. We are releasing it because even with these caveats it is useful in some cases,
but it is highly likely not to be ready for you to use yet.