make: also delete hg.exe when cleaning This will be needed for the next patch, which has more details. It has to come before the call into setup.py because even `python setup.py clean` calls hg to generate the version file. Differential Revision: https://phab.mercurial-scm.org/D8037

merge: start using the per-side copy dicts The point of this patch is mostly to clarify `manifestmerge()`. I find it much easier to reason about now. Differential Revision: https://phab.mercurial-scm.org/D7990

copies: define a type to return from mergecopies() We'll soon return two instances of many of the dicts from `copies.mergecopies()`. That will mean that we need to return 9 different dicts, which is clearly not manageable. This patch instead encapsulates the 4 dicts we'll duplicate in a new type. For now, we still just return one instance of it (plus the separate `diverge` dict). Differential Revision: https://phab.mercurial-scm.org/D7989

merge: move initialization of copy dicts to one place Differential Revision: https://phab.mercurial-scm.org/D7988

copies: print debug information about copies per side/branch Differential Revision: https://phab.mercurial-scm.org/D7987

copies: make mergecopies() distinguish between copies on each side I find it confusing that most of the dicts returned from `mergecopies()` have entries specific to one branch of the merge, but they're still combined into dict. For example, you can't tell if `copy = {"bar": "foo"}` means that "foo" was copied to "bar" on the first branch or the second. It also feels like there are bugs lurking here because we may mistake which side the copy happened on. However, for most of the dicts, it's not possible that there is disagreement. For example, `renamedelete` keeps track of renames that happened on one side of the merge where the other side deleted the file. There can't be a disagreement there (because we record that in the `diverge` dict instead). For regular copies/renames, there can be a disagreement. Let's say file "foo" was copied to "bar" on one branch and file "baz" was copied to "bar" on the other. Beacause we only return one `copy` dict, we end up replacing the `{"bar": "foo"}` entry by `{"bar": "baz"}`. The merge code (`manifestmerge()`) will then decide that that means "both renamed from 'baz'". We should probably treat it as a conflict instead. The next few patches will make `mergecopies()` return two instances of most of the returned copies. That will lead to a bit more code (~40 lines), but I think it makes both `copies.mergecopies()` and `merge.manifestmerge()` clearer. Differential Revision: https://phab.mercurial-scm.org/D7986

pathutil: mark parent directories as audited as we go Before 0b7ce0b16d8a (pathauditor: change parts verification order to be root first, 2016-02-11), we used to validate child directories before parents. It was then important to only mark the child audited only after we had audited its parent (ancestors). I'm pretty sure we don't need to do that any more, now that we audit parents before children. Differential Revision: https://phab.mercurial-scm.org/D8002

cmdutil: change check_incompatible_arguments() *arg to single iterable This makes it clearer on the call-sites that the first argument is special. Thanks to Yuya for the suggestion. Differential Revision: https://phab.mercurial-scm.org/D8018

rust: remove an unnecessary set of parentheses My build complained about this. I guess it started after I upgraded rustc. Differential Revision: https://phab.mercurial-scm.org/D8020

profiling: flush stdout before writing profile to stderr On py3, stdout and stderr appear to be buffered and this causes my command's output to be intermixed with the profiling output. Differential Revision: https://phab.mercurial-scm.org/D8024

rust: re-format with nightly rustfmt This fixes test-check-rust-format.t. Differential Revision: https://phab.mercurial-scm.org/D8025

tests: stablize test-rename-merge1.t on Windows This goes with d7622fdec3b5. Differential Revision: https://phab.mercurial-scm.org/D8036

rust-cpython: make sure PySharedRef::borrow_mut() never panics Since it returns a Result, it shouldn't panic depending on where the borrowing fails. PySharedRef::borrow_mut() will be renamed to try_borrow_mut() by the next patch.

rust-cpython: remove useless wrappers from PyLeaked, just move by map() This series prepares for migrating to the upstreamed version of PySharedRef. I found this last batch wasn't queued while rewriting the callers. While Option<T> was historically needed, it shouldn't be required anymore. I wasn't aware that each filed can be just moved.

rust-node: avoid meaningless read at the end of odd prefix This should be heavily factored out by the CPU branch predictor anyway. Differential Revision: https://phab.mercurial-scm.org/D8019

rust-nodemap: generic NodeTreeVisitor This iterator will help avoid code duplication when we'll implement `insert()`, in which we will need to traverse the node tree, and to remember the visited blocks. The structured iterator item will allow different usages from `lookup()` and the upcoming `insert()`. Differential Revision: https://phab.mercurial-scm.org/D7794

