[target.'cfg(...)'] doesn't expose all keys (like test and features)

[indygreg]

Problem

I am trying to override rustflags for my test binaries. But I don't want to do this for the normal, non-test binaries.

In theory, you can use the [target.'cfg(...)'] syntax to influence rustflags on a very granular basis. However, it appears that cfg() is missing a few keys when compiling test binaries, notably test and feature.

# Works
[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-args=-Wl,-export-dynamic"]

# Does not work - feature test fails.
[target.'cfg(feature = "build-mode-standalone")']
rustflags = ["-C", "link-args=-Wl,-export-dynamic"]

# Does not work - test not defined.
[target.'cfg(test)']
rustflags = ["-C", "link-args=-Wl,-export-dynamic"]

FWIW, --test and --cfg 'feature="build-mode-standalone"' is getting passed into rustc when building the test binaries. So something in Cargo knows about them. It appears that these values aren't getting plumbed through to cfg() evaluation.

Possible Solution(s)

I think cfg() should have access to test, feature, and perhaps other conditional keys when building test binaries.

Output of cargo version: cargo 1.43.0 (3532cf738 2020-03-17)

[indygreg]

According to https://doc.rust-lang.org/cargo/reference/config.html#target:

cfg values come from those built-in to the compiler (run rustc --print=cfg to view), values set by build scripts, and extra --cfg flags passed to rustc (such as those defined in RUSTFLAGS). Do not try to match on debug_assertions or Cargo features like feature="foo".

This clearly says that feature keys aren't supported. Sorry for missing that in the docs!

However, it does seem to imply that cargo:rustc-cfg=... lines from build scripts will get included. However, I tested this and they don't appear to work for test binaries. I do see the --cfg getting passed to rustc when building the test binary. But the value set by the build script does not seem to be in the evaluation context for [target.'cfg(...)'], seemingly contrary to what the docs say.

[alexcrichton]

Currently rustflags is not determined on a per-compilation basis, but rather an extremely coarse per-cargo-execution basis. This means it doesn't have access to any per-unit flags like features/test/etc. This has also been the source of much confusion in the past, however, so it's something that might be worthwhile trying to fix.

[tones111]

I discovered this while trying to enable source-based code coverage (rust-lang/rust#79121) for my test binaries. It would be convenient to be able to add "-Zinstrument-coverage" to RUSTFLAGS when running "cargo test" but not impact debug or release builds.

I'd initially thought this was a small oversight, but it sounds like a fix may require some architectural changes. Is this something that could be worked with some guidance, or is it a significant enough change to require an RFC?

[eholk]

I ran into this issue today. I had some code where we want to change rustflags based on what features were passed on the cargo command line. I'm already using [target.'cfg(...)'] to control rustflags for a couple of other options, since this seems to give the most flexibility in combining different sets of flags.

[golddranks]

I also ran into this issue today. Expected a cfg expression like [target.'cfg(all(target_os = "macos", target_arch = "x86_64", not(test)))'] to work, but the not(test) part gets ignored. I'm building a project for bare-metal x86 with no_std, but unit tests require std. I set some linking flags with rustflags, but I'd like to disable some of them for tests as they are incompatible with the std-requiring test runner.

[jirutka]

For me, cfg in target doesn’t work at all, neither in Cargo.toml or config.toml.

# Doesn't work, it's ignored
[target.'cfg(target_os = "linux")']
z-ng = { rustc-link-lib = ["z-ng"], rustc-cfg = ["zng"] }

# Works
[target.x86_64-alpine-linux-musl]
z-ng = { rustc-link-lib = ["z-ng"], rustc-cfg = ["zng"] }

$ rustc --print=cfg
debug_assertions
panic="unwind"
target_arch="x86_64"
target_endian="little"
target_env="musl"
target_family="unix"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_os="linux"
target_pointer_width="64"
target_vendor="alpine"
unix

[epage]

I'm proposing to the cargo team that we close this based on a discussion in a previous cargo team meeting which is covered in the This Development-cycle in Cargo: 1.77. I have the impression there isn't a sufficiently viable way of implementing support for this. Instead, we likely should focus on things like global, mutually exclusive features.