Inconsistent handling of unexpected symbol syntax errors about selfie

[Blazefrost]

If there are warnings but no errors, GCC returns a zero exit code. Using flag -Werror, GCC treats all warnings like errors and will return a non-zero exit code as well.

I prepared some examples that raise unexpected symbol messages which mostly still compile, but may have interesting effects. GCC rejects all of these examples and retursn exit code 1 because syntax errors are errors:

In this example, Selfie returns exit code 10:

int main() {
    uint64_t value;
    value = / 10;
    return value;
}

This example actually does not compile. However, this is not because the input file is not accepted but rather because compile_simple_expression expects compile_factor to allocate a temporary register. However, in line 4556, it merely prints an unexpected symbol message and continues without compiling any factor. Thus, Selfie fails with illegal register access instead:

int main() {
    uint64_t value;
    uint64_t* ptr;
    ptr = (uint64_t*) 42;
    value = ptr --{ 10;

    return value;
}

In this example, the integer literal of the former global variable is applied to the latter as well. Thus, Selfie returns 42:

uint64_t initialized = 42;
uint64_t invalid = ;

int main() {
    return invalid;
}

[ckirsch]

@Blazefrost Error handling in the selfie compiler is something that requires more attention. Very true. Do you have any recommendation on how to fix these issues with the least amount of work? I am swamped right now and won't have much time to do this.

[Blazefrost]

As we discussed, it's probably best to continue compilation after encountering a syntax error and return the exit code afterwards so that we can enumerate all syntax errors.

Both the scanner as well as the parser may raise syntax errors. There are some non-recoverable errors that prompt the scanner to immediately exit with EXITCODE_SCANNERERROR. Maybe we should prefix these errors with fatal, i.e. fatal syntax error, to distinguish them from recoverable errors where we can continue to parse the file.

Another open question is the exit code to return. If we encounter syntax errors in both the scanner and the parser, which exit code should we return? I'd propose to either take precedence on the scanner over the parser, or to introduce a new EXITCODE_SYNTAXERROR.

[ckirsch]

@Blazefrost I suggest we leave the names of the errors as is, assuming those errors are all limitations of the current implementation and could be avoided with smarter code. Thus SCANNERERROR, PARSERERROR, and COMPILERERROR should only be used when exiting immediately. Then we introduce a new SYNTAXERROR as exitcode for syntax errors from which the compiler actually recovers. What do you think?