rust-nodemap: mutable NodeTree data structure Thanks to the previously indexing abstraction, the only difference in the lookup algorithm is that we don't need the special case for an empty NodeTree any more. We've considered making the mutable root an `Option<Block>`, but that leads to unpleasant checks and `unwrap()` unless we abstract it as typestate patterns (`NodeTree<Immutable>` and `NodeTree<Mutated>`) which seem exaggerated in that case. The initial copy of the root block is a very minor performance penalty, given that it typically occurs just once per transaction. Differential Revision: https://phab.mercurial-scm.org/D7793

rust-nodemap: abstracting the indexing In the forthcoming mutable implementation, we'll have to visit node trees that are more complex than a single slice, although the algorithm will still be expressed in simple indexing terms. We still refrain using `#[inline]` indications as being premature optimizations, but we strongly hope the compiler will indeed inline most of the glue. Differential Revision: https://phab.mercurial-scm.org/D7792

rust-nodemap: NodeMap trait with simplest implementation We're defining here only a small part of the immutable methods it will have at the end. This is so we can focus in the following changesets on the needed abstractions for a mutable append-only serializable version. The first implementor exposes the actual lookup algorithm in its simplest form. It will have to be expanded to account for the missing methods, and the special cases related to NULL_NODE. Differential Revision: https://phab.mercurial-scm.org/D7791

rust-node: handling binary Node prefix Parallel to the inner signatures of the nodetree functions in revlog.c, we'll have to handle prefixes of `Node` in binary form. Another motivation is that it allows to convert from full Node references to `NodePrefixRef` without copy. This is expected to be by far the most common case in practice. There's a slight complication due to the fact that we'll be sometimes interested in prefixes with an odd number of hexadecimal digits, which translates in binary form by a last byte in which only the highest weight 4 bits are considered. This is totally transparent for callers and could be revised once we have proper means to measure performance. The C implementation does the same, passing the length in nybbles as function arguments. Because Rust byte slices already have a length, we carry the even/odd informaton as a boolean, to avoid introducing logical redundancies and the related potential inconsistency bugs. There are a few candidates for inlining here, but we refrain from such premature optimizations, letting the compiler decide. Differential Revision: https://phab.mercurial-scm.org/D7790

rust-revlog: a trait for the revlog index As explained in the doc comment, this is the minimum needed for our immediate concern, which is to implement a nodemap in Rust. The trait will be later implemented in `hg-cpython` by the index Python object implemented in C, thanks to exposition of the corresponding functions as a capsule. The `None` return cases in `node()` match what the `index_node()` C function does. Differential Revision: https://phab.mercurial-scm.org/D7789

pathauditor: drop a redundant call to bytes.lower() `_lowerclean(s)` calls `s.lower()`, so we don't need to do that before calling it. Differential Revision: https://phab.mercurial-scm.org/D8001

merge: replace a repo.lookup('.') by more typical repo['.'].node() The `repo.lookup('.')` form comes from b3311e26f94f (merge: fix --preview to show all nodes that will be merged (issue2043)., 2010-02-15). I don't know why that commit changed from `repo['.']`, but I don't think there's any reason to do that. Note that performance should not be a reason (anymore?), because repo.lookup() is implemented by first creating a context object. Differential Revision: https://phab.mercurial-scm.org/D7998

merge: drop now-unused "abort" argument from hg.merge() Differential Revision: https://phab.mercurial-scm.org/D7997

merge: don't auto-pick destination with `hg merge 'wdir()'` If the user doesn't specify a commit to merge with, we'll have `node==None` in `commands.merge()`. We'll then try to find a good commit to merge with. However, if the user, for some strange reason, runs `hg merge 'wdir()'`, we'll also have `node==None` and we'll do that same. That's clearly not the intent, so let's not do that. It turns out we'd instead crash on that command after this patch, so I added special handling of it too. Differential Revision: https://phab.mercurial-scm.org/D7996

merge: call hg.abortmerge() directly and return early It's seem really weird to go through a lot of unrelated code before we call `hg.merge(..., abort=True)` when we can just call `hg.abortmerge()` and return early. Differential Revision: https://phab.mercurial-scm.org/D7995

merge: check that there are no conflicts after --abort Same idea as in abcc82bf0717 (clean: check that there are no conflicts after, 2020-01-24). We should reuse more code here, but that will come later. Differential Revision: https://phab.mercurial-scm.org/D7994

merge: use check_incompatible_arguments() for --abort Differential Revision: https://phab.mercurial-scm.org/D7993

wix: use original version string for MSI filename Version string normalization is mostly to placate MSI requirements. I think it makes sense to use the original version string in filenames. Since we can have distinct versions normalizing to the same MSI version string, this will allow us to distinguish between different actual version strings based on the filename. Differential Revision: https://phab.mercurial-scm.org/D8005

wix: always normalize version string Before, it was possible to pass in a custom version string which would not be valid in MSI. So we always normalize the version string. While we're here, also print when we normalize the version string, for better visibility. Differential Revision: https://phab.mercurial-scm.org/D8004