Track errors from resolving the crate.

[Mark-Simulacrum]

Technically fixes the specific error case in #33525, but in an indirect way. I'm guessing this isn't the right fix and/or is an incomplete fix, but I hope that this will spur discussion/comments from @nrc (at least) to help me figure out what the best way of solving this sort of issue is, so I can apply it elsewhere when and if I encounter similar code to this in the driver.

With this, the output is:

error[E0425]: unresolved name `a`
 --> /tmp/t.rs:2:5
  |
2 |     a;
  |     ^ unresolved name

r? @nrc

[nrc]

I don't think this is the right fix because it causes us to abort after name resolution if there were errors, whereas we ought to continue. You could just ignore the result of track_errors and return Ok, but then you lose track of the errors that should be recorded (i.e., you don't fix the problem). Probably what we should do is change CompileResult so that it returns the number of non-fatal errors in the Ok case, and the driver records that and adds it to any reported errors later. We should do the same for errors from parsing as well as name resolution.

[alexcrichton]

@Mark-Simulacrum thoughts about @nrc's proposed solution? Would you be interested in implementing? We could perhaps move that strategy to the issue in question if not for future contributors!

[Mark-Simulacrum]

Yeah, I'll be taking a look at this sometime tonight or over the coming weekend, just haven't had a chance yet.

[Mark-Simulacrum]

Okay, from what I can tell, actually fixing this will not be trivial, since it would involve changing how we track errors from various places in the compiler. I may come back to this, but I don't think this is something I want to work on just now; I've posted a comment on the original issue summarizing what I've learned and discussed: #33525 (comment).