(Disclaimer: it's been a good while since I've compiler hacked)
As I currently understand it, x.py's job is to download the bootstrap compiler (the most recent beta?) and run the bootstrap crate, which then handles the rest of nearly everything x.py does. (The python side may handle some early outs for some things to avoid the compiler download.)
The eventual pie-in-the-sky goal for stdlib dev at least (which doesn't need as much of a bootstrap as the compiler or core) is for cargo build to just work, given an appropriate (nightly or RUSTC_BOOTSTRAP) default cargo/rustc version. (We could even provide a rustup-toolchain.toml to have rustup manage the "bootstrap version" here.)
In the shorter term, though, perhaps we could make x runnable with rustup cargo via a cargo alias of cargo x? Or is that not possible for reasons I'm missing?
We already have the x binary and custom cargo commands are just cargo-something. So cargo-x should work right now if you rename x and it's added to PATH?
The way x is installed right now is:
cargo install --path src/tools/x
We could maybe change that to:
cargo install --path src/tools/cargo-x
[note: this is all hypothetical, I haven't actually tested any of this]
x is short and stands for "execute". It's actually kind of interesting...
/src/tools/x is a rust binary to execute /x.py from anywhere in a rust-lang/rust checkout.
/x.py is a python pseudo symlink to /src/bootstrap/bootstrap.py.
/src/bootstrap/bootstrap.py is a python script to download the bootstrap compiler and use it to build and run the rust crate /src/bootstrap, which does the actual work of managing the bootstrap process.
I'm curious in the practicality of skipping this process, and building and running the /src/bootstrap crate with a rustup managed toolchain, rather than one managed by /src/bootstrap/bootstrap.py.
Obviously the rustup toolchain has to be recent enough (I believe beta?) but that seems reasonable enough of a requirement. The part which I don't know specifically is whether the rustbuild setup gets in the way of allowing cargo x to cargo run --manifest-path src/bootstrap/Cargo.toml --all --of --the --other --flags. I suppose one could be that the build dir is set in config.toml, which wouldn't be usable in the xtask pattern.
I mean, it shouldn't really matter how "cargo-x" is implemented? That can change under the hood at any time. Cargo subcommands are literally just any old executable with a magic "cargo-" prefix.
And jyn514 has been doing some good work (e.g. #92260) to move more logic from python to rust. I think it basically just needs more people help out.
x.py now verifies the hashes of bootstrap toolchain components. This is something rustup can't do. x.py also has git submodule handling as cargo refuses to build anything inside a workspace if any git submodule part of the workspace is not yet initialized.