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.

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

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

Closed
Systemcluster opened this issue Jan 12, 2018 · 0 comments · Fixed by #4950
Closed

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

Systemcluster opened this issue Jan 12, 2018 · 0 comments · Fixed by #4950

Comments

@Systemcluster
Copy link
Contributor

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.

alexcrichton added a commit to alexcrichton/cargo that referenced this issue Jan 16, 2018
The usage of `HashMap` in the `Config` tables introduced some nondeterminism, so
reverse that with a sort right before we pass it down to rustc. One day we'll
probably want to sort by the position where these keys were defined, but for now
a blanket sort should do the trick.

Closes rust-lang#4935
bors added a commit that referenced this issue Jan 16, 2018
Ensure `[target]` rustflags are deterministically passed

The usage of `HashMap` in the `Config` tables introduced some nondeterminism, so
reverse that with a sort right before we pass it down to rustc. One day we'll
probably want to sort by the position where these keys were defined, but for now
a blanket sort should do the trick.

Closes #4935
bors added a commit that referenced this issue Jan 17, 2018
Ensure `[target]` rustflags are deterministically passed

The usage of `HashMap` in the `Config` tables introduced some nondeterminism, so
reverse that with a sort right before we pass it down to rustc. One day we'll
probably want to sort by the position where these keys were defined, but for now
a blanket sort should do the trick.

Closes #4935
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant