Assertions

ALL input test cases will be valid. It can be a good idea to do error checking for your own testing and debugging, but it is not necessary. If you encounter what you think is undefined behaviour or think something is ambiguous then do make a forum post about it to clarify. While the generator is a relatively small spec, the latter assignments will not be.

What does it mean to be valid input? The input must adhere to the specification. The rules below give more in-depth explanation of specification particulars.

1. undef-behaviour:

   A test case will not take advantage of undefined behaviour. Undefined behaviour is functionality that does not have an outcome described explicitly by this specification.

2. nonnegative-literals:

   All integer literals will be \(\geq 0\). For example, the following tests would be considered invalid:

   [i in 0..1 | -1];
   [i in -2..-1 | i];
   

3. literal-size:

   All integer literals will fit in 31 unsigned bits. This means an integer literal can be anywhere in the range \([0, 2^{31} - 1]\) or \([0, 2147483647]\). For example, the following tests would be considered invalid:

   [i in 0..1 | -1];
   [i in 0..1 | 2147483648];
   [i in 0..2147483648 | 0];
   [i in -1..1 | 0];
   

4. nonnegative-exp:

   All exponents are \(\geq 0\). Exponents that are \(< 0\) result in fractions (except when the base is 1). Given that the specification restricts generated numbers to be integers, it does not make sense to produce fractions. Therefore, you may assume that any exponent will be greater than or equal to zero, even if the base is 1. For example, the following test would be considered in invalid:

   [i in 0..1 | 2 ^ (0 - 2)];
   

5. expression-size:

   All expressions and their intermediate values will be representable in 32 signed bits. This means the result of an expression can be anywhere in the range \([-2^{31}, 2^{31} - 1]\) or \([-2147483648, 2147483647]\). Any expression which results in or produces in its intermediate computation an integer underflow or overflow is considered invalid. For example, the following testcase is invalid:

   [i in 0..1 | 2147483647 + 1];
   [i in 0..1 | 0 - 2147483647 - 2];
   

6. zero-divide:

   No expression will contain a division by 0. The result of a division by zero is indeterminate so we will not handle it. For example, the following tests would be considered invalid:

   [i in 0..1 | 1 / 0];
   [i in 0..1 | 1 / (1 - 1)];
   [i in 0..1 | 1 % 0];
   

7. simple-bounds:

   The bounds on the index variable will always be integer literals and never an expression. For example, the following test would be considered invalid:

   [i in (1-1)..1 | i];
   

8. sane-bounds:

   The bounds on the index variable will always be such that \(\text{int}_1 \leq \text{int}_2\). For example, the following test would be considered invalid:

   [i in 1..0 | i];
   

9. matching-id:

   Any variable used in an expression will match the variable defined in the generator. For example, the following test would be considered invalid:

   [i in 0..1 | j];
   

10. simple-whitespace:

    Whitespace is guaranteed to be a space, a tab, a carriage return, or a new line. Any other whitespace characters will render the input invalid. Line comments skip all characters until the next newline or EOF. The following ANTLR rules will ensure you adhere to this:

    ::

    WS: [ trn]+ -> skip; LINE_COMMENT: ‘//’ .*? (’n’ | EOF) -> skip;