shelve: split up dounshelve() in unshelvecmd() and _dounshelve() I'd like to be able to override the new `_dounshelve()`, getting access to the name of the shelve to unshelve. `unshelvecmd()` seems to better match the existing `createcmd()`, `listcmd()` etc. Differential Revision: https://phab.mercurial-scm.org/D8322

darwin: use vim, not vi, to avoid data-loss inducing posix behavior Apple's version of vim, available at opensource.apple.com/release/macos-1015.html (for Catalina, but this behavior has been there for a while) has several tweaks from the version of vim from vim.org. Most of these tweaks appear to be for "Unix2003" compatibility. One of the tweaks is that if any ex command raises an error, the entire process will (when you exit, possibly minutes/hours later) also exit non-zero. Ex commands are things like `:foo`. Luckily, they only enabled this if vim was executed (via a symlink or copying the binary) as `vi` or `ex`. If you start it as `vim`, it doesn't have this behavior, so let's do that. To see this in action, run the following two commands on macOS: ``` $ vi -c ':unknown' -c ':qa' ; echo $? 1 $ vim -c ':unknown' -c ':qa' ; echo $? 0 ``` We don't want to start ignoring non-zero return types from the editor because that will mean you can't use `:cquit` to intentionally exit 1 (which, shows up as 2 if you combine an ex command error and a cquit, but only a 1 if you just use cquit, so we can't differentiate between the two statuses). Since we can't differentiate, we have to assume that all non-zero exit codes are intentional and an indication of the user's desire to not continue with whatever we're doing. If this was a complicated `hg split` or `hg histedit`, this is especially disastrous :( Differential Revision: https://phab.mercurial-scm.org/D8321

rust-matchers: use the `regex` crate Instead of falling back to Python when a code path with "ignore" functionality is reached and `Re2` is not installed, the default compilation (i.e. without the `with-re2` feature) will use the `regex` crate for all regular expressions business. As with the introduction of `Re2` in a previous series, this yields a big performance boost compared to the Python + C code in `status`, `diff`, `commit`, `update`, and maybe others. For now `Re2` looks to be faster at compiling the DFA (1.5ms vs 5ms for Netbeans' `.hgignore`) and a bit faster in actual use: (123ms vs 137ms for the parallel traversal of Netbeans' clean repo). I am in talks with the author of `regex` to see whether that performance difference is a bug, a "won't fix", or a tuning issue. The `regex` crate is already one of our dependencies and using this code does not require any additional work from the end-user than to use the Rust extensions. Differential Revision: https://phab.mercurial-scm.org/D8323

templater: add subsetparents(rev, revset) function Naming suggestions are welcome. And this could be flagged as an (ADVANCED) function since the primary use case is to draw a graph. This provides all data needed for drawing revisions graph filtered by revset, and allows us to implement a GUI graph viewer in some languages better than Python. A frontend grapher will be quite similar to our graphmod since subsetparents() just returns parent-child relations in the filtered sub graph. Frontend example: https://hg.sr.ht/~yuja/hgv/browse/default/core/hgchangesetgrapher.cpp However, the resulting graph will be simpler than the one "hg log -G" would generate because redundant edges are eliminated. This should be the same graph rendering strategy as TortoiseHg. This function could be implemented as a revset predicate, but that would mean the scanning state couldn't be cached and thus slow. Test cases are split to new file since test-template-functions.t is quite big and we'll need a new branchy repository anyway.

templater: remember cache key of evaluated revset This provides a hint for caching further computation result of the given revset. See the next patch for example.

templater: fix cbor() filter to accept smartset So the wrapper type can return a bare smartset.

templater: introduce wrapper for smartset (API) I want to add a template function which takes a revset as an argument: {somefunc(..., revset(...))} ^^^^^^^^^^^ evaluates to a revslist This wrapper will provide a method to get an underlying smartset. It should also be good for performance since count(revset(...)) will no longer have to fully consume the smartset for example, but that isn't the point of this change.