Allow cargo rustc -- ... for crates with both libs and binaries without needing to "filter"

[azerupi]

At the moment you can't run cargo with specific rustc arguments, like cargo rustc -- -Z no-trans on a crate that contains both a library and a binary. Cargo responds that you should filter the target by using --lib or --bin

extra arguments to rustc can only be passed to one target, consider filtering
the package by passing e.g. --lib or --bin NAME to specify a single target

Why does this limitation exist?

When creating binary crates I often tend to write the core logic in a library in the same crate. This limitation prevents me from running cargo-check on my crates using the linter-rust plugin in Atom for example.

A better way to handle this is would be to have the same behavior as cargo build

[alexcrichton]

cargo build builds everything, whereas cargo rustc only builds one target. If you have multiple targets, you need to disambiguate with extra flags.

[azerupi]

Yes, that's what I consider to be the issue. Why can't the default behavior not be "build everything" instead of fail?

If you want to filter you could still use --lib and --bin like it is currently required.

[alexcrichton]

Right, but that's precisely what cargo rustc is not. It is chartered as building one and only one target.

[azerupi]

Could you give a compelling reason behind this limitation? :)

The only reason I can see currently for not implementing this is because it would make Cargo more complex. But as cargo build already has the necessary implementation, I figure it should not be that hard to adapt it for this.

As I see it currently it wouldn't break anything to expand cargo rustc to build everything. For crates with one target it would still build that one target, and for crates with multiple targets there would finally be a way to pass custom arguments to rustc for the whole crate.

And this could be useful for better cargo integration in other tools (build tools, IDEs, ...)

[alexcrichton]

Cargo doesn't know what's getting passed to the compiler, so it has no idea if the compiler actually generates an appropriate output. As a result it can't know whether the binary in this case can actually depend on the library because the library may not be generated with a special set of flags.

[azerupi]

Ok, now I see. Thanks for the reply :)

I guess I will have to wait for a native cargo check implementation that builds the whole crate to benefit from the shorter "compile" times then. 😉

[alexcrichton]

Ok, in that case I'll close in favor of that, thanks for the report though!