Take advantage of error nodes for error handling

[philberty]

To compile Rust code we have many passes to generate more information stored in side-tables such as name-resolution lookups or type information. With each successive pass we have code to check if any errors have occurred in the previous pass lets exit.

This is not of sufficient quality for error handling, GCC has error_mark_node which means even if you have errors with unknown variables for example we can simply treat this as an error node in the graph and continue the compilation process as far as possible and simply delegate the error handling over to GCC instead of the front-end code. This means we will respect all existing conventions and return codes properly.

This issue will track any child issues trying to fix this in the front-end.

• Take advnatage of error_mark_node #539
• Constant folder should use error_mark_node #692

[bjorn3]

Rustc tries to recover from errors to be able to show successive errors. This allows for a rough estimate if how much errors you still need to fix and sometimes future errors can give useful context about what the actual problem at an earlier stage was.

[tschwinge]

@philberty, I don't know much yet about the structuring of the GCC/Rust front end, but yes, a "layered approach" does seem to make sense. For example, don't attempt semantic analysis if you run into syntax errors.

@bjorn3, GCC is generally doing the same -- though, I sometimes find the occasional long cascade of follow-on errors rather noisy and confusing, especially if they're indeed just error triggered by the original error. For example, if you get a ton of follow-on syntax errors because of one initial syntax error. ;-) (-fmax-errors=[...] to the rescue.)

[yizhepku]

As it stands, the compiler already early returns when failing to parse code(rust-session-manager.cc:477). So what needs to be done then?

[philberty]

Ah good point i merged that piece in. There will need to be some rearrangement here when we start parsing multiple files so i think it is wise to keep this open for now to make sure we test it.

[philberty]

Removing the good-first-pr label this change is a little more complex.

[philberty]

I think this issue is probably needs update to talk about getting rid of the saw_errors() return and track the efforts to start using error nodes for error handling.