rust-filepatterns: don't `Box` subincludes unnecessarily This was caught by `clippy`.

rust-nodemap: implement `PartialEq` without allocation This was caught by `clippy`. It's probable that this ends up optimized out by the compiler, but let's not rely on that.

rust-clippy: tell `clippy` we don't need to declare a default here This is a struct only useful for tests.

rust-clippy: refactor complex type This makes reading the signature a bit less tiring.

rust-clippy: simplify return type of debug function This makes the type a little bit more readable.

rust-clippy: add `is_empty` method to please the `clippy` gods I can see it being useful anyway.

rust: don't use a reference to a `Cow` This was caught by `clippy`.

rust-clippy: reassure `clippy` that 8 arguments is expected This API is a bit verbose, but refactoring it into a struct isn't better in this particular case IMO, and there is a lot of info to pass.

rust-clippy: use `write_all` since we're not expecting a partial write Clippy caught this. This is a good lint in general, but here this was not really a bug in this example code.

rust-clippy: tell clippy we want to keep those clauses separate This makes the cases more explicit, which is wanted in this specific instance.

rust-clippy: tell clippy we care about keeping those `if` clauses separate Thses were written this way because it spells out the logic in a more explicit manner.

rust-clippy: factor an `if` with the same duplicated clause Unlike the next changeset, this if is not really made clearer by keeping the cases separate.

rust: fix broken debug assertions These were caught by `clippy`. It appears no one uses the debug builds, which is how this wasn't caught before.

rust-narrow: fix loop that never loops This was caught by `clippy`. I guess the narrow tests leave something to be desired, since this previously only checked the first valid pattern.

rust: run `cargo clippy` These automatic fixes are good to have because they make the code more idiomatic and less surprising. The transform from `sort` -> `sort_unstable` is questionable, but this is only in a test, so it doesn't matter in our case.

rust: use `logging_timer` instead of `micro_timer` I am the author of `micro_timer`. I built it at the time because I couldn't find a crate that was simple to use and flexible to do function timing with. Turns out I just couldn't find it because crates.io's search isn't all that great, or maybe I didn't look hard enough. `logging_timer` is better in every way: - supports changing the logging level - supports start and end logging - supports intermediary messages - supports inline macros - supports formatting the output - better IDE/tree-sitter integration thanks to a more robust proc macro I also changed all uses to one-liners, so it's easier to copy-paste.

pathauditor: make _checkfs_exists a static method This fixes the bug detected by pytype where the auditor used in vfs.py may be a no-op auditor (vfs.py, line 398), which doesn't have the _checkfs_exists method.

merge: add mergeresult.mapaction to improve speed As a part of [hg update] we convert all [ACTION_CREATED] merge results into [ACTION_GET] actions, and that's slightly inefficient because every insertion pays the full cost of maintaining the [mergeresult] data structure up to date. This commit adds a function [mapaction], which is faster. (saves around 0.3s on a large update involving ~400k files)

merge: avoid dereferencing repo fields repeatedly

merge: skip syntactic path checks in [_checkunknownfile] We don't need to check the paths syntactically, since they are coming from diffing the revisions, so hopefully already checked on the way in. We still need to check what's on the filesystem, to avoid traversing the symlinks or subdirs, which we can't know about statically. Also, we use the directory audit to elide [isfileorlink], this removing ~all lstat calls from hg updates from-empty.

pathutil: use `finddirs_rev_noroot` instead of `parts` The benefit this brings is very tiny, if it's even there, since we still didn't get rid of the [parts] computation. It probably won't be worth it without the subsequent patch that adds one more use of [finddirs_rev_noroot]

pathutil: add the more efficient finddir iterator (to be used in subsequent commits)

typing: import unconditionally This is needed if we're writing python3 signatures.

tests: check how hgweb handles HEAD requests This test file is loosely based on test-hgweb.t. HEAD support originally implemented in fda5a4b853ab.

convert: replace repr() by pycompat.byterepr() in cvsps.py (issue6789)

convert: change socket mode from b'r+' to 'rwb' in cvs.py (issue6789) 'r+' mode used to open sockets for read/write operations, but '+' is not supported in Python 3. We're using bytes with these sockets everywhere, so the mode should have 'b'. But the mode argument has to be str, not bytes.

convert: turn the last str regex into bytes in cvs.py (issue6789) Since root is bytes, the regular expression should also be bytes.

tests: test hg status --all with hgext/git There's a TODO item in git/dirstate.py about obtaining clean files in a more straightforward way, let's first test that status can and does show clean files at all.

tests: aborting on unknown revision emits exit code 10 even with hgext/git

