Skip to content

Cargo config: Rustflags are concatenated in non-deterministic order #4935

@Systemcluster

Description

@Systemcluster

According to the Cargo Docs, defining rustflags in multiple target configurations concatenates them:

If several cfg and $triple targets are candidates, then the rustflags are concatenated.

However this happens in a non-deterministic order:

Using this sample .cargo/config file

[target.'cfg(target_arch="x86_64")']
rustflags = [
	"-Ctarget-cpu=x86-64",
	"-Ctarget-feature=+crt-static"
]
[target.'cfg(debug_assertions)']
rustflags = [
	"-Ctarget-cpu=native",
	"-Ctarget-feature=-crt-static",
]

and this main.rs:

#![feature(target_feature, cfg_target_feature)]

#[cfg(target_feature="crt-static")]
fn foo() -> &'static str {"yes"}
#[cfg(not(target_feature="crt-static"))]
fn foo() -> &'static str {"no"}

fn main() {
	println!("Feature enabled? {}", foo());
}

results in a different output each compilation.

PS C:\Snip> cargo run
   Compiling testproj v0.0.1-dev (file:///Snip)    
    Finished dev [unoptimized + debuginfo] target(s) in 0.57 secs
     Running `target\debug\testproj.exe`
Feature enabled? no

# <modify and save main.rs>
PS C:\Snip> cargo run
   Compiling testproj v0.0.1-dev (file:///Snip)
    Finished dev [unoptimized + debuginfo] target(s) in 0.64 secs
     Running `target\debug\testproj.exe`
Feature enabled? yes

Resolving the concatenation deterministically would surely be desirable.

I would propose resolving them in the order of appearance in the config file, and with project-local configs having precedence over those higher in the directory hierarchy.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions