pvec: drop an unused `from __future__ import division` This module only uses the `//` operator (for integer division). Differential Revision: https://phab.mercurial-scm.org/D8326

py3: use integer division in histedit Histedit uses the `/` operator, which does type conversion to float in Python 3 instead of integer division likeon Python 2. Let's preserve the Python 2 behavior by importing and using the `//` operator. Differential Revision: https://phab.mercurial-scm.org/D8324

rust: update README to reflect use of `regex` crate Differential Revision: https://phab.mercurial-scm.org/D8325

rust: update all dependencies We do this periodically to say up to date. No major versions were crossed this time per se, but the `rand` is still in v0, and their 0.7x series broke three things: - Some distribution-related elements were moved to a separate crate, flashing a deprecation warning - The `LogNormal::new` associated function now returns a `Result` - Certain RNGs were updated to sample a `u32` instead of `usize` when their upper-bound is less than `u32::MAX` for better portability, which changed the output for 2 tests. Moreover, the recent use of the `regex` crate for ignore mechanisms prompted some benchmarking that revealed that `regex` was slower at compiling big regex than `Re2`. The author of `regex` was very quick to discover an optimization that yielded a 30% improvement. It's still slower than `Re2` in that regard, but less so in the 1.3.6 release. Differential Revision: https://phab.mercurial-scm.org/D8320

rust: update micro-timer dependency The new version uses a much more robust technique and should remove any existing risk of bad compiler error or performance hit. Differential Revision: https://phab.mercurial-scm.org/D8319

rust-status: only involve ignore mechanism when needed This prevents unnecessary fallbacks to Python, improving performance for `hg update` for instance. On Mozilla-Central a noop update goes from 1.6s down to 700ms. Differential Revision: https://phab.mercurial-scm.org/D8315

templater: fix cbor() filter to recursively convert smartset to list The previous attempt, e3e44e6e7245 "templater: fix cbor() filter to accept smartset", was incomplete since obj may be a collection containing a smartset. This works around the problem by converting smartsets recursively. Another option is to teach cborutil how to encode a smartset. That should be okay, but I hesitated to add "import smartset" to cborutil.py as the cborutil is pretty generic.

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