Vendoring broken with stable rustc

[bjorn3]

I tried to enable vendoring in config.toml and then following the instructions given by ./x.py.

I expected to see this happen: All dependencies are vendored.

Instead, this happened:

$ ./x.py build
error: vendoring required, but vendor directory does not exist.
       Run `cargo vendor --sync ./src/tools/cargo/Cargo.toml --sync ./src/tools/rust-analyzer/Cargo.toml --sync ./compiler/rustc_codegen_cranelift/Cargo.toml --sync ./src/bootstrap/Cargo.toml ` to initialize the vendor directory.
Alternatively, use the pre-vendored `rustc-src` dist component.
[...]
$ cargo vendor --sync ./src/tools/cargo/Cargo.toml --sync ./src/tools/rust-analyzer/Cargo.toml --sync ./compiler/rustc_codegen_cranelift/Cargo.toml --sync ./src/bootstrap/Cargo.toml
error: failed to load manifest for workspace member `/home/gh-bjorn3/rust/library/std`

Caused by:
  failed to parse manifest at `/home/gh-bjorn3/rust/library/std/Cargo.toml`

Caused by:
  the cargo feature `public-dependency` requires a nightly version of Cargo, but this is the `stable` channel
  See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
  See https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency for more information about using this feature.

To work around this, I need to explicitly use a nightly cargo.

Meta

Caused by #111076 enabling the public-dependency unstable cargo feature.

[bjorn3]

This also broke the rust-analyzer config as rust-analyzer fetches the workspace layout using the default toolchain which for most users is stable.

[jyn514]

can we override the cargo that rust-analyzer uses? we should use the beta toolchain for consistency.

[bjorn3]

I can't find any configuration for that.

[jyn514]

ok. i think we should consider reverting #111076. @notriddle why did you need a new cargo feature to make that PR work?

[notriddle]

So, how are people going to dogfood unstable Cargo features before they get stabilized if rust-analyzer breaks on it?

In any case, I used an unstable Cargo feature because I wanted to use the private dependency metadata in the rlib, and that means Cargo needs to actually mark the dependency as private, and that means Cargo.toml needs to communicate this information to Cargo.

[bjorn3]

In any case, I used an unstable Cargo feature because I wanted to use the private dependency metadata in the rlib, and that means Cargo needs to actually mark the dependency as private, and that means Cargo.toml needs to communicate this information to Cargo.

As a hack you could handle marking deps as private and public in src/bootstrap/bin/rustc.rs.

[Be-ing]

I am stumbling over this too.

I can't find any configuration for that.

So is the only workaround rustup default nightly?

[bjorn3]

You can also put +nightly between cargo and vendor to override the toolchain to use for just a single call. I'm not aware of any other workaround than using nightly or using the unstable RUSTC_BOOTSTRAP with a recent enough stable/beta cargo.

[onur-ozkan]

This is no longer a problem since #120096 I think?

[bjorn3]

Does that also add RUSTC_BOOTSTRAP=1 to the vendor command shown by x.py?

[onur-ozkan]

$ ./x.py build
error: vendoring required, but vendor directory does not exist.
       Run `cargo vendor --sync ./src/tools/cargo/Cargo.toml --sync ./src/tools/rust-analyzer/Cargo.toml --sync ./compiler/rustc_codegen_cranelift/Cargo.toml --sync ./src/bootstrap/Cargo.toml ` to initialize the vendor directory.
Alternatively, use the pre-vendored `rustc-src` dist component.
[...]
$ cargo vendor --sync ./src/tools/cargo/Cargo.toml --sync ./src/tools/rust-analyzer/Cargo.toml --sync ./compiler/rustc_codegen_cranelift/Cargo.toml --sync ./src/bootstrap/Cargo.toml

Oh wait, I didn't see the manually invoked cargo part.