History

John Doty ab477cd783 [fine] Simplify function compilation This is simpler because we don't "discover" functions to compile as we go, we just compile all the ones we can find, and functions have pre-defined exports. This is good and useful to us as we can now refer to functions in different modules by known indices, but it does make me wonder what we're going to do for compiling generic specializations. The previous technique was better for that sort of thing. This is all predicated on the idea that I want to have partially-compiled modules, which I can't really say why I want it. If I'm happy to just compile things cross module in the same kind of space then it's much easier to go back to the function key way of working.		2024-03-29 19:12:18 -07:00
..
errors	[fine] Parse alternate types	2024-02-01 07:56:30 -08:00
expression	[fine] Simplify function compilation	2024-03-29 19:12:18 -07:00
modules	[fine] Simplify function compilation	2024-03-29 19:12:18 -07:00
example_tests.rs	[fine] All error sentinels carry diagnostics	2024-03-25 08:07:18 -07:00
README.md	[fine] OK	2024-01-13 15:07:38 -08:00

README.md

Snapshot Tests

The .fine files in this directory and its descendants are processed by build.rs into a series of snapshot-tests. The various test assertions are specified by @ directives in comments in the file.

e.g., a test might look like this:

// @concrete:
// | File
// |   ExpressionStatement
// |     BinaryExpression
// |       BinaryExpression
// |         LiteralExpression
// |           Number:'"1"'
// |         Star:'"*"'
// |         LiteralExpression
// |           Number:'"2"'
// |       Plus:'"+"'
// |       BinaryExpression
// |         UnaryExpression
// |           Minus:'"-"'
// |           LiteralExpression
// |             Number:'"3"'
// |         Star:'"*"'
// |         LiteralExpression
// |           Number:'"4"'
// |     Semicolon:'";"'
//
1 * 2 + -3 * 4;

// @type: 532 f64

Assertions

The various assertions are as follows:

The // @ignore directive marks the test as ignored.

The // @concrete: assertion says that the following lines (prefixed with // | , as above) describe the concrete syntax tree of the file after parsing.

e.g.:

// @concrete:
// | File
// |   ExpressionStatement
// |     LiteralExpression
// |       String:'"\"Hello world\""'
// |     Semicolon:'";"'
//
"Hello world";

The // @type: assertion says that the type of the tree at the given point will match the given type. @type assertions usually go after the contents of the file to make the probe points more stable in the face of new assertions and whatnot.

e.g.:
```
"Hello world!"
// @type: 2 string
```
The // @type-error: assertion says that the type of the tree at the given point should be an error, and that the error message provided should be among the generated errors. (Like @type, these usually go after the code, for stability.)

e.g.:
```
- "twenty five";
// @type-error: 0 cannot apply unary operator '-' to value of type string
```