Compiler should not globally stop compilation based on errors

[larsbergstrom]

Right now, rustc will report error messages only up through the highest phase it could complete. That leads developers to think they nearly have worked through all of the compilation errors only to be hit by another huge lump of them after they get to the next phase. One of our external Servo contributors described this as, "demoralizing because it looks like the number of errors is decreasing, but in reality the parser just hasn't gotten past the second line."

Ideal would obviously be to report an overall number that was more representative of the total number of errors, but even showing a measure of the overall progress (cmr suggested a counter like "125 errors (stage 3/N)") would be a huge improvement.

[comex]

C compilers can muddle past parse errors and try to provide higher-level diagnostics for what remains, presumably to avoid this problem. rustc should be made able to do the same.

[XMPPwocky]

This also seems to apply to warnings; recently, when #[deriving] changed to #[derive], the unused_atttribute warnings were not printed if the code broke because of the change!

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#633

[Centril]

I'm reopening this and closing the issue on the RFCs repo since this is a diagnostics issue and doesn't require an RFC afaik.

cc @rust-lang/compiler

[estebank]

There has been a huge push since 1.0 to continue past parse errors and avoiding unnecessary type errors on recovered blocks, but we still have this problem with borrow errors that don't get evaluated until after type checking succeeds. It will be a huge undertaking to enable partial borrow checking with incorrect types, but it would likely be worth it.

[eddyb]

@estebank There's a much more readily doable subset: we can borrow-check the functions that do have correct types. That is, don't stop the compiler after type-checking, if there were errors.

[estebank]

In order to have a deliverable for this ticket, I would say the last line should have some wording along the lines of "some errors may have not been emitted" if the compiler encountered FatalError.raise() before reaching the last stage.

[oli-obk]

Got closed because of a typo

[estebank]

FWIW, I believe that the situation has changed so dramatically since this ticket was filed that I would personally feel fine with closing it.

There have been two related efforts:

• eliminate hard stops in the compiler, allowing recovery and continuing later stages; I would say we aren't 100% done, but all but the absolutely hardest cases have been addressed
• avoid redundant errors from later stages caused by invalid state from earlier stages; I believe we're in a good state nowadays, certainly compared to where we were in 2016

There are other changes being made to help in the spirit of this ticket (changing the representation of ErrorGuaranteed to hold extra information comes to mind), but I feel like smaller, more targeted tickets ("under X circumstances, we get Y output which is too much/not enough") will make it easier for contributors to make progress towards the goal of "present the user all the necessary errors, and nothing more".