Cargo should issue a warning when rustflags from an outer config file override rustflags from an inner config file

[PoignardAzur]

Problem

Let's say your have two .cargo/config files affecting your project:

• $HOME/.cargo/config
• $HOME/my_project/.cargo/config

Let's say these config files have conflicting rustflags values:

# $HOME/.cargo/config
[target.x86_64-unknown-linux-gnu]
rustflags = [
    "--some-flags",
]

# $HOME/my_project/.cargo/config
[build]
rustflags = [
    "--other-flags",
]

In that case, the rustflags in your local file will be overwritten by the globally-set rustflags. This is coherent with the reference, which says that target.<triple>.rustflags has a higher priority than build.rustflags and is mutually exclusive.

But it's very confusing when it happens, and it's completely different from usual cargo behavior. Usually, you expect flags you set locally to override flags in a global file.

Proposed Solution

Ideally, the way rustflags are merged between config files should be reconsidered. In practice, it might be impossible to change it without breaking changes to people's workflow.

At the very least, a warning should be issued when such collisions do occur, so that users know that flags they've set locally are being ignored.

[PoignardAzur]

(Seems related to #8128)

[robinhundt]

I just got bitten by this. I added the following

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/usr/bin/mold", "-C", "target-cpu=native"]

a while ago to my global cargo config as per the instructions of mold.

However, I had rustflags = ["-C","target-cpu=native"] in the local configuration of one of my projects, which is needed as one of the crates uses AVX2. I was very confused why this configuration was suddenly not picked up anymore. A warning would be very nice in such a case.

[nipunn1313]

I've run into a very similar scenario (mold installed in the global cargo config), overriding the [build.rustflags] configuration in my local project

Haven't fully thought this through, but I think I would prefer a behavior where

• The local config.toml follows the precedence rules of rustflags sources
• The global config.toml follows the precedence rules of rustflags sources
• The results of local/global are merged.

This might mean that [build.rustflags] settings in local get merged with [cfg.target.rustflags] settings in the global settings, but that would be desirable for this use case here.