issue #45357 don't build clippy stage 1

[ratmice]

#45357
Wasn't sure top_stage was the right thing, but seemed to go ahead building clippy stage 2.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[kennytm]

r? @Mark-Simulacrum

[oli-obk]

There are other crates mentioned in the issue. Can you limit them to stage 2, too?

[ratmice]

@oli-obk Good catch, I didn't run into any issues with rustdoc or cargo,
looking a bit closer perhaps these are already handled, I will try using the same thing as cargo's default_condition, however my turn around time on this is fairly slow.

For rustdoc I believe it is handled here:
Build rustdoc only at the top stage

With Cargo I think perhaps it is handled by this line:
Add an optional condition to constrain defaults.

Where the should_run for rustdoc has no such condition.
rustdoc should_run

Edit: Retrying with extended=true in config.toml to see if that won't induce a failing cargo build.

[ratmice]

@oli-obk So .default_condition(builder.build.config.extended) does appear to limit building cargo (and clippy when set) to stage 2 when extented = true in config.toml, However I don't see where this happens occur.

Anyhow, I'm at a bit of a loss as to whether clippy needs the condition set instead of my patch,
Or cargo needs something like the match expression from my patch added.
Some of that depends upon whether we really want clippy default, or just in the set of extended tools.

[oli-obk]

The extended check for clippy makes sense. A stage 1 build without any flags should not build clippy even if it could be built on stage 1

[ratmice]

@oli-obk I updated the branch to set the extended condition instead of the match.
If it gets merged, by all means squash it. I imagine further cleanups (if any) to make the relationship between extended/stage more apparent could possibly be done separately?

[shepmaster]

@oli-obk do you want to take over review of this? Or should @Mark-Simulacrum still review?

[oli-obk]

Sure. Who do I ping for the final r+? Or does the bors-delegate thing work?

[oli-obk]

@ratmice I think you forgot to push your changes ;)

[kennytm]

Let's try...

@bors delegate=oli-obk

[bors]

✌️ @oli-obk can now approve this pull request

[ratmice]

@oli-obk whoops, pushed a branch on accident, should be fixed now.

[kennytm]

Compilation error. We don't have NLL in stage0 yet...

[00:01:24] Compiling bootstrap v0.0.0 (file:///checkout/src/bootstrap)
[00:01:28] error[E0382]: use of moved value: `run.builder.build.config.extended`
[00:01:28] --> /checkout/src/bootstrap/tool.rs:418:55
[00:01:28] |
[00:01:28] 418 | run.path("src/tools/clippy").default_condition(run.builder.build.config.extended)
[00:01:28] | --- value moved here ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ value used here after move
[00:01:28] |
[00:01:28] = note: move occurs because `run` has type `builder::ShouldRun<'_>`, which does not implement the `Copy` trait

[oli-obk]

Also that one missing space should be re-inserted ;)

[ratmice]

@kennytm pushed the wrong patch to the right branch this time, apparently you can create an ambiguous branch in git, and it makes things confusing. Apologies.

[oli-obk]

@bors r+

[bors]

📌 Commit aa9d0aa has been approved by oli-obk

[bors]

⌛ Testing commit aa9d0aa with merge 9acc333...