worker: avoid reading 1 byte at a time from the OS pipe Apparently `pickle.load` does a lot of small reads, many of them literally 1-byte, so it benefits greatly from buffering. This change enables the buffering, at the cost of more complicated interaction with the `selector` API. On one repository with ~400k files this reduces the time by about ~30s, from ~60 to ~30s. The difference is so large because the actual updating work is parallellized, while these small reads are bottlenecking the central hg process.

diffutil: rewrite an ersatz ternary operator for building diffopts.text Pytype tends to get confused by these, but the real problem here is that if the caller passes `opts={}` as TortoiseHg has been doing, that is set as the value for `diffopts.text` when in reality it expects a boolean. When `None` is passed explicitly, the default value in `mdiff.defaultopts` is assigned.

mdiff: add a __str__ method to diffopts This makes it easier to debug by just formatting the object into `%s` to see the members and state, instead of the class and memory address.

debugshell: allow TortoiseHg builds to exit with the usual `quit()` command I've long been annoyed that `quit()` only randomly worked to exit the interpreter. When that happens, Ctrl+C doesn't work either (it simply prints "KeyboardInterrupt"), so then you have to `import sys` and `sys.exit()`. But it turns out that the behavior isn't random and it depended on which `hg.exe` was picked up on PATH first, because py2exe disables site initialization. I wasn't able to persuade the maintainer to allow an opt-in to initialization[1], but this works around it so that the behavior is now consistent however `hg.exe` is built. TortoiseHg 6.3.3 will be the first build that includes the site package, so handle the ImportError. [1] https://github.com/py2exe/py2exe/issues/154

doc: add a few comments

rhg: implement checkexec to support weird filesystems In particular, some of our repos are stored on a fileserver that simulates POSIX permissions poorly, in such a way that prevents the removal of execute permission. This causes rhg show a spurious unclean status, even though python hg reports the repo as clean. We fix this by making rhg implement the ~same checkexec logic that python hg does.

convert: stop passing str to the dateutil API in darcs I'm sure there's a bunch more stuff in here that's broken, but this was flagged by pytype.

sparse: fix a py2 based usage of `map()` In a local pytype run, this fixes: File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 386, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '0: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 387, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '1: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 388, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '2: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]'

histedit: byteify the help for the multifold action While there's some allowance for str in `_()`, it's commented to be for "goofy unicode docstrings in test", so no idea how well that works, but it should at least come back as bytes. With HGPLAIN, however, the str isn't touched and is returned as-is, so this seems like a real bug.

typing: use python3-style type annotation

merge: cache the fs checks made during [_checkunknownfiles] this ~halves the number of lstat calls made when updating from rev(-1) to a revision with lots of files

merge: disable the whole filesystem access loop if [_realfs] is false This makes it clearer that [auditeddir] is only relevant for [_realfs] checkers, and makes the non-realfs checkers more performant.

merge: short-circuit the _checkfs loop upon getting ENOENT This reduces the number of [lstat] calls when updating from rev(-1) to a rev with lots of files by a factor of several: for path foo/bar/baz/quux.txt without this patch we're lstatting: foo foo/bar foo/bar/baz foo/bar/baz/quux.txt and with this patch: foo foo/bar/baz/quux.txt

merge: don't pay for pathconflicts if there are none

pathauditor: no need to normcase the paths The only thing normed paths are used is the key of the caching sets, so the only change of behavior will be that the checks will be repeated for paths that differ by case. If anything, it seems correct for the check to be repeated, in case that actually affects semantics, but the main reasoning is simplifying the code and making it a bit faster. It looks like the code originally comes from commit [081e795c60e0]: it looks like that commit tried to get rid of the existing norming, but presumably did this overly cautiously, preserving it for the cache keys, even though it was pointless even then.

pathutil: slightly faster path audit in the common case

debug: add a config to abort update early This is useful to benchmark the parts of [hg update] that come before the parallel worker.

dirstate: add missing methods and kwargs to idirstate interface

dirstate: swap pathto() and get_entry() in idirstate This way the order of methods in dirstate and idirstate classes is the same. Just to make it easier to use diff tools to compare the two classes.

dirstate: update docstrings in idirstate from the current dirstate

