crates using unstable cargo feature `bindeps` are not buildable in docs.rs

[wada314]

Crate name

protoc-plugin-by-closure

Build failure link

https://docs.rs/crate/protoc-plugin-by-closure/0.1.6/builds/1612629

Additional details

Hello! First of all, thanks for fixing #2542 ! Thanks to this fix, I could go deeper why my crate does not build in docs.rs.
I think I found the reason, but this might be not trivial...

Background

My relatively simple crate fails to build in docs.rs.
My crate has one special thing: Using cargo's unstable feature "Artifact dependencies" in my Cargo.toml.
You don't need to know the detail about this feature. Just please remember that by enabling this feature, Cargo.toml accepts a new attribute artifact = ... in the dependencies:

[dependencies]
bar = { version = "1.0", artifact = "staticlib" }

Of course, without explicitly enabling the feature by cargo command flag (-Z bindeps), this Cargo.toml fails to compile.

docs.rs document says we can add the cargo command line flags using [package.metadata.docs.rs] table's cargo-args = ... field in my Cargo.toml, but it turned out this is not enough.

My investigation

(In my understanding) When docs.rs builds a crate, it invokes many cargo command internally, and there are 2 ways to do this:

1. Explicitly invoking the cargo command using a ::rustwide::cmd::Command struct constructed by RustwideBuilder::prepare_command() function.
2. Implicit cargo invocations done in Rustwide library code. For example, when Rustwide is preparing for the build command, it is running cargo fetch command internally.

The problem is the second case. In this case, our custom cargo command line param -Z bindeps is not passed, and it seems to be no way to do so.
This is resulting in my crate's build error even though I'm setting the cargo-args flag in my Cargo.toml.

Unresolved questions

There are another way to specify the unstable cargo flag: Using the .cargo/config.toml file. My crate contains this file too, but it seems to be ignored when Rustwide is running cargo commands. Why?

[syphar]

thank you for your investigation! it makes sense.

There are another way to specify the unstable cargo flag: Using the .cargo/config.toml file. My crate contains this file too, but it seems to be ignored when Rustwide is running cargo commands. Why?

rust-lang/rustwide#60

The file is removed before the build.

From what I see in the rustwide PR the motivation was to prevent the crate from defining the toolchain (which we still need). I could imagine a change to rustwide that would filter .cargo/config.toml file so we can keep the properties we want. The thing I don't know if this might start breaking other builds that previously only worked because we ignored .cargo/config.toml

An alternative could be to change rustwide itself to enable passing cargo args into the build preparation so we could pass our cargo_args from docs.rs metadata into it.

@GuillaumeGomez @ jyn514 I would appreciate any feedback on this.

[GuillaumeGomez]

I did pretty much nothing on rustwide, so my opinion is only that of someone who don't know how it works.

I think your second suggestion would be better:

An alternative could be to change rustwide itself to enable passing cargo args into the build preparation so we could pass our cargo_args from docs.rs metadata into it.

It allows to keep the current code working while also leaving the possibility for crate owners to add the missing cargo arguments they need inside Cargo.toml like we already do for rustdoc.