Spin up one worker thread per cpu, and run filetests on all of them. Use
a reorder buffer in Runner to make sure results are still reported in
order.
Individual test files given as command line arguments are still run
synchronously for easier debugging. Only directories are run on worker
threads. The recursive directory traversal is still happening on the
main thread.
Use a heartbeat thread to send ticks on the reply channel every second,
and use the ticks to detect tests that are stuck. When
Receiver::recv_timeout() is stabilized, we can probably get rid of the
heartbeat thread.
Catch panics on the worker threads and report them as test failures.
This command accepts files and directories containing test cases to run.
Recursively searches for test files in any directory it is passed.
Actually running tests is not yet implemented.
Add an external dependency to the docopt package and use it for a scaffold
command line interface for the cton-util command.
I am not too happy about taking external dependencies, and docopt pulls in 13
other packages. However, I really don't want to be writing command line parsers,
and as long as the external dependencies are confined to the tools crate, we
should be fine.
The core cretonne crate should stay free of external dependencies to avoid
trouble with embedding it.
Implement a basic 'cat' subcommand which currently behaves like unix 'cat'. It
will gain parser powers soon.
libctonfile -> libreader.
This library will only provide .cton file reading/parsing services which are
not needed after deployment.
Code for writing .cton files lives in the main cretonne library because it is
fairly small, and because it is useful for extracting test cases from a
deployed library.
The src/tools directory contains the cretonne-tools crate which will build
binaries for testing cretonne.
The src/libctonfile directory contains the ctonfile library crate which
provides reading and writing of .cton files.
