Historically, test-float-parse was a Python script that invoked rustc from a sysroot-under-test to compile and run various test files, and then compare their outputs against reference results computed with Python rationals.

However, #127510 rewrote the Python script into a Rust program, to be built with the sysroot-under-test and then run to perform tests against the float-parsing routines in that sysroot's standard library.

(At the time, the sysroot-under-test could have been a stage 0 sysroot with a locally-built copy of the in-tree standard libraries. But now that the stage 0 redesign has been carried out, it typically only makes sense to use/test a “staged” sysroot, i.e. stage 1 or higher.)

After #146929, test-float-parse is the only remaining user of bootstrap's Mode::ToolStd cargo mode. But that's conceptually awkward, because the Rust-based test-float-parse isn't really a “tool” (in the sense of bootstrap tools or distributed tools); it's more like an integration-test harness, or a really really big compiletest test (that is too large to sensibly run from compiletest).

One example of such awkwardness is stage numbering. Currently, doing x test test-float-parse --stage=1 correctly uses a stage 1 sysroot as the sysroot-under-test, but the resulting test-float-parse binary is treated as being a “stage 2” tool.

I think it would be good to try to remove Mode::BuildStd, and replace it with something like a Mode::StagedTest that is more suited to the task of building and running a crate with a staged compiler, for the purposes of testing its sysroot.