rust: update Cargo.lock Differential Revision: https://phab.mercurial-scm.org/D9080

rust-tests: add test to check if `Cargo.lock` is up-to-date An out-of-date `Cargo.lock` is the source of rebase conflicts, prevents a reproductible build, introduces desync between the series that introduces a change in dependencies and the one that eventually commits the `Cargo.lock`, and is just a general annoyance. This commit demonstrates that the test works, the next one fixes the currently out-of-date `Cargo.lock`. Differential Revision: https://phab.mercurial-scm.org/D9079

scmutil: introduce function to check whether repo uses treemanifest or not In an upcoming patch, I wanted to check whether current repo uses treemanifest or not. I looked for a function and found that at all places we manually check for the requirement in repo requirements. I guess having a dedicated function for that is much better. Differential Revision: https://phab.mercurial-scm.org/D8981

chg: make is possible to call by default an hg binary located next to chg When a single version of hg is in use and it's in the PATH, using chg is just a matter of calling chg. But when there are multiple installations of hg+chg around, and hg is referred to with an absolute path, using chg is more annoying because it requires both changing the invocation to hg to use chg, but also setting CHGHG. Currently, we set HGPATH when we build chg to remove the need to set CHGHG in the previous paragraph. But that means chg now hardcodes its installation path, which makes the installation not relocatable. Hence this proposal to make chg find ./hg relative to itself (as opposed to CHGHG=./hg which find hg relative to cwd). This only works on linux as written, but since it's opt-in, it sounds fine. Tested by hand, as I'm not sure how else to test this. Differential Revision: https://phab.mercurial-scm.org/D9006

phases: fix performance regression with Python 2 Unlike Python 3, xrange doesn't support efficient "in" and uses a linear time scan instead. Expand the condition to handle it fast. Differential Revision: https://phab.mercurial-scm.org/D9072

rebase: move check for unresolved conflicts into lower-level rebasenode() I want to add another call to `rebasenode()` and it's better to not have to duplicate the check. Differential Revision: https://phab.mercurial-scm.org/D9075

rebase: add dryrun property to rebaseruntime I want to be able to check the property in `rebaseruntime._rebasenode()`. Passing the value via the runtime is a convenient way. Differential Revision: https://phab.mercurial-scm.org/D9074

rebase: when collapsing, p1 == dest, so use the former only `dest` is the destination we're rebasing onto, which is always the same as `p1` when using `--collapse`. This lets us simplify a bit. Differential Revision: https://phab.mercurial-scm.org/D9073

rebase: remove redundant isinmemory argument from _origrebase() The argument is redundant with `rbst.inmemory`, which makes it unclear what to do if they were somehow different. Differential Revision: https://phab.mercurial-scm.org/D9070

largefiles: prevent in-memory merge instead of switching to on-disk I enabled in-memory merge by default while testing some changes. I spent quite some time troubleshooting why largefiles was still creating an on-disk mergestate. Then I found out that it ignores the callers `wc` argument to `mergemod._update()` and always uses on-disk merge. This patch changes that so we raise an error if largefiles is used with in-memory merge. That way we'll notice if in-memory merge is used with largefiles instead of silently replacing ignoring the `overlayworkingctx` instance and updating the working copy instead. I felt a little bad that this would break things more for users with both largefiles and in-memory rebase enabled. So I also added a higher-level override to make sure that largefiles disables in-memory rebase. It turns out that that fixes `run-tests.py -k largefiles --extra-config-opt rebase.experimental.inmemory=1`. Differential Revision: https://phab.mercurial-scm.org/D9069