Don't build the full compiler before running unit tests

[jyn514]

This has been present since builder.ensure was first added in #43059.
It's unclear to me why it was added then - I tested these changes locally
with x test compiler/rustc_data_structures --stage 0 and they worked fine.

Fixes#51748.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Dylan-DPC]

@bors r+ rollup

[bors]

📌 Commit ae12597 has been approved by Dylan-DPC

[jyn514]

@Dylan-DPC please don't rollup sensitive bootstrap changes like this; it's not unheard of for them to only fail in a full bors test, and I don't really have a way of replicating all those tests locally.

[Mark-Simulacrum]

In general the likely intent here was that if some of our unit tests (as seems not unlikely, though perhaps wrong and fixable) are making use of extern crate foo where foo is loaded from the sysroot and not communicated to Cargo via dev-dependencies or something like that, then this will fail. I think CI should catch that, though there may be some amount of stage-dependence (running tests in stage 2 may not notice this, nor stage 0, though I'm not 100% sure on that).

[jyn514]

if some of our unit tests (as seems not unlikely, though perhaps wrong and fixable) are making use of extern crate foo where foo is loaded from the sysroot and not communicated to Cargo via dev-dependencies or something like that, then this will fail.

Ah, interesting, that sounds possible. But we should be able to fix it by adding to dev-dependencies, right? Unless we have a situation where e.g. a test for rustc_lexer depends on rustc_driver ... but that seems kind of cursed and at that point it should probably just be a UI test.

Anyway, I'll run --stage 1 tests of all the compiler crates to make sure this doesn't break them :)

[Mark-Simulacrum]

Well, in theory there's nothing wrong with rustc_lexer depending on rustc_driver as a dev-dep (beyond "why???") from Cargo's perspective I think.

But yes, I think it should be fixable unless I'm missing something, just that as-is this may break things. I wish we had a better way of reviewing and testing these patches, but as-is I am tempted to r- this sort of thing (or I guess we can wait till someone reports breakage...).

[jyn514]

Ok, I ran x test --stage 1 compiler/* (manually removing codegen_gcc and codegen_cranelift, which apparently aren't supported right now) and it passed fine. I'll leave it up to you whether to r- or not.

[Mark-Simulacrum]

That seems likely good enough for now.