Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo -C dir does not use the rust-toolchain.toml file within the given directory. #11957

Open
mikeleany opened this issue Apr 11, 2023 · 2 comments
Labels
A-rustup Area: rustup interaction C-bug Category: bug S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@mikeleany
Copy link

Problem

Issue #10098 requested the addition of the -C <DIR> flag. This flag was added in #10952, which closed #10098. However, using the -C flag does not use the rust-toolchain.toml file from the given directory.

For context, see this note from issue #10098:

Regarding rustup and rust-toolchain.toml overrides, I'm inclined to say rustup should honor this flag as well and interpret it prior to locating an override file. The idea here is that saying cargo -C $path … should behave indistinguishably from running cargo within that path.

Steps

  1. Run the following commands:
rustup default beta # since `-C` isn't released on stable yet
cargo new use-nightly
  1. Create use-nightly/rust-toolchain.toml with the following contents:
[toolchain]
channel = "nightly"
  1. Check the version of cargo being used with the -C option vs cd command and note the difference:
$ (cd use-nightly && cargo --version)
cargo 1.70.0-nightly (0e474cfd7 2023-03-31)
$ cargo -C use-nightly --version
cargo 1.69.0-beta.6 (713164a40 2023-03-26)
  1. If you want to take this one step further, try using a nightly-only feature within the use-nightly directory. With -C it will fail, but with cd use-nightly && cargo build it should succeed.

Possible Solution(s)

No response

Notes

I'm not sure how practical it is to actually fix this issue, but wanted to call attention to it, especially since fixing this after it reaches the stable channel could break things for anyone who might depend on the current behavior.

If it is practical, and someone could point me toward the relevant code, I would be happy to work on fixing this myself.

Version

cargo 1.69.0-beta.6 (713164a40 2023-03-26)
release: 1.69.0-beta.6
commit-hash: 713164a40962a0a76c7f3ad8aafb6f03410e21d2
commit-date: 2023-03-26
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Pop!_OS 22.04 (jammy) [64-bit]
@mikeleany mikeleany added the C-bug Category: bug label Apr 11, 2023
@mikeleany mikeleany changed the title cargo -C dir does not use the toolchain.toml file within the given directory. cargo -C dir does not use the rust-toolchain.toml file within the given directory. Apr 11, 2023
@weihanglo weihanglo added the A-rustup Area: rustup interaction label Apr 11, 2023
@weihanglo
Copy link
Member

As you've pointed out, this is something related to cargo proxy in rustup. Cargo itself doesn't read stuff from rust-toolchain.toml. But yes, it is a bit confusing for users not familiar with the relationship between rustup and cargo, and I believe the majority of Rust developers don't know that. (It should be a implementation detail in general to me)

Simliar issue #11036.

@ehuss
Copy link
Contributor

ehuss commented Apr 12, 2023

Thanks for the report! The cargo team discussed this and have decided to mark -C as unstable (#11960) to give more time to make a decision on this.

bors added a commit that referenced this issue Apr 12, 2023
Change -C to be unstable

Due to #11957, we have decided to change `-C` to be unstable to give us some more time to decide on how it should behave.
@weihanglo weihanglo added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Apr 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rustup Area: rustup interaction C-bug Category: bug S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

3 participants