Sat, 26 Oct 2024 23:33:19 +0200 branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 26 Oct 2024 23:33:19 +0200] rev 52132
branching: merge stable into default Hopefully this will bring the last changes necessary to make the 3.13 tests green (on Linux).
Fri, 25 Oct 2024 23:46:20 -0400 tests: enable pytype checking on `mercurial/wireprotov1peer.py`
Matt Harbison <matt_harbison@yahoo.com> [Fri, 25 Oct 2024 23:46:20 -0400] rev 52131
tests: enable pytype checking on `mercurial/wireprotov1peer.py`
Fri, 25 Oct 2024 23:45:05 -0400 typing: suppress bogus pytype errors in `mercurial/wireprotov1peer.py`
Matt Harbison <matt_harbison@yahoo.com> [Fri, 25 Oct 2024 23:45:05 -0400] rev 52130
typing: suppress bogus pytype errors in `mercurial/wireprotov1peer.py` Fixes: File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 100, in result: No attribute '_peerexecutor' on unsentfuture [attribute-error] File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 278, in close: No attribute 'shutdown' on None [attribute-error] Called from (traceback): line 123, in __exit__ File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 278, in close: No attribute 'shutdown' on None [attribute-error] In Optional[concurrent.futures.thread.ThreadPoolExecutor] We drop the zope decorator on `peerexecutor`, because otherwise it triggers this error: File "/tmp/mercurial-ci/mercurial/wireprotov1peer.py", line 111, in <module>: Invalid type annotation [invalid-annotation] Must be constant Not sure why, because the decorated classes usually get typed as `Any`, which would also be fine here.
Fri, 25 Oct 2024 23:09:10 -0400 tests: enable pytype checking on `mercurial/wireprotoframing.py`
Matt Harbison <matt_harbison@yahoo.com> [Fri, 25 Oct 2024 23:09:10 -0400] rev 52129
tests: enable pytype checking on `mercurial/wireprotoframing.py`
Fri, 25 Oct 2024 23:07:34 -0400 typing: suppress bogus pytype errors in `mercurial/wireprotoframing.py`
Matt Harbison <matt_harbison@yahoo.com> [Fri, 25 Oct 2024 23:07:34 -0400] rev 52128
typing: suppress bogus pytype errors in `mercurial/wireprotoframing.py` This fixes: File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 480, in createalternatelocationresponseframe: unsupported operand type(s) for item assignment: bytes [unsupported-operands] No attribute '__setitem__' on bytes File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 510, in createcommanderrorresponse: unsupported operand type(s) for item assignment: bytes [unsupported-operands] No attribute '__setitem__' on bytes File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 776, in __init__: Can't find module 'mercurial.zstd'. [import-error] File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 804, in __init__: Can't find module 'mercurial.zstd'. [import-error] File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 834, in populatestreamencoders: Can't find module 'mercurial.zstd'. [import-error] Using `TypedDict` is tempting here to fix the first two, but requires str keys. The code doing the importing doesn't call the code at the other three locations if the `mercurial.zstd` module fails to import in a place that handles the ImportError.
Thu, 24 Oct 2024 22:47:31 -0400 wireprototypes: make `baseprotocolhandler` methods abstract
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Oct 2024 22:47:31 -0400] rev 52127
wireprototypes: make `baseprotocolhandler` methods abstract The documentation says it's an abstract base class, so let's enforce it. The `typing.Protocol` class is already an ABC, but it only prevents instantiation if there are abstract attrs that are missing. For example, from `hg debugshell`: >>> from mercurial import wireprototypes >>> x = wireprototypes.baseprotocolhandler() Traceback (most recent call last): File "<console>", line 1, in <module> TypeError: Can't instantiate abstract class baseprotocolhandler with abstract method name >>> class fake(wireprototypes.baseprotocolhandler): ... pass ... >>> x = fake() Traceback (most recent call last): File "<console>", line 1, in <module> TypeError: Can't instantiate abstract class fake with abstract method name That's great, but it doesn't protect against calling non-abstract methods at runtime, rather it depends on the protocol type hint being added to method signatures or class attrs, and then running a type checker to notice when an instance is assigned that doesn't conform to the protocol. We don't widely use type hints yet, and do have a lot of class hierarchy in the repository area, which could lead to surprises like this: >>> class fake(wireprototypes.baseprotocolhandler): ... @property ... def name(self) -> bytes: ... return b'name' ... >>> z = fake() >>> z.client() >>> print(z.client()) None Oops. That was supposed to return `bytes`. So not only is a bad/unexpected value returned, but it's one that violates the type hints (since the base client() method will be annotated to return bytes). With this change, we get: >>> from mercurial import wireprototypes >>> class fake(wireprototypes.baseprotocolhandler): ... @property ... def name(self) -> bytes: ... return b'name' ... >>> x = fake() Traceback (most recent call last): File "<console>", line 1, in <module> TypeError: Can't instantiate abstract class fake with abstract methods addcapabilities, checkperm, client, getargs, getpayload, getprotocaps, mayberedirectstdio So this looks like a reasonable safety harness to me, and lets us catch problems by running the standard tests while the type hints are being added, and pytype is improved. We should probably do this for all Protocol class methods that don't supply a method implementation.
Thu, 24 Oct 2024 22:37:45 -0400 wireprototypes: convert `baseprotocolhandler.name` to an abstract property
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Oct 2024 22:37:45 -0400] rev 52126
wireprototypes: convert `baseprotocolhandler.name` to an abstract property PyCharm was flagging the subclasses where this was declared as a `@property` with Type of 'name' is incompatible with 'baseprotocolhandler' But pytype didn't complain. This seems more correct, however. Since `Protocol` is already an `abc.ABCMeta` class, we don't need to mess with the class hierarchy.
Thu, 24 Oct 2024 20:50:47 -0400 wireprotoserver: subclass the new `baseprotocolhandler` Protocol class
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Oct 2024 20:50:47 -0400] rev 52125
wireprotoserver: subclass the new `baseprotocolhandler` Protocol class
Thu, 24 Oct 2024 20:47:12 -0400 wireprototypes: convert `baseprotocolhandler` to a Protocol class
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Oct 2024 20:47:12 -0400] rev 52124
wireprototypes: convert `baseprotocolhandler` to a Protocol class The methodology for doing this is now known, and this is limited to two implementing classes, so just make the changes.
Sat, 26 Oct 2024 12:56:02 +0200 test: stabilize `test-audit-path.t` in rust (hopefully)
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 26 Oct 2024 12:56:02 +0200] rev 52123
test: stabilize `test-audit-path.t` in rust (hopefully) We have been seeing flakiness on the file reported for a bit.
Sat, 26 Oct 2024 05:09:55 +0200 pycompat: drop test involving assigning "foo" to `sys.hexversion` stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 26 Oct 2024 05:09:55 +0200] rev 52122
pycompat: drop test involving assigning "foo" to `sys.hexversion` Starting with python 3.13, `sys.hexversion` refuse to be assigned non-hex value like "foo". I don't think I can blame it. It is time to drop that part of the tests.
Sat, 26 Oct 2024 05:11:58 +0200 pycompat: filter more of the traceback in `test-flagproccessor.t` stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 26 Oct 2024 05:11:58 +0200] rev 52121
pycompat: filter more of the traceback in `test-flagproccessor.t` The traceback changes again with 3.13. So we filter it to only keeps the bits we care about. This is actually only reusing the approach from a few line below.
Fri, 25 Oct 2024 00:46:22 +0200 pycompat: ignore the fork + thread warning for now stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 25 Oct 2024 00:46:22 +0200] rev 52120
pycompat: ignore the fork + thread warning for now No known issues has been reported and this is breaking the CI quite hard. So for now we have to delay the issue.
Thu, 24 Oct 2024 22:55:45 -0400 wireprototypes: fix exception handling code with a bad pytype suppression stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Oct 2024 22:55:45 -0400] rev 52119
wireprototypes: fix exception handling code with a bad pytype suppression This goes back to f5fcf7123a92, and I suspect it was a misread of the error message is describes- the LHS of `.sorted()` is always bytes, and bytes didn't have this method in py2 either. The invalid names were already handled like this a few lines above. PyCharm flagged this, and it stood out after converting the zope interfaces to Protocol classes (which hasn't been published yet).
Fri, 18 Oct 2024 14:14:24 -0400 tests: conditionalize undesired output on Windows for rbc the mmap cases
Matt Harbison <matt_harbison@yahoo.com> [Fri, 18 Oct 2024 14:14:24 -0400] rev 52118
tests: conditionalize undesired output on Windows for rbc the mmap cases I don't want to lose sight of this issue, and it's useful to be able to turn on mmap support to hack on the underlying problem. As noted in the previous commit, I think the current usage of `mmap` and `memoryview` needs to be reworked for correctness on posix anyway.
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 tip