Bump rustc version to 1.22.0 #210
Conversation
|
LGTM (assuming we dont bump it again any time soon). |
|
Good by me too. |
|
It would appear that we've run into a bug with rustc, detailed here: rust-lang/rust#43613, the fix is in rust-lang/rust#44269, and merged in I personally don't mind bumping to |
|
I really do not want to go to 1.22. That will require 3 successive compile iterations to get from mrustc on 1.19, plus it's a bigger jump from 1.14. |
|
Yea, 1.22 is only what's used in rust-lightning because we don't expect to have production users for another few months, at least. 1.22 seems like a reasonable target (it's the first before the fancy match reference assumption stuff) in a another few months, but would need to push forward rustc deterministic builds/mrustc during that time.
… On Jan 14, 2019, at 15:57, Andrew Poelstra ***@***.***> wrote:
I really do not want to go to 1.22. That will require 3 successive compile iterations to get from mrustc on 1.19, plus it's a bigger jump from 1.14.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
fcf04b2 to
5775735
Compare
|
As discussed on IRC, people are reluctantly okay with |
5775735 to
33f32be
Compare
@dongcarl I thought it could be solved by replacing strason with the current serde json crate (which needs rust >1.14, 1.20 works), but that's just a vague memory.
EDIT: found the source of the bug:
|
LGTM |
|
Guess we should bump bitcoin_hashes to 1.22 as well so we can get associated constants. |
|
Just FYI https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html |
|
I wonder if there are any plans to upgrade to edition 2018 and rustc 1.31. Current Debian stable ships 1.34. |
|
Very much no. People use these libraries in production and that would break their ability to compile them.
… On Oct 4, 2019, at 06:31, Artem Vorotnikov ***@***.***> wrote:
I wonder if there are any plans to upgrade to edition 2018 and rustc 1.31.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Why do you assume production uses rustc older than 1.31? |
|
There’s a number of reasons, notably rustc bootstrapability (ie mrustc support). However, in general, unless there’s a reason we need to force users to upgrade, why would we? Upgrading a package with a handful of commits isn’t a big lift, but upgrading your entire tool chain can be incredibly disruptive.
… On Oct 4, 2019, at 08:26, Artem Vorotnikov ***@***.***> wrote:
Why do you assume production uses rustc older than 1.31?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
One important reason is that edition 2018 has been around for quite some time and many potential contributors are already used to it. Staying with edition 2015 means forcing them to remember obsolete idioms (like |
|
@vorot93 I don't think the edition is a big issue. I use both in between different projects. Those tiny verbosities we have here are catched by CI. New contributors that contribute real code and forget some small verbosities can very simply be notified of such by CI or other contributors interpreting CI. No biggie. Those are really minor annoyances compared with having to either stay on an old rust-bitcoin version because you can't support an older Rust version or being forced to upgrade your toolchain while you don't want to. |
|
Potential contributors need to be on-board with our commitment to stability and our need to support old (in rust time) compilers. It is inconvenient and annoying at times, but much less inconvenient and annoying than forcing our users to constantly update their toolchain. |
…zzer fix roundtrip_descriptor fuzztest
It seems from IRC conversations and other discussions that
1.20.0is an acceptable version to bump our rustc to.1.24.0, which is packaged by debian stable1.20.0This PR is now for bumping to 1.22.0