merge with stable

grep: grep the working copy faster `hg grep qqqq` in the mercurial repo: before: 0,859s after: 0,233s `hg grep somethingwithnomatch` in mozilla-central: before: 51s after: 19s This is probably also a tiny bug fix, because the code was looking up a node for filename `pfn` on a filelog for filename `fn`, which are most of the time the same filename, but don't have to be. Ignoring performance and the bug fix, the code should have the same behavior. Differential Revision: https://phab.mercurial-scm.org/D8545

grep: stop computing information for --diff when unnecessary This is one reason why `hg grep pattern` essentially does `hg cat -r . 'set:**'` inside. There is no speed improvement in this commit, because the rest of the code still greps data from filelog instead of working copy when possible. Differential Revision: https://phab.mercurial-scm.org/D8544

grep: don't go in an infinite loop when given empty regex Differential Revision: https://phab.mercurial-scm.org/D8543

grep: improve test coverage Differential Revision: https://phab.mercurial-scm.org/D8542

phabricator: avoid passing None to pycompat.fsdecode Differential Revision: https://phab.mercurial-scm.org/D8525

setup: stop asking cargo to spam It prints this kind of stuff by default: Compiling regex v1.3.6 Compiling rand v0.7.3 Compiling crossbeam-deque v0.7.3 which is way better than we ask for before this change, which is screen after screen of compilation commands and irrelevant warnings in crates we use. Differential Revision: https://phab.mercurial-scm.org/D8537

git: implement some changelog methods Differential Revision: https://phab.mercurial-scm.org/D8540

git: avoid looking-up parents for the null commit Differential Revision: https://phab.mercurial-scm.org/D8541

git: fix probable missing return Differential Revision: https://phab.mercurial-scm.org/D8539

rust: fix warning about unnecessary mut If there's a reason to use mut (like compability with older compilers), then we should stick `#[allow(unused_mut)]` on the declaration. Differential Revision: https://phab.mercurial-scm.org/D8538

upgrade: support upgrade and downgrade from persistent nodemap The requirements is now recognised and dealt with and the associated files properly handled. The persistent nodemap should be ready for usage in the field now. Differential Revision: https://phab.mercurial-scm.org/D8431

status: also support for `traversedir` callback in the Rust fast-path Repeating the performance numbers from the `hg-core` change: Running `hg clean/purge` on Netbeans' repo (100k files): ``` | No-op | 30% unknown -------------------------- Rust | 1.0s | 1.67s C | 2.0s | 2.87s ``` Differential Revision: https://phab.mercurial-scm.org/D8520

rust-hg-cpython: update status bridge with the new `traversedir` support Differential Revision: https://phab.mercurial-scm.org/D8519

rust-status: collect traversed directories if required Some commands (`hg purge` notably) register the `traversedir` callback on their matcher to run said callback every time a directory is traversed. This is the first of three patches, further broadening Rust support for status. Unfortunately, there is no way around collecting a full `Vec` (or any other owned datastructure, like a radix tree) and pushing it back up the Python layer since keeping the Python callback in a closure would mean giving up multithreading because of the GIL, which is obviously unacceptable. Performance is still a lot better than the Python+C path. Running `hg clean/purge` on Netbeans' repo (100k files): ``` | No-op | 30% unknown -------------------------- Rust | 1.0s | 1.67s C | 2.0s | 2.87s ``` Differential Revision: https://phab.mercurial-scm.org/D8518

rust-status: don't dispatch unknown file when traversing if not listing unknowns This usually isn't a (functional) problem since we ignore the unknown files anyway, but when specifically using `hg purge`, unknown files were iterated over regardless of the option being true. This is both more correct and more efficient. Differential Revision: https://phab.mercurial-scm.org/D8517

status: update comment to reflect the more recent situation This is a gratuitous cleanup. Differential Revision: https://phab.mercurial-scm.org/D8516

hooks: provide access to transaction changes for internal hooks External hooks are skipped here as the environment often has a size limit in the low MBs and that can easily be reached by larger transactions. Differential Revision: https://phab.mercurial-scm.org/D8490

rust-regex: add test for verbatim regex syntax This makes sure it's not modified. Differential Revision: https://phab.mercurial-scm.org/D8508

rust-regex: prevent nonsensical `.*.*` pattern from happening Differential Revision: https://phab.mercurial-scm.org/D8507

rust-regex: fix issues with regex anchoring and performance It turns out that the way I tried to work around `regex`'s behavior difference with `re2` and Python's `re` was 1) buggy and 2) much more complicated than needed. In a few words: `regex` adds `.*` on either side of patterns when no start or end anchor is present. My previous workaround put `^` or `$` for every pattern, which is wrong even without the other 2 bugs on top of it. Using `^(?:<patterns>)` right at the end of the `regex` path fixes the issue. I've opened an issue to get a build option instead: https://github.com/rust-lang/regex/issues/675 Differential Revision: https://phab.mercurial-scm.org/D8506

diff: avoid going from contexts to nodes and back This will allow us to pass in-memory contexts that may not have a valid node to the diffing logic. Differential Revision: https://phab.mercurial-scm.org/D8503

setup: raise minimum Python version to 2.7.4 On older Python versions, Mercurial is not really usable because of https://bugs.python.org/issue10211. Recently someone reported a crash on the mailing list when running Mercurial on Python 2.7.3. There was consensus that fixing compatibility for a Python version more than 7 years old is not worth it. So, instead of making Mercurial crash with an obscure exception, this patch raises the minimum Python version to 2.7.4.

fsmonitor: coerce `clock` variable to byte-string (issue6321) Callers of `fsmonitor.state.setlastclock` pass their arguments wrapped in `pycompat.sysbytes` to ensure the value is a `bytes` on Python 3. However in `fsmonitor.poststatus.__call__`, if the return value of `getlastclock()` is `None`, we use the value of `fsmonitor.poststatus._startclock` instead, which is not converted to a byte string in the same manner. This commit converts the value of `startclock` to a byte string using `pycompat.sysbytes` in the constructor for `poststatus`, to avoid the "`str` + `bytes`" error from issue 6321. Differential Revision: https://phab.mercurial-scm.org/D8573