The main libcretonne crate should not have any external dependencies if
at all possible. Use simple substring matching instead of regular
expressions in the verifier tests to achieve this.
The tools crate no longer depends directly on glob and regex. It still
has an indirect dependency on regex through libfilecheck.
The main libcretonne crate should not have any external dependencies if
at all possible. Use simple substring matching instead of regular
expressions in the verifier tests to achieve this.
The tools crate no longer depends directly on glob and regex. It still
has an indirect dependency on regex through libfilecheck.
This test runs the verifier on each function and matches the resulting
verifier error against the "error:" annotation.
Move the existing verifier test into filetests/verifier/ and use the new
syntex.
This test runs the verifier on each function and matches the resulting
verifier error against the "error:" annotation.
Move the existing verifier test into filetests/verifier/ and use the new
syntex.
The verifier reports the 'location' of an error message as a reference
to the entity that has a problem. This uses the 'AnyEntity' type to
refer to instructions/values/ebbs etc.
Also add an err! macro similar to the one used by the parser.
The verifier reports the 'location' of an error message as a reference
to the entity that has a problem. This uses the 'AnyEntity' type to
refer to instructions/values/ebbs etc.
Also add an err! macro similar to the one used by the parser.
This makes it possible to refer to entities defined in the source file,
using the source names prefixed with $.
For example, $v20 refers to the value by that name in the sources, even
if it was renumbered to 'vx0' in the parsed file.
This makes it possible to refer to entities defined in the source file,
using the source names prefixed with $.
For example, $v20 refers to the value by that name in the sources, even
if it was renumbered to 'vx0' in the parsed file.
Often, an implementation of VariableMap can return references to
internal strings, and Cow::Borrow() allows that without making any
copies.
We still want to allow VariableMap implementations to return owned
strings in case they have to manufacture variable values on demand. The
Cow::Owned() variant does exactly that.
Switch the internal VariableMap implementations over to Cows. It turns
out they can simply store references to substrings of the input test,
completely avoiding string allocation for script-defined variables.
Often, an implementation of VariableMap can return references to
internal strings, and Cow::Borrow() allows that without making any
copies.
We still want to allow VariableMap implementations to return owned
strings in case they have to manufacture variable values on demand. The
Cow::Owned() variant does exactly that.
Switch the internal VariableMap implementations over to Cows. It turns
out they can simply store references to substrings of the input test,
completely avoiding string allocation for script-defined variables.
Create a new directory hierarchy under 'filetests' for all the tests
that are run by 'cton-util test'.
Convert the parser tests under 'tests/parser' to use 'test cat' and
filecheck directives.
Create a new directory hierarchy under 'filetests' for all the tests
that are run by 'cton-util test'.
Convert the parser tests under 'tests/parser' to use 'test cat' and
filecheck directives.
This trait serves as a shared interface for the different kinds of test
commands the 'cton-util test' understands.
Many tests produce output that is run through filecheck for validation.
Provide a simple run_filecheck() function to help with this.
Implement the 'test cat' sub-test which is probably the simplest
possible.
This trait serves as a shared interface for the different kinds of test
commands the 'cton-util test' understands.
Many tests produce output that is run through filecheck for validation.
Provide a simple run_filecheck() function to help with this.
Implement the 'test cat' sub-test which is probably the simplest
possible.
It is common to represent a function as a String, and previously that
required re-validating the UTF-8 in a Vec<u8>. The fmt::Write trait
writes UTF-8 directly into a String, so no extra checking is required.
This also means we can implement Display for Function which gives it a
to_string() method. This makes the function_to_string() method
redundant, so delete it.
The functions in the write module are no longer generally useful, so
make the module private. The Display trait on Function is all we need.
It is common to represent a function as a String, and previously that
required re-validating the UTF-8 in a Vec<u8>. The fmt::Write trait
writes UTF-8 directly into a String, so no extra checking is required.
This also means we can implement Display for Function which gives it a
to_string() method. This makes the function_to_string() method
redundant, so delete it.
The functions in the write module are no longer generally useful, so
make the module private. The Display trait on Function is all we need.
It's not super fast to clone a function, but it is faster than
re-parsing the test case file it came from.
Some tests want to mutate the function, and there may be other tests in
the same script that need the original function.
It's not super fast to clone a function, but it is faster than
re-parsing the test case file it came from.
Some tests want to mutate the function, and there may be other tests in
the same script that need the original function.
Use (Function, Details) in place of the aggregrate DetailedFunction.
It turns out that some tests want to clone and manipulate the function
while the details never change.
Use (Function, Details) in place of the aggregrate DetailedFunction.
It turns out that some tests want to clone and manipulate the function
while the details never change.
This code looks overly complicated because it is anticipating running
jobs in a thread pool.
The test files are loaded and parsed, but not actually executed yet.
Errors are reported back to the test runner.
This code looks overly complicated because it is anticipating running
jobs in a thread pool.
The test files are loaded and parsed, but not actually executed yet.
Errors are reported back to the test runner.
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.
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.
The result from parsing a function is now a DetailedFunction which
includes all comments that can be associated with an entity.
Comments before the first function are ignored, everything else is
associated with the preceeding entity.
The parse_functions() function still returns plain functions.
The result from parsing a function is now a DetailedFunction which
includes all comments that can be associated with an entity.
Comments before the first function are ignored, everything else is
associated with the preceeding entity.
The parse_functions() function still returns plain functions.
