Errors

Errors must be reported on the standard error output. The exit status and the standard error output must be consistent: the exit status is 0 if and only if there is no output at all on the standard error output. There are actually some exceptions: when tracing is enabled (such as during scanning, parsing, etc.)

Compile errors must be reported on the standard error stream with precise error location. The error output must exactly follow the format specified below where location includes the file name, initial position, and final position.

location: error message

There is no fixed set of error messages.

Examples include:

$ echo "1 + + 2" | ./tc -
error→standard input:1.4: syntax error, unexpected "+"
error→Parsing Failed

and

$ echo "1 + () + 2" | ./tc -T -
error→standard input:1.0-5: type mismatch
error→  right operand type: void
error→  expected type: int

Warning

The symbol error→ is not part of the actual output. It is only used in this document to highlight that the message is produced on the standard error flow. Do not include it as part of the compiler’s messages. The same applies to ⇒.

The compiler exit value should reflect faithfully the compilation status. The possible values are:

0

Everything is all right.

1

Some error which does not fall into the other categories occurred. For instance, malloc or fopen failed, a file is missing, etc…

An unsupported option must cause tc to exit with 64 (EX_USAGE) even if related to a stage option otherwise these optional features will be tested, and it will most probably have 0. For instance, a TC-5 delivery that does not support bounds checking must not accept --bounds-checking.

2

Error detected during the scanning, e.g., invalid character.

3

Parse error.

4

Identifier binding errors such as duplicate name definition, or undefined name use.

5

Type checking errors (such as type incompatibility).

64 (EX_USAGE)

The command was used incorrectly, e.g., with the wrong number of arguments, a bad flag, a bad syntax in a parameter, etc…

This is the value used by argp.

Error handling:

Warning

The following part is valid only if you implement error recovery for you compiler.

When several errors have occurred, the least value should be issued, not the earliest. For instance:

(let error in end; %)

should exit 2, not 3, although the parse error was first detected. (if you did not implemented error recovery the example above should exit 3)

In addition to compiler errors, the compiled programs may have to raise a runtime error, for instance when runtime functions received improper arguments. In that case use the exit code 120, and issue a clear diagnostic. Because of the basic MIPS model we target which does not provide the standard error output, the message is to be output onto the standard output.