Tracking issue for -Z features=host_dep

[ehuss]

Implementation: #7820
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features

Summary
-Z features=host_dep causes the feature resolver to prevent features enabled on build dependencies or proc-macros from being enabled for normal dependencies. For example:

[dependencies]
log = "0.4"

[build-dependencies]
log = {version = "0.4", features=['std']}

When building the build script, the log crate will be built with the std feature. When building the library of your package, it will not enable the feature.

Unresolved issues

• Update cargo metadata
• Does this cause existing projects to fail?
  • Projects can add missing features as a backwards-compatible workaround. However, if it causes problems for too many projects, we may need to find some way to opt-in.
• Does this significantly increase build times?
  • This can cause common dependencies to be built multiple times, when they were previously shared (when --target is not used). Projects can add features to re-unify if they want, but it may not be clear or obvious what to add and when. We may need something that identifies these duplicate dependencies, and give suggestions on how to unify them. Or, we may need to make this opt-in somehow so the user needs to make this an explicit decision.
• Does the feature resolver need to support decoupling of shared proc-macro dependencies?
  • Currently this isn't possible because Cargo does not have the necessary information to know which dependencies are proc-macros during resolution time. Either we would need to add the proc-macro status to the index, or try to do feature resolution while dependencies are downloaded. The latter is very difficult due to the way downloading works. The former isn't too hard. Nobody has asked for this ability, so it is unclear how important it is. Presumably that is because proc-macros are relatively new, and tend to only use proc-macro-specific dependencies like syn/quote.
  • Implemented in Re-implement proc-macro feature decoupling. #8028.

[Amanieu]

Does the feature resolver need to support decoupling of shared proc-macro dependencies?

Yes please. I've encountered an issue related to this already when a proc-macro enabled many features in the rand crate which caused my build to fail since my target does not have std. See rust-lang/hashbrown#124 for details.

[valarauca]

Does the feature resolver need to support decoupling of shared proc-macro dependencies?

Seeing as #4866 was about proc-macro's it does seem to be in demand. Also could #4866 be re-opened as #7820 doesn't address it?

[tarcieri]

UPDATE: never mind, this is a red herring. the proc macro itself was referencing std, because I forgot to disable its std feature 😅. With the std feature it works, but I can see how this could come up in dependency-laden proc macros that activate the std feature in dependencies shared by the proc macro.

I just ran into the proc macro problem trying to use displaydoc in a no_std project:

$ cargo build -Z features=build_dep --no-default-features --target thumbv7em-none-eabihf --release
error[E0433]: failed to resolve: use of undeclared type or module `std`
 --> rust/src/error.rs:7:30
  |
7 | #[derive(Copy, Clone, Debug, Display, Eq, PartialEq)]
  |                              ^^^^^^^ use of undeclared type or module `std`

It would definitely be super duper handy to be able to use proc macros that link against std in no_std targets, and also to ensure there's some open issue tracking it until it's fixed.

Seeing as #4866 was about proc-macro...

@valarauca it looks like some people discussed proc macros in the comments, but #4866 itself was about build-dependencies

Perhaps it's worth opening a new issue?

[ia0]

I would also be interested in having -Z features=build_dep work with proc-macro. I would use it for the data-encoding-macro crate.