Tracking issue for -Z features=itarget

[ehuss]

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

Summary
-Z features=itarget causes the feature resolver to ignore features for target-specific dependencies for targets that don't match the current compile target. For example:

[dependency.common]
version = "1.0"
features = ["f1"]

[target.'cfg(windows)'.dependencies.common]
version = "1.0"
features = ["f2"]

When building this example for a non-Windows platform, the f2 feature will not be enabled.

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.

[est31]

Does this affect lockfiles too? As in: if this feature is enabled, will a lockfile on Windows look different from a lockfile on Linux? Or is it only affecting behaviour of the actual build?

[ehuss]

It does not affect Cargo.lock.

[johanlindfors]

This seems to work, at least for my scenario:

[target.'cfg(macos)'.dependencies]
sdl2 = { version = "0.32", features = ["bundled"]}

[target.'cfg(windows)'.dependencies]
sdl2 = { version = "0.32", features = ["bundled", "static-link"]}

Building with: cargo +nightly run -Z features=itarget

But I'm still a bit confused about the proposed solution. This clearly feels like a bug in the current feature resolver, but this fix proposes that we specify a different resolver? Or is this just a temporary solution while this fix gets merged into the "original" resolver?

[ehuss]

@johanlindfors it seems to work for me. What platform are you targeting? What did you see that made you think it isn't working? One thing, cfg(macos) is not a valid expression. It should be cfg(target_os = "macos").

Yes, there is a new resolver, it is not a "bug" per se in the current resolver. The dependency resolver still needs to resolve all platforms for a stable dependency graph. These features also need to be resolved for multiple targets independently (host and target). It may be possible to do it with the current resolver, but I think it would require a multi-pass solution, so I don't think there would be any benefit, and a lot of downsides.

[jdm]

cfg([some target_os value]) is actually a valid cfg expression in current Rust code as far as I can tell. At least cfg(unix) and cfg(windows) seem to work.

[ehuss]

unix and windows are special cases. You can read more about them here. Those are target families, whereas macos is a target os within the unix family.

[jplatte]

@johanlindfors Yes, -Z features=itarget is a temporary solution for trying out the new solver while it is still unstable. It will replace the current solver as the default if things go to plan.

[johanlindfors]

@ehuss You are right, I was using the cfg(target_os = "macos") syntax but when copying the code into the comment on github I manually "shortened" it, thinking I was being smart, turns out, as usual, that was not the case!

:)

[ehuss]

The crater run for this has finished: https://crater-reports.s3.amazonaws.com/pr-69560/index.html

There are about 9 regressions, which is a bit more than I was hoping for:

• https://github.com/FauxFaux/quad-image
• https://github.com/Leinnan/slavic_castles
• https://github.com/chrisabruce/libp2p-ios
• https://github.com/dmweis/lunar_lander
• https://github.com/plaptov/ant_sim_rs
• https://github.com/tomaka/2018-rustrush-demo
• arwa 0.1.0
• label_attribute 0.1.1
• zrs 0.1.5