profile-rustflags are not propagated to `CARGO_CFG_TARGET_FEATURE` or `CARGO_ENCODED_RUSTFLAGS`

[DouglasDwyer]

Problem

When setting flags with the profile-rustflags unstable feature (tracking issue #10271), the data is not propagated to the build script environment variables CARGO_CFG_TARGET_FEATURE and CARGO_ENCODED_RUSTFLAGS.

Steps

1. Create a new binary
2. Create a build.rs:

fn main() {
    println!("cargo:warning=Feats: {:?} Flags: {:?}", std::env::var("CARGO_CFG_TARGET_FEATURE"), std::env::var("CARGO_ENCODED_RUSTFLAGS"));
}

3. Set up Cargo.toml:

cargo-features = [ "profile-rustflags" ]

[package]
name = "profile_flags_script"
version = "0.1.0"
edition = "2021"

[profile.dev]
rustflags = [ "-C", "target-feature=+crt-static" ]

4. Call cargo run - observe that crt-static is not reported by the build script.
5. Create .cargo/Config.toml:

[build]
rustflags = [ "-C", "target-feature=+crt-static" ]

6. Call cargo clean and cargo run - observe that the build script now sees the crt-static flag, as it should.

Possible Solution(s)

No response

Notes

This issue seems very similar to #6858.

Version

cargo 1.70.0-nightly (145219a9f 2023-03-27)
release: 1.70.0-nightly
commit-hash: 145219a9f089f8b57c09f40525374fbade1e34ae
commit-date: 2023-03-27
host: x86_64-pc-windows-msvc
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:Schannel)
os: Windows 10.0.19045 (Windows 10 Home) [64-bit]

[weihanglo]

CARGO_ENCODED_RUSTFLAGS, as you read, is the merged (more precisely overriden) result of rust flags sources listed here. At this moment, the CARGO_ENCODED_RUSTFLAGS doesn't include

• profile.rustflags
• cargo rustc -- <flags>
• flags for -Zlints controlling lint levels and rules.

In the current implementation, profile-rustflags are provided directly to rustc. It isn't serialized for being reading from build script.

It sounds reasonble if Cargo reflect profile-rustflags to CARGO_ENCODED_RUSTFLAGS. The question always is, should CARGO_ENCODED_RUSTFLAGS be the source of truth of all rustflags Cargo sets for rust invocations? I don't know the implication here now.

---

@rustbot label +S-needs-team-input -S-triage +A-rustflags +A-environment-variables +Zprofile-rustflags +A-build-scripts

[DouglasDwyer]

@weihanglo, thanks for the response!

The question always is, should CARGO_ENCODED_RUSTFLAGS be the source of truth of all rustflags Cargo sets for rust invocations?

Let me provide some additional context to shed some light on the issue. I am using a library called gvox-rs which wraps a native C library. The build script which compiles the C library needs to know whether to link against the static or dynamic MSVC runtimes, and for this, it currently uses CARGO_ENCODED_RUSTFLAGS to detect whether crt-static is set. Because crt-static is not correctly reflected in the flags list with profile-rustflags, this causes linking errors for me.

[weihanglo]

I assumed you use proflie-rustflags because you only want some flags for specific profiles. Given that is an unstable feature and not reflects the correct set of flags, here is another workaround before that moves forward:

• Create an extra config.toml file, e.g. .cargo/dev.config.toml
• Put these in that config file:

  [build]
  rustflags = ["-C", "target-feature=+crt-static"]

• Run cargo b --config .cargo/dev.config.toml and you're all set.
  (Alternaitvely you can run cargo +nightly -Zunstable-options --config dev.config.toml rustc --print cfg to verify it working.)

[andreeaflorescu]

@weihanglo -Zallow-features is also not passed in CARGO_ENCODED_RUSTFLAGS when it specified as follows in the .cargo/config.toml:

[unstable]
allow-features = []

Is this the intended behavior? If not, I can also open a separate issue if you think it makes sense. I am running into a build problem because of it as the proc-macro2 crate enables the unstable feature proc_macro_span unless -Zallow-features is passed. As a workaround I am adding -Zallow-features to the build and target RUSTFLAGS, but that results in quite a lot of duplication as we have multiple target definitions.

[weihanglo]

@andreeaflorescu, your case is a bit different from this issue since unstable.allow-features is an unstable feature Cargo provides, which is a wrapper of Rustc's -Zallow-features plus Cargo its own unstable feature control. It can surely be passed in rustc as rustflags. However, it doesn't seem quite right to pass Cargo's unstable features in.