Over the weekend I tested rustc 1.12.0-nightly (7ad125c4e 2016-07-11) for target x86_64-pc-windows-msvc against all crates.io using cargo-apply, without and with -Z orbit. The results where interesting, but good! The only case I can’t explain is the following:
- The failure cases were different! pre-orbit many of the failures were building the openssl crate. Post-orbit they failed building openssl-sys-extras. Why would this be?
Before/after diffs of success cases. Before/after diffs of failure cases. These are hard to read because the tool isn’t very sophisticated. The success diff is much easier to read than the failure diff because of all the openssl differences.
In the data were several weird false positives:
- codify, encoding_rs, quine, static_assert_macro - false positive network timeout
- serde/codegen/macros - weird ‘unable to update files’ errors before, ok post-orbit
- oak_runtime - failed to compile before, compiles with orbit! This was a result of the before run choosing the broken 0.3.7 and after 0.4.0.
- aho-corasick, memchr, regex-syntax, utf8-ranges - cargo panics post-orbit! Need to investigate. cargo-apply runs cargo as a library so there may be some unexpected behavior due to that, but this is quite suspicious. And indeed, a cursory run of
RUSTFLAGS=-Zorbit cargo test --releaseon the affected utf8-ranges and regex-syntax repos seem to work just fine. cc @alexcrichton weird panics in cargo-apply.
With all the openssl failures we would get significantly more coverage if openssl was installed.