custom/external clippy support for bootstrapping

[onur-ozkan]

Similar to cargo, rustc, and rustfmt, this adds the support of using custom clippy on bootstrap. It’s designed for those who want to test their own clippy builds or avoid downloading the stage0 clippy.

Closes#121518

[rustbot]

r? @Kobzol

rustbot has assigned @Kobzol.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

This PR modifies config.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

[Kobzol]

PR looks good, but when I tried this locally with a stable version of clippy, it failed:

Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
There have been changes to x.py since you last updated:
[INFO] New options `build.cargo-clippy` and `build.clippy-driver` added for supporting the use of custom/external clippy
- PR Link https://github.com/rust-lang/rust/pull/129152
NOTE: to silence this warning, update `config.toml` to use `change-id = 129152` instead
Installing external clippy to stage0 sysroot.
Linting stage0 library {alloc, core, panic_abort, panic_unwind, proc_macro, std, sysroot, test, unwind} (x86_64-unknown-linux-gnu)
/projects/personal/rust/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo-clippy: error while loading shared libraries: librustc_driver-a30ca400d2857f33.so: cannot open shared object file: No such file or directory

a30ca400d2857f33 is the version from my stable toolchain.

The problem seems to be that the cargo clippy binaries from the distributed toolchains are looking for librustc_driver.so and libstd.so using relative paths, so after being copied out, it no longer works.

(venv) /pr/pe/ru/rust [custom-clippy/u]$ ldd build/x86_64-unknown-linux-gnu/stage0/bin/cargo-clippy linux-vdso.so.1 (0x00007fff52583000)
librustc_driver-a30ca400d2857f33.so => not found
libstd-52417a9a08ba8fb9.so => not found
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1c7ed6e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1c7ed69000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1c7ec82000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1c7ea57000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1c7eec6000)

The same is true for rustc, if I copy it e.g. to /tmp, it stops working.
However, if I set build.rustc, it works even with the rustc from the stable toolchain. So maybe bootstrap does something more in that case?

[onur-ozkan]

The problem seems to be that the cargo clippy binaries from the distributed toolchains are looking for librustc_driver.so and libstd.so using relative paths, so after being copied out, it no longer works.

Hmm.. I only tried it with the beta clippy and it worked fine.

The same is true for rustc, if I copy it e.g. to /tmp, it stops working.
However, if I set build.rustc, it works even with the rustc from the stable toolchain. So maybe bootstrap does something more in that case?

For rustc we are passing its path in cargo environment variable, which is not possible for clippy unfortunately.

[onur-ozkan]

@rustbot author

[bors]

☔ The latest upstream changes (presumably #129295) made this pull request unmergeable. Please resolve the merge conflicts.

[onur-ozkan]

@rustbot ready

[Kobzol]

Thank you!

@bors r+

[bors]

📌 Commit 1a991e5 has been approved by Kobzol

It is now in the queue for this repository.