Matt Harbison <matt_harbison@yahoo.com> [Sat, 28 Sep 2024 19:11:39 -0400] rev 51932
mdiff: tweak calls into `bdiff.fixws` to match its type hints
It turns out that protocol classes can be used for modules too, which is great
because all of the dynamically loaded modules (and their attributes) are
currently inferred as `Any`. See the next commit for details.
A protocol class for the `bdiff` module detected this (trivial) mismatch, so
correct it first. The various implementations of this method are typed as
taking a `bool`. The `cext` implementation parses its arguments with
`PyArg_ParseTuple(args, "Sb:fixws", &s, &allws)`, which wants an `int`. But
experimenting in `hg debugshell` under py38, passing `True` or `False` to
`cext.fixws()` also works. We can change the implementation to use "p" (which
was introduced in py33) instead of "b", but that's beyond the scope of this.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 01 Oct 2024 15:04:06 -0400] rev 51931
util: minor copy editing of the documentation for `mmapread()`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 01 Oct 2024 15:00:39 -0400] rev 51930
util: make `mmapread()` work on Windows again
522b4d729e89 started referencing `mmap.MAP_PRIVATE`, but that's not available on
Windows, so `hg version` worked, but `make local` did not. That commit also
started calling the constructor with the fine-grained `flags` and `prot` args,
but those aren't available on Windows either[1] (though the backing C code
doesn't seem conditionalized to disallow usage of them).
I assume the change away from from the `access` arg was to provide the same
options, plus `MAP_POPULATE`. Looking at the source code[2], they're not quite
the same- `ACCESS_READ` is equivalent to `flags = MAP_SHARED` and `prot = PROT_READ`.
`MAP_PRIVATE` is only used with `ACCESS_COPY`, which allows read and write.
Therefore, we can't quite get the same baseline flags on Windows, but this was
the status quo ante and `MAP_POPULATE` is a Linux thing, so presumably it works.
I realize that typically the OS differences are abstracted into the platform
modules, but I'm leaving it here so that it is obvious what the differences are
between the platforms.
[1] https://docs.python.org/3/library/mmap.html#mmap.mmap
[2] https://github.com/python/cpython/blob/
5e0abb47886bc665eefdcc19fde985f803e49d4c/Modules/mmapmodule.c#L1539
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Sep 2024 12:30:37 -0400] rev 51929
typing: add type annotations to the dirstate classes
The basic procedure here was to use `merge-pyi` to merge the `git/dirstate.pyi`
file in (after renaming the interface class to match), cleaning up the import
statement mess, and then repeating the procedure for `mercurial/dirstate.pyi`.
Surprisingly, git's dirstate had more hints inferred in its *.pyi file.
After that, it was a manual examination of each method in the interface, and how
they were implemented in the core and git classes to verify what was inferred by
pytype, and fill in the missing gaps. Since this involved jumping around
between three different files, I applied the same type info to all three at the
same time. Complex types I rolled up into type aliases in the interface module,
and used that as needed. That way if it changes, there's one place to edit.
There are some hints still missing, and some documentation that doesn't match
the signatures. They should all be marked with TODOs. There are also a bunch
of methods on the core class that aren't on the Protocol class that seem like
maybe they should be (like `set_tracked()`). There are even more methods
missing from the git class. But that's a project for another time.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Sep 2024 12:10:25 -0400] rev 51928
interfaces: change a couple of dirstate fields to `@property`
As I was adding type hints here and to the concrete classes, PyCharm flagged the
property in the core class as not being compatible with the base class's
version.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Sep 2024 12:05:48 -0400] rev 51927
git: make `dirstate.parents()` return a list like the core class
The core class returned a list, so that's how I type annotated it, and this got
flagged. I suppose we could annotate it as a `Sequence[bytes]`, but it's a
trivial difference.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Sep 2024 11:57:42 -0400] rev 51926
typing: add type hints for the overloads of `matchmod.readpatternfile()`
The return type is conditional on an argument passed, and it very much confused
both pytype and PyCharm inside `dirstate._ignorefileandline()` after adding
type hints for the return value there.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:52:46 -0400] rev 51925
dirstate: subclass the new dirstate Protocol class
Behold the chaos that ensues. We'll use the generated *.pyi files to apply type
annotations to the interface, and see how much agrees with the documentation.
Since the CamelCase name was used to try to work around pytype issues with zope
interfaces and is a new innovation this cycle (see
c1d7ac70980b), drop the
CamelCase name. I think the Protocol classes *should* be CamelCase, but that
can be done later in one pass. For now, the CamelCase alias is extra noise in
the *.pyi files.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:51:03 -0400] rev 51924
git: correct some signature mismatches between dirstate and the Protocol class
These were flagged by PyCharm when subclassing the Protocol class. Note that
both `is_changing_xxx` were only flagged when the Protocol class used a plain
field, as mentioned in the previous commit. After converting those attrs in the
Protocol class to @property to match the regular dirstate class, it stopped
flagging these. But I don't think that makes sense- `@property` should look
like an attribute to the outside world, not a callable.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Sep 2024 18:15:36 -0400] rev 51923
interfaces: convert the zope `Attribute` attrs to regular fields
At this point, we should have a useful protocol class.
The file syntax requires the type to be supplied for any fields that are
declared, but we'll leave the complex ones partially unspecified for now, for
simplicity. (Also, the things documented as `Callable` are really as future
type annotating worked showed- roll with it for now, but they're marked as TODO
for fixing later.) All of the fields and all of the attrs will need type
annotations, or the type rules say they are considered to be `Any`. That can be
done in a separate pass, possibly applying the `dirstate.pyi` file generated
from the concrete class.
The first cut of this turned the `interfaceutil.Attribute` fields into plain
fields, and thus the types on them. PyCharm flagged a few things as having
incompatible signatures when the concrete dirstate class subclassed this, when
the concrete class has them declared as `@property`. So they've been changed to
`@property` here in those cases. The remaining fields that are decorated in the
concrete class have comments noting the differences. We'll see if they need to
be changed going forward, but leave them for now. We'll be in trouble if the
`@util.propertycache` is needed, because we can't import that module here at
runtime, due to circular imports.