rust: core implementation for lazyancestors
Once exposed through appropriate bindings, this
should be able to replace ancestor.lazyancestors
entirely.
Differential Revision: https://phab.mercurial-scm.org/D5440
rust-cpython: binding for AncestorsIterator
It's now reachable from Python as
rustext.ancestor.AncestorsIterator
Tests are provided in the previously introduced
Python testcase: this is much more convenient
that writing lengthy Rust code to call into Python.
Differential Revision: https://phab.mercurial-scm.org/D5439
rust-cpython: implement Graph using C parents function
We introduce the `Index` struct that wraps the C index. It is
not intrinsically protected by the GIL (see the lengthy
discussion in its docstring). Improving on this seems
prematurate at this point.
A pointer to the parents function is stored on the parsers
C extension module as a capsule object.
This is the recommended way to export a C API for consumption
from other extensions.
See also: https://docs.python.org/2.7/c-api/capsule.html
In our case, we use it in cindex.rs, retrieving function
pointer from the capsule and storing it within the CIndex
struct, alongside with a pointer to the index. From there,
the implementation is very close to the one from hg-direct-ffi.
The naming convention for the capsule is inspired from the
one in datetime:
>>> import datetime
>>> datetime.datetime_CAPI
<capsule object "datetime.datetime_CAPI" at 0x
7fb51201ecf0>
although in datetime's case, the capsule points to a struct holding
several type objects and methods.
Differential Revision: https://phab.mercurial-scm.org/D5438
pull: fix inconsistent view of bookmarks during pull (
issue4700)
I had a share where a pull apparently pulled a bookmark but not the
revision pointed to by the bookmark, which I suspect is due to this
(and if not, we might as well remove known issues in this area).
I do this by combining doing all the queries that could read the
bookmarks in one round trip.
I had to change the handling of the case where the server doesn't
support the lookup query, because if it fails, it would otherwise make
fremotebookmark.result() block forever. This is due to
wireprotov1peer.peerexecutor.sendcommands's behavior (it fills a
single future if any query fails synchronously and leaves all other
futures unchanged), but I don't know if the fix is to cancel all other
futures, or to keep going with the other queries.
Differential Revision: https://phab.mercurial-scm.org/D5449
merge: modify the logical statement
Differential Revision: https://phab.mercurial-scm.org/D5476
lfs: convert to using exthelper to wrap functions
I'm not 100% sure that upgraderequirements() can be double annotated safely, but
it seems OK based on printing the address of the function being wrapped.
One thing I've noticed is that @eh.reposetup doesn't do the usual check to
ensure that it's a local repo. Should that be baked into @eh.reposetup()
somehow, possibly with a non-default option to skip the check? It seems like a
gaping hole if every function that gets registered needs to add this check.
tests: convert a test extension to use exthelper
This provides test coverage to uipopulate().
exthelper: drop fileset/revset/template support for now
Yuya raised concerns about duplicating registrar functionality. There are a
couple of ideas to work around this, which would allow bringing them back, and
then backporting to evolve. For now, I just want to get the subsequent changes
landed before the bulk b'' rewrite makes rebasing too hard.