Cargo nondeterministically fails to build

[alexreg]

Successful build:

https://gist.github.com/ddb95a0dabd1697a9a836698fb97d257

Failing build:

https://gist.github.com/808ad5acb5a239671bb0f05776d4c9d2

The relevant part of my Cargo.toml file is:

[dependencies]
chrono = { version = "0.2", features = ["serde"] }
collect-mac = "0.1"
decimate = "0.1" # { version = "0.1", features = ["serde"] }
errorplate = { path = "/Users/alex/Software/rust-errorplate" }
flate2 = "0.2"
hyper = "0.9"
json-rpc = { path = "/Users/alex/Software/rust-json-rpc" }
openssl = "0.7"
serde = { version = "0.8", features = ["unstable"] }
serde_derive = "0.8"
serde_json = { version = "0.8", features = ["preserve_order"] }
timer = "0.1"
url = { version = "1.1", features = ["serde"] }
uuid = { version = "0.2", features = ["serde", "v4"] }

[replace]
"chrono:0.2.25" = { path = "../rust-chrono" }
"hyper:0.9.10" = { path = "../hyper" }
"decimate:0.1.0" = { path = "../decimate" }
"serde:0.8.15" = { path = "../serde/serde" }
"serde_derive:0.8.15" = { path = "../serde/serde_derive" }
"serde_test:0.8.15" = { path = "../serde/serde_test" }
"serde_json:0.8.3" = { path = "../serde-json/json" }
"serde_urlencoded:0.2.2" = { path = "../serde_urlencoded" }

Sometimes the build works fine, sometimes it doesn't. It seems to always fail after a cargo clean, but I'm not 100% positive. What's going on here?

[alexcrichton]

Thanks for the report! Definitely sounds quite fishy and like a bug in Cargo. Do you perhaps have a repo I could check out and reproduce as well? Maybe stripped down?

If not, could you gist a full log of RUST_LOG=cargo=trace cargo build -v for both a successful and a failing build? (ideally back-to-back)

[alexreg]

Sadly no repo is easily available, partly because it's closed-source, partly because the bug seems to rely on so many parts of code (including replaced dependencies)!

Failing build: https://gist.github.com/71dd13c00411fdba8ffbf0fab03ac335
Successful build: https://gist.github.com/46dc2b0ccdab55a4ce8784cc81c3b735

The successful one came right after the failed one.

Hope that helps. I could try creating a stripped-down repo that I could share at some point, but might not get around to it right away, so with any luck you can diagnose from this...

[alexcrichton]

Ok I think I see what's going on. In the failing logs we see:

  - chrono v0.2.25 (file:///Users/alex/Software/rust-chrono)
    - num v0.1.36
    - time v0.1.35
    - serde v0.7.15

and in the successful logs we see:

  - chrono v0.2.25 (file:///Users/alex/Software/rust-chrono)
    - time v0.1.35
    - num v0.1.36
    - serde v0.8.15

Notably it's changing what version of serde the chrono crate is linking to. @alexreg can you also gist Cargo.lock? I'm curious what's mentioned in there as well.

[alexcrichton]

Also, are the [replace] packages modified? Or are they just vendored?

[alexreg]

They're modified. I should note everything was working before some recent updates of the Rust nightly and/or serde, however.

Here's my Cargo.lock: https://gist.github.com/a3bf2058a19971a5e32ea801ef09e9a1

[alexcrichton]

Can you gist the diff from the released version of chrono?

[alexreg]

Sure, but it's probably easier if I just tell you that the differences are due to some extra primitive types I added to serde (decimals types over various integral types). Not the ideal solution I know, but it works for now.

[alexcrichton]

Hm ok. So in the lockfile chrono depends on serde 0.7. Did you correct that in the overridden version of chrono though to 0.8?

[alexreg]

Yeah. My replaced chrono is based off the Git master. Its Cargo.toml reads:

serde = { version = "<0.9", optional = true }

[alexcrichton]

Ok I've managed to reproduce locally, thanks for the info!

[alexreg]

Ah, brilliant. Keep me posted.

[alexcrichton]

Oh gee well that was an embarrassing bug!

#3220

[alexreg]

Hah, no worries! Thanks for the quick fix. Will that be in a nightly soon?

[alexcrichton]

Yeah once that's merged it'll be out in the next nightly

[alexreg]

Okay, I lie about that even: it’s still nondeterministic!

On 21 Oct 2016, at 17:22, Alex Crichton [email protected] wrote:

Yeah once that's merged it'll be out in the next nightly

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3216 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF3NLEeNljPI3lr9sYWPrEf5dABng3ks5q2Oa-gaJpZM4Kci_r.

[alexreg]

I built cargo from the branch for your fix, but the problem is still persisting. Well, rather, I’m getting the errors consistently (always) now.

Here’s the output of cargo tree: http://hastebin.com/xocuqinaru

On 21 Oct 2016, at 17:22, Alex Crichton [email protected] wrote:

Yeah once that's merged it'll be out in the next nightly

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3216 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF3NLEeNljPI3lr9sYWPrEf5dABng3ks5q2Oa-gaJpZM4Kci_r.

[alexreg]

Or maybe it is working fine… there was some crossover of cargo versions on my system, perhaps. It all looks okay now.

On 21 Oct 2016, at 17:22, Alex Crichton [email protected] wrote:

Yeah once that's merged it'll be out in the next nightly

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3216 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF3NLEeNljPI3lr9sYWPrEf5dABng3ks5q2Oa-gaJpZM4Kci_r.