Environment variable RUSTFLAGS not set inside build.rs script since Rust 1.55.0

[Tirka]

Problem

Environment variable RUSTFLAGS not set inside build.rs script since Rust 1.55.0

Steps

Install Rust Stable 1.54 and 1.55

rustup install 1.54.0
rustup install 1.55.0

Clone Minimal Reproducible Example

git clone https://github.com/Tirka/rustflags-buildrs.git
cd ./rustflags-buildrs

Build with Cargo and Rust Stable 1.54.0

RUSTFLAGS="-C target-cpu=skylake" FOO="bar" cargo +1.54.0 build -vv

Output:

[rustflags-buildrs 0.1.0] RUSTFLAGS=Some("-C target-cpu=skylake")
[rustflags-buildrs 0.1.0] FOO=Some("bar")

Cargo clean

cargo clean

Build with Cargo and Rust Stable 1.55.0

RUSTFLAGS="-C target-cpu=skylake" FOO="bar" cargo +1.55.0 build -vv

Output:

[rustflags-buildrs 0.1.0] RUSTFLAGS=None
[rustflags-buildrs 0.1.0] FOO=Some("bar")

It looks like RUSTFLAGS environment variable is not available within build.rs script since 1.55.0 and I can't find any info related to this new behavior in the changelog.

Possible Solution(s)

No response

Notes

No response

Version

No response

[ehuss]

Thanks for the report, and sorry about the problem you've run into. This was changed in #9601, and I asked for clarification over there. But I'm also wondering, is it feasible for you to use CARGO_ENCODED_RUSTFLAGS? I'm not sure if your project has strict requirements for supporting older versions of cargo.

[Tirka]

Unfortunately, this change of the Cargo behavior affects 3rd party crates, which rely on RUSTFLAGS in their build.rs. (e.g., https://github.com/darrenldl/reed-solomon-erasure/blob/5fe2d8a7786ac7891cca6c1e20371a0be0c9ce82/build.rs#L164)

So, this is not a bug? Is this behavior expected?

[alexcrichton]

Following up from #9601 (comment) I'll echo what jonhoo said and otherwise add that other methods of configuring flags, e.g. build.rustflags and such, were never reflected with RUSTFLAGS and are now all reflected via the replacement. While this was a breaking change I figured it was ok since it was only "half" working before when the outer cargo invocation already happened to set the environment variable and it would be best for a guaranteed source of information instead of one that only may happen to be set.

[Eh2406]

We added it to the Changelog, both in the release where the change happened and in the release where you noticed it.
Sorry for not documenting this change when it happened. #10141