<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 7/2/19 5:47 AM, Gregory Szorc wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAKQoGam+RwMnk9isgL8+cPkxnzYQfJumszZLFgMeFLvLuNiYaQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at 1:56
AM Raphaël Gomès <<a
href="mailto:raphael.gomes@octobus.net"
moz-do-not-send="true">raphael.gomes@octobus.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">As more and more Rust
makes its way into the Mercurial code base, the <br>
question of picking a minimum required version of Rust
becomes more and <br>
more urgent. On the one hand, staying too up to date means
breaking the <br>
install for some of our users, and staying too far behind
means creating <br>
a technical debt that only gets worse over time.<br>
<br>
Many interesting changes have happened in Rust since the
Oxidation Plan <br>
was introduced, like the 2018 edition and procedural macros:<br>
<br>
- Opting in to the 2018 edition would be a clear
benefit in terms <br>
of future proofing, new (nice to have) syntactical sugar <br>
notwithstanding. It also has a new non-lexical, non-AST
based borrow <br>
checker that has fewer bugs(!) and allows us to write
correct code that <br>
in some cases would have been rejected by the old one.<br>
- Procedural macros would allow us to use the PyO3
crate which <br>
maintainers have expressed the clear goal of compiling on
stable, which <br>
would help in code maintainability compared to rust-cpython.<br>
<br>
These are the two major features I can think of that would
be clearly <br>
beneficial and that I think should matter in determining the
target Rust <br>
version. This means that the absolute oldest rustc version
should be <br>
1.31.1, however picking the more recent 1.34.2 would be
preferable as it <br>
is of course newer, but still packaged in Debian.<br>
<br>
I can volunteer to write the patch that will port the
current 2015 <br>
edition code to 2018 and pin down the Rust version. I've
talked to <br>
gracinet, who is currently the only other contributor
writing major Rust <br>
patches, and he would be fine (could I say thrilled?) with
adapting his <br>
newer code to the 2018 edition after said patch lands.<br>
</blockquote>
<div><br>
</div>
<div>I think targeting >=1.31 makes sense in order to get
the 2018 edition. I fully support requiring the 2018
edition.</div>
<div><br>
</div>
<div>There are some compelling enhancements in >=1.32 that
would be nice to use. But I don't feel as strongly about
requiring their usage. In targeting something that is less
than the minimal version for the 2018 edition, we do
undermine the Rust edition philosophy a bit. But as Yuya
said, Rust support is still not stable, so there is some
room to more aggressively adopt Rust releases.</div>
<div><br>
</div>
<div>I agree with Yuya that targeting whatever Debian is
packaging is a good move, as Debian packages tend to impacts
a large portion of the Linux user base.</div>
<div><br>
</div>
<div>I would absolutely love to move to PyO3. But until they
stop requiring Nightly, I'm opposed to the change. Until
then, I guess we'll have to deal with Rust code that looks
like Python C code for the time being. All the more
incentive to minimize the amount of Rust code in the
Python/C interop layer and focus on writing as much
functionality in "pure" Rust as possible.<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Mercurial-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Mercurial-devel@mercurial-scm.org">Mercurial-devel@mercurial-scm.org</a>
<a class="moz-txt-link-freetext" href="https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel">https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel</a></pre>
</blockquote>
<p>FYI, PyO3 seems "close" to compiling on stable. I don't know
enough about the code base or the problem at hand (i.e. removing
specialization), but they seem pretty confident:
<a class="moz-txt-link-freetext" href="https://github.com/PyO3/pyo3/issues/210">https://github.com/PyO3/pyo3/issues/210</a>.</p>
<p>I think we are all starting to agree that using the 2018 edition
plus whatever version is the latest for Debian for now is good
enough, until we get to a less experimental stage.<br>
</p>
</body>
</html>