Georges Racinet <gracinet@anybox.fr> [Thu, 06 Dec 2018 16:34:22 +0100] rev 40967
rust-cpython: build via HGWITHRUSTEXT=cpython
The existing behaviour, building the direct ffi bindings if
HGIWTHRUSTEXT is just set is unchanged, but if HGWITHRUSTEXT is
cpython, then the cpython bindings (aka mercurial/rustext.so) are
built.
Differential Revision: https://phab.mercurial-scm.org/D5436
Georges Racinet <gracinet@anybox.fr> [Thu, 06 Dec 2018 16:23:20 +0100] rev 40966
rust: better treatment of cargo/rustc errors
Differential Revision: https://phab.mercurial-scm.org/D5435
Georges Racinet <gracinet@anybox.fr> [Mon, 03 Dec 2018 06:52:17 +0100] rev 40965
rust-cpython: start cpython crate bindings
This changeset introduces the hg-cpython crate,
that compiles as a shared library holding a whole
Python package (mercurial.rustext), with only the empty
'ancestor' submodule for now.
Such bindings will be easier and safer to develop and maintain
that those of `hg-direct-ffi`.
They don't involve C code, only unsafe Rust that's mostly isolated
within the cpython crate.
The long-term goal would be to import the provided modules, such
as rustext.ancestor with mercurial.policy.importmod, same as
we already do with cext modules.
Differential Revision: https://phab.mercurial-scm.org/D5434
Georges Racinet <gracinet@anybox.fr> [Mon, 03 Dec 2018 06:54:19 +0100] rev 40964
rust-cpython: exclude hgcli from workspace
hgcli uses a specific rust-cpython commit by indygreg, of which
a PR has been derived which is not merged nor released yet.
But we can't use several versions of the sys-python2.7 crate in
a single workspace: it makes for a build error. Since hgcli does not at
the time being need anything from hg-core, whereas the upcoming hg-cpython
will. So for now we're moving hgcli aside, hoping we could base all of them
on the same version of rust-cpython again in the future.
Differential Revision: https://phab.mercurial-scm.org/D5433
Boris Feld <boris.feld@octobus.net> [Fri, 14 Dec 2018 17:25:41 +0100] rev 40963
sparse-revlog: protect C code against delta chain including nullrev
For unclear reasons, some repositories include nullrev (-1). Re-computing
delta for such repo remove nullrev from all chain, so some older versions have
been creating them.
This currently raise an IndexError with the new C code doing chain slicing as
it expect all item to be positive.
Both python and C code for reading delta chain preserve nullrev, and the Python
code for chain slicing handle the case fine. So we take the safe route and make
the new C code works fine in that case.
Boris Feld <boris.feld@octobus.net> [Fri, 14 Dec 2018 17:24:44 +0100] rev 40962
sparse-revlog: handle nullrev in index_get_length
The more generic index_get method handle nullrev fine, we apply the same logic
here.
Boris Feld <boris.feld@octobus.net> [Fri, 14 Dec 2018 17:23:41 +0100] rev 40961
sparse-revlog: handle nullrev in index_get_start
The more generic index_get method handle nullrev fine, we apply the same logic
here.