setup: drop legacy osx compiler tuning to enable universal builds This was triggering deprecation warnings about migrating to `packaging.version` from `distutils` Version classes with `make local`. But rather than migrate that code, let's just get rid of some ~10-12 year old workarounds. As a bonus, the cext libraries that are built are now universal binaries containing x86_64 and arm64 images (at least when built on macOS 11.4 with Xcode 12.5 and the universal version of Python 3.9.13). Several things to note here: - Apple dropped support for 10.15 in Nov 2022, and OS X Lion that is referenced is 10.7 (unsupported since late 2014) - `xcode4` was basically always True because of the `>=` check (10.8 used Xcode 5, and I have Xcode 10.2 on 10.14) - `xcode51` was always False for modern-ish Xcode, because of the exact version string matching - Python 3.8 only supports OS X 10.9+; the Python 3.9.1+ universal installer is macOS 11+ only, and Python 3.10 drops the x86_64 installer to deliver only the universal installer. All of this is to say, the only thing lost by dropping this code on modern Xcode is that `os.environ['ARCHFLAGS'] = ''` is no longer set. But we probably shouldn't be setting that anymore, as shown by the universal libraries now being generated. I was able to `make local` and `python3 run-tests.py --local` with python 3.9.9, Xcode 10.2, and macOS 10.14.6, and didn't incur any more than the usual few test errors, so this should still work on some older versions of macOS.

tests: simplify `(py3 no-py36 !)` output matching predicates to `(no-py36 !)` It's all py3 now.

tests: drop `(py3 !)` output matching predicates Presumably these were paired with `(no-py3 !)` at one point, but now they were unconditionally true. test-check-code.t required a couple of `(glob)` markers on the changed lines in test-lfs-serve-access.t, because of the `$LOCALIP` usage on those lines. Not sure how those lines slipped through the checks previously.

run-tests: drop a workaround for python2 The problem is only on python3, but the awkward handling was because python2 didn't have this exception type. I've sporadically seen it running in WSL, but no clue what it means.

contrib: drop py2 support from testparseutil.py

tests: drop py2 support from `f` utility

tests: drop py2 support from test-doctest.py

tests: drop py2 support from test-demandimport.py

tests: optional PEP 657 error location in test-lfs-serve-access.t (issue6782)

tests: optional PEP 657 error location in test-extension.t (issue6781)

tests: filter out PEP 657 error locations in tracebacks (issue6780) https://docs.python.org/3/whatsnew/3.11.html#whatsnew311-pep657

pytype: add coverage for parts of hgext There are tons of things to fix here (which have been blacklisted for now), but this should help prevent further regressions.

convert: stop passing str to the dateutil API in darcs I'm sure there's a bunch more stuff in here that's broken, but this was flagged by pytype.

typing: suppress a couple of attribute-errors in convert I thought these might be real issues, but they're not.

hooklib: force an exception wrapped by errors.Abort to bytestr Flagged by PyCharm and pytype.

notify: force an exception wrapped by errors.Abort to bytestr Flagged by PyCharm and pytype.

typing: disable a bogus attribute-error warning in phabricator In a local pytype run, this fixes: File "/mnt/c/Users/Matt/hg/hgext/phabricator.py", line 359, in <lambda>: No attribute 'items' on bytes [attribute-error] In Union[Any, bytes] Called from (traceback): line 363, in process The `bytes` case takes the previous `if` branch though.

sparse: fix a py2 based usage of `map()` In a local pytype run, this fixes: File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 386, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '0: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 387, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '1: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 388, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '2: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]'

typing: adjust `mercurial.util.iterlines()` to accept any `Iterable` In a local pytype run on the extensions, this fixes: File "/mnt/c/Users/Matt/hg/hgext/phabricator.py", line 788, in maketext: Function mercurial.util.iterlines was called with the wrong arguments [wrong-arg-types] Expected: (iterator: Iterator[bytes]) Actually passed: (iterator: list) Attributes of protocol Iterator[bytes] are not implemented on list: __next__

typing: disable an attribute-error warning in the journal extension The code is complicated enough that pytype doesn't realize that `name` can't be `None` if it is evaluated here.

remotefilelog: byteify the message for a few StorageErrors Flagged by pytype locally.

histedit: byteify the help for the multifold action While there's some allowance for str in `_()`, it's commented to be for "goofy unicode docstrings in test", so no idea how well that works, but it should at least come back as bytes. With HGPLAIN, however, the str isn't touched and is returned as-is, so this seems like a real bug.

typing: disable a few incorrect warnings in pywatchman The module-attr warnings are for things that only exist on Windows, and the wrong-keyword-args warning is due to a special case for a specific constructor. Both of these are properly conditionalized.

watchman: refactor transport connecting to unconfuse pytype Pytype sees `self.proc` as potentially `None` here, even though it's set by the `_connect()` logic. Instead of asserting, simply use the process returned by that method (which it sets into `self.proc` before returning, so there's no functional change here).

watchman: refactor `ctypes.windll.kernel32` references to a local variable This is flagged by pytype as an attribute-error, and it's easier to disable that in a single place.

