To clarify something, I'm suggesting this not because it fundamentally changes the behavior of the Rust compiler, (though I can imagine ways the compiler's behavior would benefit from it being done pervasively), but rather because doing so provides much more hygiene in the build tool and avoids ever conflating a build for the system you're running on with a build for the system you're targeting even if they happen to be building for the same Rust target.
I personally would, yes. You already know what the desired target platform is (based on prior invocation of config.guess if not supplied as an argument), and if you tell rustc explicitly, you avoid depending on whatever rustc's own default might theoretically be. You could also export both RUSTC and HOST_RUSTC (names naturally subject to bikeshedding; I'm ), so that if a user needs to build a proc macro or build script or something else intended to run on the system they're building on, they have a separate tool with which to do so. (Likewise, RUSTFLAGS needs a different version for host and target, even if they're the same, because the desired flags might not be the same. This is something that'd be desirable to work out for Cargo.)
As one of many potentially interesting possibilities: consider a system that happens to have two architectures installed, such as 32-bit i686 and 64-bit x86_64. Suppose the user invokes your build system expecting to build for 32-bit, but happens to have a 64-bit rustc installed. (Suppose they're building a very large program, and they need a 64-bit tool to avoid running out of address space.) That 64-bit rustc may know how to build 32-bit binaries, but it might default to the same architecture it was built for. But if you're invoking the build script in 32-bit mode, you likely want to do your build for a 32-bit target unless you specify otherwise. In particular, if you do have a 32-bit C compiler installed but don't have a 32-bit Rust compiler installed, I think the most useful behavior is to build for 32-bit anyway, rather than building incompatible object files and then giving inscrutable errors when trying to link them together. The architecture rustc happens to be compiled for is an implementation detail that shouldn't determine your target unless you have no better means to determine what target you want to compile for.
rustc doesn't care what name it gets invoked by:
/tmp$ cat hello.rs
fn main() {
println!("Hello world");
}
/tmp$ ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc hello.rs -o hello && file hello && ./hello
hello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e767329f8afa26862a973c0bd052bfc2aa52d961, for GNU/Linux 3.2.0, with debug_info, not stripped
Hello world
/tmp$ bash -c 'exec -a i686-unknown-linux-gnu-rustc ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc hello.rs -o hello' && file hello && ./hello
hello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e767329f8afa26862a973c0bd052bfc2aa52d961, for GNU/Linux 3.2.0, with debug_info, not stripped
Hello world
/tmp$ bash -c 'exec -a some-unknown-target-rustc ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc hello.rs -o hello' && file hello && ./hello
hello: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e767329f8afa26862a973c0bd052bfc2aa52d961, for GNU/Linux 3.2.0, with debug_info, not stripped
Hello world
(exec -a sets the program name, so it's useful to test running a program as if invoked by a different name.)
I have a hard time imagining a benefit to prefixing rustc with a target, unless it was just to work around a build system that can't deal with a toolchain that supports multiple targets. And if that were the reason, I'd just suggest producing tiny wrapper scripts that invoke the compiler with appropriate arguments. But ideally, I'd instead prefer to have the build system understand how to invoke the Rust compiler for different targets.
| 
mcy: