Implement cfg-based target-specific dependencies

[alexcrichton]

This commit is an implementation of [RFC 1361][rfc] which is an extension of
Cargo's target section in Cargo.toml to allow the use of #[cfg]-like
expressions for target-specific dependencies. Now that the compiler has been
extended with --print cfg each invocation of Cargo will scrape this output and
learn about the relevant #[cfg] directives in play for the target being
compiled. Cargo will then use these directives to decide whether a dependency
should be activated or not.

This should allow definition of dependencies along the lines of:

[target.'cfg(unix)'.dependencies]
[target.'cfg(target_os = "linux")'.dependencies]
[target.'cfg(windows)'.dependencies]

Which is much more ergonomic and robust than listing all the triples out!

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Note that this will require rust-lang/rust#31278 to land first to get the CI/tests to pass, but I figured I'd at least put this up for review?

r? @brson or @wycats

[durka]

This will be great. Maybe we can knock winapi off the most popular crates list!

[brson]

This only supports a subset of Rust's attribute syntax. In particular, it doesn't support the 'list' meta item type, instead hardcoding 'all', 'not', and 'any'. ISTM that we should keep them at parity and support the same grammar in both places.

[alexcrichton]

Ah that's because right now Rust doesn't actually allow #[cfg] directives defined by the platform to take the form of list meta items. I believe the syntax accepted here is the same as any valid #[cfg] attribute in Rust.

Would you prefer that the grammar itself is represented the same way, though, and then there's a pass afterwards to make sure it's a valid meta item by parsing but error'ing on strings like foo(bar)?

[bors]

☔ The latest upstream changes (presumably #2370) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

Two more notes I have since realized:

• When using a newer Cargo with an older Compiler, we won't be able to learn about --print cfg, so these new kinds of target-specific dependencies won't work. Cargo will just always return false indicating that the dependencies are not applicable, but there's also in theory room to do something like emit a warning.
• Various #[cfg] lines sometimes get out of hand and are split across multiple lines, but the syntax here does not support that. TOML only allows keys to be defined on one line.

[bors]

☔ The latest upstream changes (presumably #2387) made this pull request unmergeable. Please resolve the merge conflicts.

[brson]

@bors r+

[bors]

📌 Commit f5d786e has been approved by brson

[bors]

⌛ Testing commit f5d786e with merge 4739ba1...

[bors]

☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64

[lilianmoraru]

Would of been nice if this syntax was supported on all of the options...
Example:

[workspace.'cfg(target_os = "linux")']
#...

# Example for the Cargo.toml present in the Rust source "rust/src/Cargo.toml"
[profile.release.'cfg(windows)']
opt-level = 2

[dependencies.'cfg(windows)']
winapi = "0.2"

[dev-dependencies.'cfg(target_os = "linux")']
libfuzzer-sys = { git = "https://github.com/rust-fuzz/libfuzzer-sys.git" }