rhg: add resolve_file_args to path_utils.rs Extracted logic for resolving `FILE ...` arguments from cat.rs into a new function in path_utils.rs. I plan to use this for rhg annotate. I tried to reuse hg::utils::files::canonical_path instead, but that didn't work. For example it reports a InsideDotHg error for any path containing "..".

help: fix command build with rust The use of `--no-use-pep517` leads to ERROR: Disabling PEP 517 processing is invalid: project specifies a build backend of setuptools.build_meta in pyproject.toml

run-tests: call the command using shell=True to please Windows Windows is unhappy about the lack of shell=True, probably because the "self._realhg" is a script instead of a Win32 executable.

run-tests: align call argument on string The real hg path is bytes and need to be converted to align with the other arguments.

run-tests: provide more information when calling hg fails This helps to debug failure.

rust-pyo3: plugging in the ancestor module

rust-pyo3: MissingAncestors

rust-pyo3: new helper for incoming iterables of revisions The pattern to borrow the core `Index` from the index proxy, and using it in `rev_pyiter_collect` is frequent enough in what remains to be converted from `hg-cpython` that it is worth having this direct helper (and it will neatly enclose the unsafety).

rust-pyo3: implementation of LazyAncestors There is a difference in the implementaion of `__contains__` between PyO3 and rust-cpython: if the specified signature in Rust code is for a precise type (e.g., `PyRevision`) rust-cpython would automatically convert the potential resulting `TypeError` into `Ok(false)`, whereas PyO3 let it bubble up. Hence we treat the case manually and add it to the common test. In Mercurial Python code, `None in` for a `LazyAncestors` object can really happens, namely in this lambda from `discover._postprocessobsolete`: ``` ispushed = lambda n: torev(n) in futurecommon ``` This lambda can get called with `n` such that `torev(n)` is `False` (seen in `test-bookmarks-push-pull.t`).

rust: test AncestorsIterator without duplication Up to now, it was acceptable to duplicate the test in `test-rust-ancestor.py` that was relevant to `dagop`. Now that we have more PyO3 implementations, it is better, and actually more convincing, to express the tests in a common base class (has technically to be a mixin to avoid running the tests from the base class itself).

rust-pyo3: exposition of AncestorsIterator Compared to the early experiments, we have one less `RwLock` in the wrapping. Still that is somewhat redundant with `UnsafePyLeaked` being itself some kind of lock. In the original rust-cpython code, we were borrowing the `RefCell` with a method that can panic. Instead we are now converting the `PoisonError` that unlocking a `RwLock` can produce. Since all methods acquiring the `RwLock` are themselves protected by the GIL and do not release it before returning, nor do they leak RwLock guards, there is no risk of contention on these locks themselves.

rust-pyo3: generic borrows of UnsafePyLeaked with error treatment Maybe we will find later a more pleasant way to express safety. Meanwhile, these helpers are useful because of the proper error propagation, and will help to avoid too much cruft in the caller code.

rust-pyo3: error propagation for UnsafePyLeaked wrapping a result This `py_leaked_or_map_err` is the PyO3 version of the function of the same name in `hg-cpython/src/ancestors.rs`.

rust-pyo3: getting rust-cpython GIL handle from various PyO3 objects Depending on the caller context, we might have a `Python<'py>` around or any of the smart pointers that bear the GIL lifetime. Of course, all of these can give back a `Python<'py>` but it is worthwile to reduce the needed boilerplate. The trait just expresses that a lifetime is assumed to be outlived by the PyO3 GIL lifetime. It is marked as unsafe because that is just trusting the implementor. A first version of this was made of a safe trait with a `get_py()` method and the corresponding trivial implementations. We found it finally to be even more artificial, as it boils down to coding 4 functions doing and returning no real data, that we hope the compiler will optimize away.

rust-pyo3: intermediate ProxyIndex extraction Retrieving the `UnsafePyLeaked` without borrowing it will be necessary for the upcoming classes that need to store an inner object derived from it.

rhg: set group-writable checkisexec file permissions in Python This actually achieves what the parent commit tried to do, but on the Python side. Unfortunately, `mkstemp` doesn't seem to let us specify the initial file permissions so we have to apply umask by hand when chmodding.

rhg: set the expected temp file permissions (0o666 minus umask) This continues the theme of a48c688d3e80, and fixes the bug #6375, which was causing some problems for us, where a non-group-readable file can't be copied, which breaks some tools that copy the repo. This affects both the `checkexec` file and the temporary file we use for filesystem time measurement, since either of these files remaining on disk can cause this problem, and the 0666 permissions are just the better default here.

rhg: add a collision detection to complain about duplicated commands The previous commit made it easier (too easy) to define commands with identical names. It turns out `clap` does nothing to detect such collisions, which also leads to very confusing behavior. This change catches that error, and reports where the commands came from.

rhg: consistently use the command name given in clap::command!(<...>) macro Before this patch there are 2 things the user controls: 1. the module/command name, specified in subcommand! macro 2. the command name, specified in clap::command! macro If these are out of sync, we get no compile error or a clear runtime error, but instead a confusing behavior where command line parser parses one thing, but running it doesn't work. This commit makes the clap::command! macro the sole authority determining the command name, so we don't have to worry about this weird behavior any more. It also makes it easy to validate agreement between (1) and (2) if we want it, but I didn't add the check because I'm not sure people necessarily want it.

rhg: simplify the subcommands macro Reduce the scope of the macro to only generate individual `SubCommand` values. This way, it will be easy to tweak the behavior of `add_subcommand_args` and `subcommand_run_fn` without having to understand the details of the macro. It also lets us easy add commands that don't fit the idiom, for example the "admin::" commands or "script::" commands.