I'm dropping this since I found a bug in memfilectx. That's probably why
absorb crashed.

+try:
+ from . import rustext
+except ImportError:
+ rustext = None

+def parentsfunc(index):
+ def parentrevs(rev):
+ try:
+ entry = index[rev]
+ except IndexError:
+ if rev == wdirrev:
+ raise error.WdirUnsupported
+ raise
+
+ return entry[5], entry[6]
+ return parentrevs

Nit: While it's correct per our naming convention, I prefer calling it
as LazyAncestors in Rust, and export as lazyancestors.

• a/rust/hg-core/src/lib.rs +++ b/rust/hg-core/src/lib.rs @@ -2,8 +2,10 @@ This software may be used and distributed according to the terms of the // GNU General Public License version 2 or any later version. +use std::clone::Clone;

// GNU General Public License version 2 or any later version.

• //! Bindings for the hg::ancestors module provided by the

+type IndexParentsFn = unsafe extern "C" fn(
+ index: *mut python_sys::PyObject,
+ rev: ssize_t,
+ ps: *mut [c_int; 2],
+ max_rev: c_int,
+) -> c_int;

I've queued the first 5 patches, thanks. Please send a follow up to fix nits
and minor issues.

I expect we'll soon drop the support for the old ffi binding.

+ cargocmd = ['cargo', 'build', '-vv', '--release']
+ try:
+ subprocess.check_call(cargocmd, env=env, cwd=self.rustsrcdir)
+ except OSError as exc:
+ if exc.errno == os.errno.ENOENT:

I feel --no-<thing> and --<thing>=off|false are more natural, and
(default: %s) is the latter form.

Arguments against yes/no:

The point of D5430 was to make hg help output more human friendly by replacing True and False with something less Python-related. In other words, more human-friendly. "Yes" and "no" are way more human-friendly:

TBH, I think 'on' and 'off' are more appropriate than 'yes' and 'no'.

obviously, this one could be adapted for application before the rust-cpython bindings, and extended for the incrementalmissingancestors as well

Here, I'd be tempted to submit a py_capsule_fn macro to rust-cpython, but I guess it can wait.

This Differential has been superseded by D5414 through D5417

@yuja: I'll look into it, maybe that's a case for benches (I've not played with them yet).

In case of a failed example, all needed information
for reproduction is included in the panic message,
so that we don't need to
seed the random generator explicitely. This is how
`test_remove_ancestors_from_case1()` has been generated.

Queued this, thanks.