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).
Matt Harbison <matt_harbison@yahoo.com> [Fri, 25 Oct 2024 23:46:20 -0400] rev 52131
tests: enable pytype checking on `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.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 25 Oct 2024 23:09:10 -0400] rev 52129
tests: enable pytype checking on `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.
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.
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.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 24 Oct 2024 20:50:47 -0400] rev 52125
wireprotoserver: subclass the new `baseprotocolhandler` 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.
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.
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.
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.
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.
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).
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.