Maintain compatibility with Rust 1.25

[azriel91]

Issue #135

Not sure if you want to also include a CI config for Rust 1.18

[azriel91]

Implementation is incorrect for detecting rust features, shall find another way.

---

Pulled in the autocfg crate as a build dependency to do this, detects the compiler version instead of features though – can't find how to detect compiler features. Let me know if you prefer to go lower level and use rustc_version and do the version check in build.rs

[RalfJung]

Not sure if you want to also include a CI config for Rust 1.18

I think that would be a good idea.

[azriel91]

Ah, 1.18.0 built on windows, but not linux. I'm off for tonight, but feel free to add to the branch if it's urgent.

[alexcrichton]

This is unfortunately a bit too much code duplication for me to be comfortable maintaining purely for the reason of supporting older compilers. Is there a compelling reason to support 1.18.0?

[azriel91]

Hm, besides "make the failure PR pass", I think that's better answered by @BurntSushi

[BurntSushi]

I've honestly lost a lot of my own motivation for tracking older Rust releases. It is too much work, and in particular, is completely intractable without community consensus on what to do. I think we should at the very minimum put a specific Rust version in our CI config so that folks can at least know which version is supported though.

[RalfJung]

error_len is stable since Rust 1.20. Assuming that this removes most of the need for code duplication, would it be okay for failure to bump its minimal version to 1.20?

[alexcrichton]

Heh to add to what @BurntSushi says I've also lost motivation to even list the minimum Rust version in CI, all it ends up doing for me is making it annoying to land PRs that bump it (as you always forget about it) and also confusing contributors who aren't typically aware that it can be bumped.

It looks like the main duplication here is happening at the rust 1.25.0 boundary, so it seems fine to me to land whatever's necessary to support 1.25.0+ as it likely doesn't involve much duplication

[RalfJung]

Oh dang I missed the repr(align) thing and that it requires Rust 1.25.

[azriel91]

Okay, so with 1.25.0 as the minimum, things are much easier!
Actually many times when Rust releases a new stable version, I think "wow, this should be the minimum stable" 😅.

[alexcrichton]

Hm what's going on here? Was this something we moved from std to core in the last few versions?

[azriel91]

Yeap, based on issue rust-lang/rust#49319 and the corresponding PR: rust-lang/rust#49698 which happened on 2018-04-12, which is just after Rust 1.26 was released.

[alexcrichton]

Looks great to me! Just one thing I'm curious about, and it also looks like CI may be failing for 1.25.0? (I don't think std has c_void by that point)

[azriel91]

Yeap, took longer than I'd've liked to figure out that no_std support isn't able to be supported until Rust 1.30. I've updated the CI config to test the features with std, though it duplicates nearly all of the main script. Yaml doesn't have a standard merge syntax (probably for good reason).

[azriel91]

So, the "gimli-symbolize" feature transitively uses the parity-wasm crate (backtrace -> addr2line 0.7 -> object 0.9 -> parity-wasm 0.31.3).

parity-wasm makes use of auto dereferencing match patterns introduced in Rust 1.26.

Road from here, things that I'd consider unfeasible (maintenance cost, sanity):

• Chase down every crate and make it backward compatible
• Track down Rust compatibility for every dependency and introduce Rust version checks for each.

I've removed it from the 1.25 CI tests.

[alexcrichton]

Thanks so much!