[Discussion] Updating MSRV to 1.29.0 #338
Comments
|
I'll wait to see what's up with thepowersgang/mrustc#123 but we can start talking about this. |
|
Hmm, it kinda sucks to break Debian Stretch (which is 1.24 and still supported for some time). I’m working on getting bits of rust-bitcoin into Core, and a supported distro which was latest as of only a year or so again seems well within what is required to be supported there, though Rust bits there are designed to be optional. What are other Distros’ supported releases on?
… On Nov 6, 2019, at 10:00, Elichai Turkel ***@***.***> wrote:
Hi,
I want to initiate a discussion about bumping the MSRV to 1.29.0.
It was released at 2018-09-13, which is more than a year ago.
mrustc now supports compiling it directly. so potential bootstrapping should be easy.
A non exhaustive list of important(IMHO) features:
the GlobalAlloc API is stable. meaning we can make better alignment guarantees in rust-secp256k1. (fix rust-bitcoin/rust-secp256k1#138 which also affect non preallocated ).
repr(align(N)) on types.
The Error trait is a marker on top of Display.
Closures implement Clone/Copy (see tests of #319).
u128/i128.
Duration no longer requires libstd. (rust-lang/rust#46666)
Fix cargo's CVE-2019-16760.
Ergonomics reasons (again non exhaustive):
Tests can return Result<(), E: Debug>.
dyn syntax. (shows explicitly that there's dynamic dispatch involved).
#[must_use] warning (https://github.com/rust-lang/rfcs/blob/master/text/1940-must-use-functions.md)
Inclusive range (getting rid of these warnings lol).
Nested imports (https://github.com/rust-lang/rfcs/blob/master/text/2128-use-nested-groups.md).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
That's a great question that skipped my mind. |
|
If a standard update without switching to a new major distro version results in a higher rustc (which would be weird - most distros that pin packages definitely pin compilers), I don’t think we need to worry about the currently shipping version.
Stretch is, like all Debian releases, pinned to 1.24 until it EOLs in 2020 (there are some additional updates after that point, but it becomes less and less official so dunno how much we need to worry about it).
Core has had issues with folks on CentOS in the past.
… On Nov 6, 2019, at 10:14, Elichai Turkel ***@***.***> wrote:
That's a great question that skipped my mind.
I'll try to do a survey of rust versions in distros.
Altough it's always a bit hard to differentiate between available packages and shipped ones.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Supported Distros:
RedHat and CentOS are harder to search for some reason. but checking via docker
|
|
Hmm, so minimum is definitely no lower than 1.24 (about 1.5 years old). Of your list of "wants", I'd love to see a "which version it went in", it looks like quite a few of them went in in 1.24 (except maybe NonNull, which maybe we can live without?). |
|
@TheBlueMatt updated the list. seems like non of what I listed here is less than 1.25. I looked again at https://github.com/rust-lang/rust/blob/master/RELEASES.md and couldn't find anything interesting between 1.22-1.24. Anyway. I see no good reason to bump to anything less than 1.28 (which will help me sleep better at night with the raw allocations and alignments lol). And unless you know a Debian maintainer it doesn't look like they're going to update Strech's rustc. so I guess we need to wait until it's |
|
Talked with some Debian guys. [1] http://ftp.debian.org/debian/dists/oldstable-proposed-updates/ |
|
Does oldstable-proposed-updates go into oldstable/updates or into oldstable main? Cause those are rather different things (though it also may not be worth making the distinction in our case). At a high level, making the required version something that is barely more than a year old feels super, super unhealthy, but it seems supported platforms have mostly been updating quickly. It would be nice to finally get to a point where we don't need to bump the min version so often, is there anything we want in 1.30 - 1.34 (I assume we'll at least be stuck on 1.34 for a long time, given Debian stable is currently shipping it). |
|
It does seem unhealthy in general, but I really don't expect this situation to persist very long. In 20 years maybe we'll be using 18-year-old versions of Rust without issue. |
I don't know.
I agree. it seems like the reason distros are updating quickly is so they can build firefox (https://wiki.mozilla.org/Rust_Update_Policy_for_Firefox)
Anyway, the main problem is that rust is still evolving really fast. I'm not sure these changes will stop in the next year( |
|
I really really want |
|
Why do you want it so much? |
|
Looks like 1.41 hopefully rust-lang/rust#65355 |
Isn't that the point of Firefox ESR? You don't have to upgrade Rust to upgrade to the latest ESR release, no?
As long as you only need atomic_u32, AtomicUsize should suffice, no? As for the rest of the things in your list they all seem purely ergonomic, and only marginally so? I don' think anything in that list is too helpful for core, though we do really need/want GlobalAlloc, so 1.29 seems to be what we'll need for Core, too, admittedly. |
|
@elichai 3rd party void types have a ton of disadvantages (and very few advantages over just defining your own), vs one that the compiler understands. |
|
@apoelstra IIUC this is literally |
|
Apparently CentOS 7 is on 1.24 https://twitter.com/bk2204/status/1213980937744211968 and EOL isn't until 2024 https://wiki.centos.org/Download |
weird. this says otherwise: https://pkgs.org/download/rust |
|
FWIW it looks like bitcoin core requires the EPEL repositories in CentOS too (which currently contain rust 1.40 even for CentOS 7) |
|
That's just the CI scripts, though, no? Did you actually test building Core without them? |
I was trying to word it as maybe but I guess that didn't come out as I wanted heh. |
|
FIY the whole serde ecosystem is sadly slowly climbing to MSRV 1.31 |
|
While I’m not hugely against bumping our MSRV, there’s also no reason why we can’t also require a newer rust if you want to use serde.
… On Jan 23, 2020, at 04:53, Elichai Turkel ***@***.***> wrote:
FWIW the whole serde ecosystem is sadly slowly climbing to MSRV 1.31
See: #398
#398
serde-rs/serde#1602
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
FWIW, stretch is on 1.34 now. |
|
Very relevant: #409 Requires rust 1.36.0: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1360-2019-07-04 |
|
I think it'd be reasonable to require 1.36 (or even higher) for |
|
Also a nice webpage for tracking |
|
I just stumbled over https://github.com/dtolnay/rustversion and thought I might share it here. It has trade-offs in terms of maintenance effort but could allow the library to make use of newer language features for some parts of the code without necessarily requiring every consumer to use a newer version of Rust. Now the irony is, I think that this library in itself has a MSRV of 1.31 😬 |
|
FYI, for #430 and the I also updated the main post and the distributions post: #338 (comment), the only distro we care about that is under 1.31 is CentOS 7 under the SCL repositories, I'm not a CentOS user so I don't really know the usage and difference between SCL and EPEL but rust is not included in the main repos anyway. also 1.31 is more than 1.5 years old, and mrustc supports 1.29, I can try writing a bootstrap script from mrustc to 1.31 stable if it helps |
|
Note that when bitcoin/bitcoin#18942 is merged bitcoin core will officially stop supporting compiling core in CentOS 7 |
|
I'm not in total disagreement with raising the MSRV. It think we could have a planned discussion on IRC once (or perhaps a CoreDev meeting or so) to agree on a specific version. The we can merge all our pending changes, do a release and then raise the MSRV for next releases. If we find out there are people still using version we don't support anymore, we can potentially do security patches or specific feature requests to the 1.22 branch. |
|
If we'd like to have |
|
Sadly, 1.36 is a long ways off from practical for everyday rust - if you want to do that you force a lot of distro users into rustup, which is totally unacceptable for security-conscious users. |
|
We ended up bumping MSRV for rust-lightning to 1.30, as there's a bug in 1.29 cargo which breaks compilation when you have a subcrate with an |
|
I think we could bump to 1.29 today. Going all the way to 1.31 is tempting -- it would require mrustc users to do two more compilations of the compiler (which is actually better than the situation we had back when we moved to 1.22, when mrustc was at 1.19) -- and it would give us basic access to Rust 2018. |
|
I personally don't think that the ability to bootstrap is very relevant because I doubt that users do this in practice. And since I don't write a lot of Rust code I don't feel competent enough to judge whether it's worth to bump to a particular version, so I'm happy with whatever people here agree on. |
|
For the record, Debian stable now contains |
|
1.41.1 is not even a year old, and mrustc only supports 1.29. |
|
Didn't want to imply we should update MSRV right now. :) Just hope it's not too far away. Async/await would be very nice. |
|
Definitely :) though unfortunately it may be quite a difficult thing for mrustc to support. |
|
I think |
|
Rustc needs generators anyway (in rustc_interface), so implementing async/await should by a matter of just desugaring it to a generator like rustc does. |
|
Oh nice, that's an encouraging observation. |
|
mrustc now supports 1.39.0 |
|
@devrandom: MSRV bump is already sort of WIP - pls check #510 (comment) |
Hi,
I want to initiate a discussion about bumping the MSRV to 1.29.0.
A non exhaustive list of important(IMHO) features:
GlobalAllocAPI is stable. meaning we can make better alignment guarantees inrust-secp256k1. (fix Pre-allocation and alignment rust-secp256k1#138 which also affect non preallocated ). [1.28]repr(align(N))on types. [1.25]Errortrait is a marker on top ofDisplay. [1.27]u128/i128. [1.26]Durationno longer requires libstd. (Move Duration to libcore rust-lang/rust#46666) [1.25]NonNullpointer. [1.25]slice::align_to[1.30]Ergonomics reasons (again non exhaustive):
Result<(), E: Debug>. [1.28]dynsyntax. (shows explicitly that there's dynamic dispatch involved). [1.27]#[must_use]warning (https://github.com/rust-lang/rfcs/blob/master/text/1940-must-use-functions.md) [1.27]Important features for allowing dependencies:
cratekeyword (used byccandryu). [1.30]cc,ryu,serde_derive) [1.31]to_be_bytefunctions (used bybase64(Add MessageSignature type for dealing with signed messages #413)) [1.32]TryIntotrait (used bybase64(Add MessageSignature type for dealing with signed messages #413)) [1.34]The text was updated successfully, but these errors were encountered: