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

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.

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).