typing: disable [unsupported-operands] warning in the largefiles outgoing hook For some reason, pytype thinks `toupload` is a set: No attribute '__setitem__' on Set[nothing] (It actually is a set in the subsequent `else` branch, but I'm not interested in trying to rewrite this to be consistent.)

typing: add some assertions that a variable isn't None In the case of blackbox, there's a default limit if one isn't explicitly supplied. For the monotone regex, neither group is optional, so a match means it's not None.

largefiles: reference `mercurial.configitems.dynamicdefault` directly Pytype was unable to see `dynamicdefault` on `eh.configitem`. This is clearer anyway.

releasenotes: fix a typo in a comment

schemes: fix a broken check for drive letter conflicts Flagged by pytype locally. It appears to have regressed in 1863584f2fba (not yet released). This seems like an obvious typo- `dict.isalpha()` is nonsense. There's no crash though because `schemes` is pre-populated with 5 schemes (that are all now defunct), so the length of the dict is never 1, so it's impossible to abort.

typing: suppress a bunch of potential import-error cases in extensions As flagged by pytype locally. Either the ImportError is locally handled, or the imported module was previously determined to be present by `hgave` (for the phabricator extension), or is handled by the `hgext.convert.subversion` module when imported (for the `hgext.convert.transport` module).

watchman: drop some py2 compat code The `unicode` reference was being flagged by pytype, even though it was never evaluated on py3. There's more that can be dropped and `compat.py` can probably be inlined if we don't care about minimizing the code changes from FB. But I don't feel like dealing with that.

pytype: add coverage for hgdemandimport This would have flagged what needed fixing in 48e38b179106 long ago.

hgweb: skip body creation of HEAD for most requests The body is thrown away anyway, so this just wastes a lot of CPU time. In the case of /archive/, this skips manifest processing and the actual file archiving, resulting in a huge difference. The most tricky part here is skipping the Content-Length creation as it would indicate the output size for the corresponding GET request.

branching: merge stable into default

urlutil: drop the deprecated `getpath()` This was deprecated in 5.9.

ui: drop the deprecated `getpath()` This was deprecated in 5.9.

ui: drop the deprecated `expandpath()` This was deprecated since 5.8.

relnotes: last-minute addition to 6.3.2

relnotes: add 6.3.2

Added signature for changeset 59466b13a3ae

Added tag 6.3.2 for changeset 59466b13a3ae

filemerge: fix crash when using filesets in [partial-merge-tools] Without this patch, you'd get `mercurial.error.ProgrammingError: fileset expression with no context`.

packaging: add dependencies to the PyOxidizer build on macOS Otherwise, we get a bunch of test failures for missing things like pygments, or tests skipped entirely. The input file is a copy/paste from the equivalent Windows file, but with dulwich, pygit2, and pytest-vcr commented out because the build process errors out with them, flagging them as incompatible with loading from memory. I have no idea if that's actually true or not, because I've noticed that if I don't `make clean` after every build, the next build flags the watchman stuff as incompatible with loading from memory. The remaining failures are: Failed test-alias.t: output changed Failed test-basic.t: output changed Failed test-check-help.t: output changed Failed test-commit-interactive.t: output changed Failed test-extension.t: output changed Failed test-help.t: output changed Failed test-i18n.t: output changed Failed test-log.t: output changed Failed test-qrecord.t: output changed Failed test-share-safe.t: output changed Most of the issues seem related to loading help for disabled extensions from `hgext.__index__`, namely the full extension help being unavailable, not being able to resolve what commands are provided by what extension, and not having the command level help available. test-log.t, test-commit-interactive.t, and test-i18n.t look like i18n (or lack thereof) issues. test-basic.t is just odd: @@ -55,7 +55,7 @@ On Python 3, stdio may be None: $ hg debuguiprompt --config ui.interactive=true 0<&- - abort: Bad file descriptor (no-rhg !) + abort: response expected abort: response expected (rhg !) [255] $ hg version -q 0<&-

tests: conditionalize path output for in-memory pyoxidizer resources

tests: conditionalize test output for in-filesystem pyoxidizer resources The in-memory pyoxidizer builds apparently behave as expected.

hghave: add predicates for embedded and filesystem pyoxidizer resources There are a handful of tests with different output between the two flavors of pyoxidizer builds (like the location of the modules and templates), and a few others that avoid `known-bad-output` cases with the embedded resources that shouldn't cause the tests to fail.

run-tests: support --pyoxidized on macOS We should definitely be able to test this before releasing it with an installer.

make: add a target for building pyoxidizer tests on macOS The resources seem to be embedded inside the binary, but for some reasons they aren't read there. And since they are embedded, they aren't staged by the build in the `lib` directory like on Windows. So copy them from the repo. We can figure out what's going wrong later.

copyright: update to 2023

bisect: correct message about aborting an in-progress bisect (issue6527) By using a custom cmdhint message here we're avoiding automatic hint generation in _statecheck.hint(), which would suggest 'hg bisect --continue' and 'hg bisect --abort' (neither of which is a valid option). This patch is only fixing the message about in-progress bisect, it doesn't modify the unfinished state checking logic.

revlog: fix misleading comment about _maxinline

verify: print short `p1` node in relevant dirstate messages This will help with debugging.

verify: also check dirstate The dirstate already is capable of verifying its integrity (although v2 features are not yet checked), let's run that code in `hg verify`.

tests: use the `--quiet` flag for verify when applicable This reduces a lot of the test output that was otherwise useless, and also makes it a lot easier to add things to verify without breaking the test suite because of additional output.

verify: format messages directly at the source

dirstate: update messages in verify to not use the old `state` API

dirstate: add narrow support to `verify` This will be called later in the series by the `verify` command.

dirstate: stop using `entry.state()` for logic in `verify` Use the new API instead of the deprecated one. The next changeset will remove the use of `state` in this method altogether (currently still in the messages)

dirstate-entry: add `modified` property This was already done in the Rust implementation and is a useful primitive. The C implementation had this called `merged`, but wasn't used anywhere. It will be used in the next changeset.

debug: add debug-revlog-stats command Display statistics about revlogs in the store. Useful to get an approximate size of a repository, etc. More statistics will be added in the future.

typing: attempt to remove @overloads in the platform module for stdlib methods This is mostly successful, as examining util.pyi, posix.pyi, and windows.pyi after a pytype run shows that the type overloads for `oslink`, `readlink`, `removedirs`, `rename`, `split`, and `unlink` have been removed. (Some of these still have an @overload, but the differences are the variable names, not the types.) However, @overloads remain for `abspath` and `normpath` for some reason. It's useful to redefine these methods for the type checking phase because in addition to excluding str and PathLike variants, some of these functions have optional args in stdlib that aren't implemented in the custom implementation on Windows, and we want the type checking to flag that instead of assuming it's an allowable overload everywhere. One last quirk I noticed that I can't explain- `pycompat.TYPE_CHECKING` is always False, so the conditionals need to check `typing.TYPE_CHECKING` directly. I tried dropping the custom code for assigning `pycompat.TYPE_CHECKING` and simply did `from typing import TYPE_CHECKING` directly in pycompat.py, and used `pycompat.TYPE_CHECKING` for the conditional here... and pytype complained that `pycompat` doesn't have the `TYPE_CHECKING` variable.

typing: add trivial type hints to rest of the windows platform module Skipping the file wrappers for now because there's interplay with C code, and making them subclass `typing.BinaryIO_Proxy` confuses PyCharm a bit.

typing: add type hints to the rest of the posix module These methods either don't have an analog in the windows module, or are aliased in the windows module from something else (like os.path.xxx).

typing: add type hints to the platform `cachestat` classes

util: fix the signature of observedbufferedinputpipe._fillbuffer() Flagged by PyCharm, since it didn't match the signature of the method being overridden. The default value in the superclass is also `_chunksize`, and I suspect that the amount read from `osread` should be limited to what is passed in. Only one caller (`bufferedinputpipe.unbufferedread()`) passes this argument, and it passes the max of `_chunksize` and whatever it was passed.

tests: drop some obsolete py2 handling in util.py doctest Flagged by PyCharm while inspecting imports from the platform modules.

typing: add type hints to the common posix/windows platform functions These are done in sync because some platforms have empty implementations, and it isn't obvious what the types should be without examining the other. We want the types aligned, so @overload definitions that differ aren't generated. The only differences here are the few methods that unconditionally raise an error are marked as `NoReturn`, which doesn't seem to bother pytype. A couple of the posix module functions needed to be updated with a modern ternary operator, because pytype seems to want to use the type of the second object in the old `return x and y` style.

typing: add type hints to the posix platform module matching win32.py

typing: add type hints to mercurial/win32.py These are the low level functions that are imported by the mercurial.windows module, which is in turn imported by mercurial.utils as the platform module. Pretty straightforward, but pytype inferred very little of it, likely because of the heavy ctypes usage. It also seems to trigger a pytype bug in procutil, now that it has an idea of the underlying function type, so disable that warning to maintain a working test.

windows: drop some py2 registry module importing The comment was actually backwards- `winreg` is importable on py3, and is already imported by mercurial/windows.py.