Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
PoignardAzur opened this issue Mar 24, 2023 · 3 comments
Open

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

PoignardAzur opened this issue Mar 24, 2023 · 3 comments
Labels
A-configuration Area: cargo config files and env vars A-rustflags Area: rustflags C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@PoignardAzur
Copy link

PoignardAzur commented Mar 24, 2023 •
edited
Loading

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 PoignardAzur added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Mar 24, 2023
@PoignardAzur
Copy link
Author

(Seems related to #8128)

@weihanglo weihanglo added A-configuration Area: cargo config files and env vars S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. A-rustflags Area: rustflags labels Apr 20, 2023
@robinhundt
Copy link

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-configuration Area: cargo config files and env vars A-rustflags Area: rustflags C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nipunn1313 @PoignardAzur @weihanglo @robinhundt