parser: force a `ValueError` to bytes before passing to `error.ParseError` I'm not sure what changed before pytype 09-09-2021 (from 04-15-2021), but this started getting flagged. I think there's a pytype bug here, because I don't see how `.lower()` can be getting called on a `ValueError` after it is forced to a byte string. That's suppressed for now to make progress. This fixes: File "/mnt/c/Users/Matt/hg/mercurial/parser.py", line 219, in unescapestr: Function bytestr.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, ints: Iterable[int]) Actually passed: (self, ints: ValueError) Attributes of protocol Iterable[int] are not implemented on ValueError: __iter__ File "/mnt/c/Users/Matt/hg/mercurial/parser.py", line 219, in unescapestr: No attribute 'lower' on ValueError [attribute-error] In Union[ValueError, mercurial.pycompat.bytestr] Differential Revision: https://phab.mercurial-scm.org/D11471

util: avoid a name-error warning in the `mmapread` exception handler Newly caught by pytype 2021-09-09. File "/mnt/c/Users/Matt/hg/mercurial/util.py", line 458, in mmapread: Name 'fd' is not defined [name-error] Differential Revision: https://phab.mercurial-scm.org/D11470

typing: suppress an name-error warning in `mercurial/windows.py` Newly caught by pytype 2021-09-09. Differential Revision: https://phab.mercurial-scm.org/D11469

typing: suppress an import-error warning in `mercurial/utils/resourceutil.py` Newly caught by pytype 2021-09-09. Differential Revision: https://phab.mercurial-scm.org/D11468

encoding: force a few Errors to bytes before passing to `error.Abort` I'm not sure what changed before pytype 09-09-2021 (from 04-15-2021), but these started getting flagged. PyCharm also flagged these. This fixes the following: File "/mnt/c/Users/Matt/hg/mercurial/encoding.py", line 243, in fromlocal: Function Abort.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, message: Union[bytearray, bytes, memoryview], ...) Actually passed: (self, message: LookupError, ...) File "/mnt/c/Users/Matt/hg/mercurial/encoding.py", line 309, in lower: Function Abort.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, message: Union[bytearray, bytes, memoryview], ...) Actually passed: (self, message: LookupError, ...) File "/mnt/c/Users/Matt/hg/mercurial/encoding.py", line 336, in upperfallback: Function Abort.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, message: Union[bytearray, bytes, memoryview], ...) Actually passed: (self, message: LookupError, ...) Called from (traceback): line 391, in current file line 348, in get line 318, in upper Differential Revision: https://phab.mercurial-scm.org/D11467

typing: add a fake `__init__()` to bytestr to distract pytype I'm not sure what changed before pytype 09-09-2021 (from 04-15-2021), but these started getting flagged. This wrapping an exception in a `bytestr` pattern has been flagged before, and I've fixed it then with `stringutil.forcebytestr()`. But that doesn't work here, because it would create a circular import. I suspect the issue is `bytes.__new__()` wants `Iterable[int]`, so it just assumes the subclass will also take that. The referenced pytype bug isn't an exact match, but seems related and the suggested workaround helps. The specific warnings fixed are: File "/mnt/c/Users/Matt/hg/mercurial/encoding.py", line 212, in tolocal: Function bytestr.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, ints: Iterable[int]) Actually passed: (self, ints: LookupError) Attributes of protocol Iterable[int] are not implemented on LookupError: __iter__ Called from (traceback): line 353, in current file File "/mnt/c/Users/Matt/hg/mercurial/encoding.py", line 240, in fromlocal: Function bytestr.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, ints: Iterable[int]) Actually passed: (self, ints: UnicodeDecodeError) Attributes of protocol Iterable[int] are not implemented on UnicodeDecodeError: __iter__ Differential Revision: https://phab.mercurial-scm.org/D11466

merge: with stable

pep-517: remove the `build-backend` key to allow for users to build extensions PEP 517 changed how projects should define their build dependencies. The presence of a `pyproject.toml` file changes the behavior of `pip` to conform to PEP 517. Since we haven't updated the `setup.py` file yet (I'm not even sure we're not an edge case which would make it harder/impossible, I have not tried yet), this is a workaround to issue6589: it allows users to pass `--no-use-pep517` to pip to revert to the legacy installer. The build backend is simply assumed to be the `build_meta:__legacy__` one. Differential Revision: https://phab.mercurial-scm.org/D11393

dirstate: drop the `dirstatemap.dropfile` method All use have been migrated. Differential Revision: https://phab.mercurial-scm.org/D11443

dirstate: use `reset_state` instead of `dropfile` in test-rebuildstate.t As `dirstatemap.dropfile` is on its way out. Differential Revision: https://phab.mercurial-scm.org/D11442