Do not complain about missing main when a block has been recovered

[estebank]

Follow up to https://github.com/rust-lang/rust/pull/66183/files#r346077120.

r? @Centril

[Centril]

Are you sure that we actually reach Eof in all cases, e.g. the return below?

[estebank]

changed

[estebank]

I had to change it back. Setting reached_eof before all of the returns in the loop would cause the missing main error to come up (!?).

[Centril]

I don't feel entirely comfortable reviewing the correctness of this right now (in particular that we don't suddenly allow code) and I don't have much time to do an in-depth review, so I'll r? @petrochenkov for now.

That said, here's a sledge-hammer suggestion which would be easy to be confident in: Record whether .has_err() after parsing and don't emit errors about missing fn main if there were.

[petrochenkov]

I'd rather get rid of reached_eof and always emit the "no main" diagnostics instead.

This is such a random ad hoc bit of logic.
The unclosed delimiter recovery can swallow any kinds of items causing various semantic / type errors due to that, why should the "no main" error be treated specially?

[petrochenkov]

The existing logic seems to set reached_eof pretty inconsistently too, and not necessarily when crate parsing encounters EOF while having an unclosed delimiter.
Every parser created to parse something local can set the global value in the session.
I also don't understand why recover_closing_delimiter and emit_unclosed_delims are two seemingly independent pieces of code.

I don't want to have this debt accumulating on top of other debt, reporting a false positive "no main" error in some cases has much less importance than that.