Repository: rust
Issue: x.py install uses different compiler stage for extended tools than x.py dist
Labels: I-compiletime,E-mentor,E-help-wanted,T-bootstrap,C-bug

Scenario:
1. Set up config.toml with `extended = true` and `tools = ["cargo", "clippy", "rustfmt"]` and a custom prefix like `prefix = "/opt/rust-dev"`
2. Run `./x.py dist`
3. Run `./x.py install`

In the `dist` step, tools are built using the stage1 compiler and then zipped up into dist tarballs. Then, without making any changes, the `install` step rebuilds all of the tools using the stage2 compiler.

For example:
```
$ ./x.py dist
...
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.13s
Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage2 compiler (x86_64-unknown-linux-gnu)
...
Building stage1 tool cargo (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.12s
Building stage1 tool cargo-credential-1password (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Dist cargo-1.60.0-dev-x86_64-unknown-linux-gnu
        finished in 0.050 seconds
Building stage1 tool rustfmt (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Building stage1 tool cargo-fmt (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Dist rustfmt-1.60.0-dev-x86_64-unknown-linux-gnu
        finished in 0.045 seconds
Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Building stage1 tool cargo-clippy (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.09s
Dist clippy-1.60.0-dev-x86_64-unknown-linux-gnu
        finished in 0.043 seconds
```

and
```
$ ./x.py install
...
Building stage1 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.12s
Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Assembling stage2 compiler (x86_64-unknown-linux-gnu)
...
Building stage2 tool cargo (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.12s
Building stage2 tool cargo-credential-1password (x86_64-unknown-linux-gnu)
    Finished release [optimized] target(s) in 0.08s
Dist cargo-1.60.0-dev-x86_64-unknown-linux-gnu
        finished in 0.056 seconds
Install cargo stage2 (Some(TargetSelection { triple: "x86_64-unknown-linux-gnu", file: None }))
install: creating uninstall script at /workspace/rust/DD/opt/rust-dev/lib/rustlib/uninstall.sh
install: installing component 'cargo'

    cargo installed.

Building stage2 tool rustfmt (x86_64-unknown-linux-gnu)
...
```

I'm not sure whether this is intentional or a bug, but it at least feels nonintuitive. Typical software packages don't compile more things if you run `make install` right after `make all`, but rustbuild does so using a different compiler stage. As expected, the output of compiler stage1 and stage2 is the same (e.g. build/x86_64-unknown-linux-gnu/stage1-tools-bin/cargo and build/x86_64-unknown-linux-gnu/stage2-tools-bin/cargo are identical).

Is it supposed to be this way? Just building stage2 tools cargo, clippy, and rustfmt adds a few extra minutes to the `./x.py install` time.