cargo rustc --version should print the version of rustc called by cargo

[lolbinarycat]

Problem

it is difficult to check if the version of rustc called by cargo and the version of rustc in the users environment are the same, either due to RUSTC or RUSTC_WRAPPER being set, or due to cargo being patched by a package manager such as nix.

Proposed Solution

when cargo rustc --version is run, cargo should invoke rustc --version following all the usual rules of how to find rustc, such as checking RUSTC and RUSTC_WRAPPER

Notes

you an kind of get the desired effect with RUSTFLAGS=--version, but it's a bit of a hack.

`cargo rustc -- --version also doesn't exist for some reason.

[weihanglo]

cargo rustc -- --version works for me. Did you get any error from that?

[lolbinarycat]

@weihanglo it works, but it also builds the project in the current dir, and it only prints the version number if the build is successful.

which is a problem, because the main reason you would want to run this is to debug issues that are causing your build to fail (in my case it was a strange problem, because just updating rustc wasn't enough, i had to also run cargo clean for the unsupported version error to go away)

[heisen-li]

but it also builds the project in the current dir, and it only prints the version number if the build is successful.

From what I understand, this seems to be a problem, and the build should not be performed if it only outputs the version.

[lolbinarycat]

From what I understand, this seems to be a problem, and the build should not be performed if it only outputs the version.

from cargo rustc --help:

Compile a package, and pass extra options to the compiler

it compiles the current package because that's what cargo rustc is supposed to do.

[weihanglo]

From reading the issue description, there seems to be two different output you want:

• Get the version info of rustc, i.e. the output of rustc -vV.
• Get the path to the rustc, i.e. the value of RUSTC, RUSTC_WRAPPER, and RUSTC_WORKSPACE_WRAPPER.

Before proposing a change to the entire Cargo team, I think we should flesh out the desired output that captures things people want. Also, rustdoc might also be bothered by the issue, so should be dealt with together.

However, before that, I'd like to have more background of situation you want to learn the rustc version. Also why cargo build --verbose + CRTL-C and read the rustc invocation didn't satisfy you, just because it's a bit hacky?

[lolbinarycat]

From reading the issue description, there seems to be two different output you want: no, just the rustc version is enough for my usecase

* Get the version info of rustc, i.e. the output of `rustc -vV`.

just the output of rustc --version would be enough for my usecase.

* Get the path to the rustc, i.e. the value of `RUSTC`, `RUSTC_WRAPPER`, and `RUSTC_WORKSPACE_WRAPPER`.

could be useful for some, but it wasn't what i had in mind, no.

Before proposing a change to the entire Cargo team, I think we should flesh out the desired output that captures things people want. Also, rustdoc might also be bothered by the issue, so should be dealt with together.

However, before that, I'd like to have more background of situation you want to learn the rustc version. Also why cargo build --verbose + CRTL-C and read the rustc invocation didn't satisfy you, just because it's a bit hacky?

only works inside of a cargo crate, also not at all obvious that would print the rust version and not just build logs.

[weihanglo]

* Get the path to the rustc, i.e. the value of `RUSTC`, `RUSTC_WRAPPER`, and `RUSTC_WORKSPACE_WRAPPER`.

could be useful for some, but it wasn't what i had in mind, no.

This somehow contradicts to what I understood. RUSTC_WRAPPER could hijack and calls into the entire different rustc. If not handle correctly, the version info might not be useful or even absent. (A slightly relevant PR https://github.com/rust-lang/cargo/pull/13659 of this).

---

Not mean to turn this down, but Cargo is cautious of adding new flags, since once they've added they stay like forever. A specialized flag for only one purpose with no interaction with other parts is unlikely to be accepted by the team.

If people want to move things forward, somebody needs to drive this with a proposal considering different parts in Cargo holistically, and with some practical use cases. See RFC 3180 for reference. Not every flag needs to go through the RFC process, but still needs a fair amount of use cases. See --output-format for cargo rustdoc as another example.

[lolbinarycat]

Not mean to turn this down, but Cargo is cautious of adding new flags, since once they've added they stay like forever. A specialized flag for only one purpose with no interaction with other parts is unlikely to be accepted by the team.

i see. i was under the impression that an isolated feature would be less likely to cause problems for other pieces of code later down the line, but i'm not the one designing toolchains.