[Oxidation Plan] Choosing a target Rust version and edition

Georges Racinet georges.racinet at octobus.net
Mon Jul 1 10:06:03 EDT 2019

On 7/1/19 2:57 PM, Yuya Nishihara wrote:
> On Mon, 1 Jul 2019 10:32:34 +0200, Raphaël Gomès wrote:
>> As more and more Rust makes its way into the Mercurial code base, the 
>> question of picking a minimum required version of Rust becomes more and 
>> more urgent. On the one hand, staying too up to date means breaking the 
>> install for some of our users, and staying too far behind means creating 
>> a technical debt that only gets worse over time.
>> Many interesting changes have happened in Rust since the Oxidation Plan 
>> was introduced, like the 2018 edition and procedural macros:
>>      - Opting in to the 2018 edition would be a clear benefit in terms 
>> of future proofing, new (nice to have) syntactical sugar 
>> notwithstanding. It also has a new non-lexical, non-AST based borrow 
>> checker that has fewer bugs(!) and allows us to write correct code that 
>> in some cases would have been rejected by the old one.
>>      - Procedural macros would allow us to use the PyO3 crate which 
>> maintainers have expressed the clear goal of compiling on stable, which 
>> would help in code maintainability compared to rust-cpython.
>> These are the two major features I can think of that would be clearly 
>> beneficial and that I think should matter in determining the target Rust 
>> version. This means that the absolute oldest rustc version should be 
>> 1.31.1, however picking the more recent 1.34.2 would be preferable as it 
>> is of course newer, but still packaged in Debian.

Let me add for people that aren't familiar with Rust development that
switching version while using the regular day-to-day tools (rustup) is
very easy. The question is mostly what is acceptable for passerbys and
distro packagers.

> Since Rust modules are highly experimental, I don't think it's important
> to support quite old rustc versions at this point. Maybe supporting two or
> three major versions should be enough.
> Personally, I'm okay with any recent rustc version which is packaged for
> Debian sid.

A good criterion in my opinion would be to work with the version that
ends up in Debian 10 (buster), the reason being that it would open the
way to have an oxidized Mercurial in buster-backports if we manage to
have it in the next (Debian 11) testing.

>> I can volunteer to write the patch that will port the current 2015 
>> edition code to 2018 and pin down the Rust version. I've talked to 
>> gracinet, who is currently the only other contributor writing major Rust 
>> patches, and he would be fine (could I say thrilled?) with adapting his 
>> newer code to the 2018 edition after said patch lands.

I do have a topic for edition 2018, but it covers only what I wrote as
of last January. I'll hand it over to you, Raphaël, as a starting point.

I'm not sure about hard pinning the version: rustc is pretty good at
backwards compatibility, and I wouldn't want to make life of other
distro packagers more difficult for no good reason. I expect Fedora,
Arch etc to be ahead of Debian for instance. I'd be more in favor of
announcing an official minimal supported version (that would be enforced
by some CI in an ideal world), and that's also something that the
edition marker does (with 1.31).

I don't think it's reasonable to stick on 1.31.1, though, I'm even
surprised that our current code does seem to build with that version
(just checked on 6a3872e34503). Some of Raphaël's topics might already
require a more recent one.

To wrap it up here's my practical conclusion : let's switch to edition
2018, and see what happens next. I will be in favor of jumping to the
version of Debian 10 as soon as we actually need it.

Note: rust-cpython stable Travis builds run with rustc 1.25. Wouldn't
say I like it, but thanks to the CI, I couldn't miss it – had to adapt
some of my tests.


> +1 for the removal of extern crate.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Georges Racinet
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190701/fd944da4/attachment.sig>

More information about the Mercurial-devel mailing list