Should the compiler stop compiling after parsing if syntax errors have occurred?

[bradcray]

Over the compiler's history, a common complaint has been that we stop compiling after an error occurs, making it hard for users to work through a series of errors without recompiling again and again, fixing one at a time. The current Dyno compiler makes great strides in doing less of that. This issue asks whether, in some cases, we should consider stopping compilation—or squashing different classes of errors—once errors have occurred since cascades of errors can be more confusing than helpful.

As an example, consider this program which is lacking either the required do or curly brackets to define a procedure body under the current rules:

proc foo()
  return 42;

Once the deprecated old behavior is removed, the compiler generates:

testit.chpl:2: syntax error: near 'return'
testit.chpl:1: In module 'testit':
testit.chpl:1: error: no-op procedures are only legal for extern functions

The syntax error is completely correct, but the error about a no-op procedure seems incorrect ("it looks like it's doing something!") and distracting (since it's the last thing that appears, consumes two lines, and feels a bit more actionable than a syntax error).

Given a file with the same pattern four times in a row, we get the four syntax errors before getting any of the no-op errors, suggesting to me that perhaps we should stop compilation if syntax errors were detected after parsing rather than going on to run post-parsing checks (which is where the no-op error is generated, I believe). Or, if there's a more subtle interplay than I'm picking up on (do we parse and post-parse one module before going on to the next?), then maybe post-parse checks should be squashed or skipped in the presence of syntax errors without completely halting compilation just yet?

Curious for others' thoughts on this.

[mppf]

What is supposed to be happening in a case like this is that when there is a parse error, we save ErroneousExpression in the uAST. Ideally, in this case, we would create a Function that contains a body of ErroneousExpression. Then, later parts of the compiler should ignore the ErroneousExpression & use it as a signal that errors about that part should be ignored.

The trouble with this approach is that it's unlikely we will have these cases working out of the gate (although hopefully some will) and so we will rely on issues like this one to know that there is something to adjust.