build rustflags and target rustflags from config are not merged together

[ItsEthra]

Problem

In cargo config file, rustflags from sections [target.<target>] and [build] cannot be used together, the one in [target.<target>] takes precedence. Though I would expect them to be allowed together. Consider this config placed in the home directory.

[target.x86_64-unknown-linux-gnu]
rustflags = [
  "--remap-path-prefix", "/home/user/.cargo=cargo"
]

[build]
rustflags = [
  "--cfg", "tokio_unstable",
]

This causes tokio_unstable cfg flag to be unset when compiling cargo project.

fn main() {
    #[cfg(tokio_unstable)]
    println!("Unstable!"); // Isn't printed
}

This doesn't happen if [target.<target>] is missing or its rustflags equal to empty array or unset.

Steps

1. Create ~/.cargo/config.toml with the following content

[target.x86_64-unknown-linux-gnu] # use proper target
rustflags = [
  "--remap-path-prefix", "/home/user/.cargo=cargo"
]

[build]
rustflags = [
  "--cfg", "tokio_unstable",
]

2. Create cargo project, cargo new foo and use this main.rs

fn main() {
    #[cfg(tokio_unstable)]
    println!("Unstable!");
}

3. After cargo r the string isn't printed.

Possible Solution(s)

Merge together rustflags from [target.<target>] and [build] sections.

Notes

I would assume this also happens to other keys such as rustdocflags. This also happens when using multiple configs, i.e. 2 configs at ~/.cargo/config.toml and project/.cargo/config.toml.

Version

cargo 1.75.0-nightly (6fa6fdc76 2023-10-10)
release: 1.75.0-nightly
commit-hash: 6fa6fdc7606cfa664f9bee2fb33ee2ed904f4e88
commit-date: 2023-10-10
host: x86_64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.3.0-DEV (sys:0.4.66+curl-8.3.0 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Arch Linux Rolling Release [64-bit]

[weihanglo]

Thanks for the report.

And yes, it is documented that build.rustflags and target.<…>.rustflags are mutually exclusive. There are issues talking about the lack of good documentations, and ways to inspect the final merged rustflags, which can make the situation a bit better but not really resolved.

#5376 is exactly the same issue and proposal as yours with some prior discussions. Let's close this and move to there :)