# 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:

```fine
// @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.:

  ```fine
  // @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.:

  ```fine
  "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.:

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