Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 06 Nov 2022 14:47:17 -0500] rev 49772
delta-find: add a way to control the number of bases tested at the same time
See inline comment for details.
The feature is currently disabled, but should be enabled by default to mitigate
some existing pathological cases.
Also see the next changeset for details.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 21:11:46 -0500] rev 49771
setup: include vendored 3rd party type stubs
While pytype may not support PEP 561, PyCharm does, so having the stubs
available means it can determine `foo = attr.ib(type=int)` means `foo` is an
int. This only applies when using Mercurial as a library, like with TortoiseHg
development- PyCharm is already smart enough to use the *.pyi files in the
Mercurial source tree when hacking on Mercurial itself.
I left the mercurial.cext stubs out because it seems very low level, that 3rd
parties shouldn't be using directly.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 20:59:53 -0500] rev 49770
ci: bump pytype to 2022.11.18
No particular reason, other than the current build is fairly old. It flagged a
few more things (that weren't errors based on the logic around them), but OTOH,
some of the pyi stubs it generates are less specific.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 20:56:22 -0500] rev 49769
ci: run the script to add vendored type stubs to typeshed
Since CI runs from docker images, it doesn't matter that this mucks with the
typeshed bundled with pytype.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 20:50:39 -0500] rev 49768
contrib: add a script for adding vendored type stubs to typeshed
I really hate this, but pytype doesn't support PEP 561 and doesn't seem to have
the equivalent of `MYPYPATH` to point to custom stubs. Ignoring the vendored
stubs isn't necessarily harmful, but pytype has been choking on the vendored
attr package after pytype 2022.03.29 with errors like this:
File "/mnt/c/Users/Matt/hg/mercurial/linelog.py", line 52, in __iter__: Built-in function iter was called with the wrong arguments [wrong-arg-types]
Expected: (collection: bytearray)
Actually passed: (collection: mercurial.thirdparty.attr._make._CountingAttr)
File "/mnt/c/Users/Matt/hg/mercurial/dirstateutils/v2.py", line 143, in pack: Built-in function len was called with the wrong arguments [wrong-arg-types]
Expected: (obj: Sized)
Actually passed: (obj: mercurial.thirdparty.attr._make._CountingAttr)
Attributes of protocol Sized are not implemented on mercurial.thirdparty.attr._make._CountingAttr: __len__
File "/mnt/c/Users/Matt/hg/mercurial/dirstateutils/v2.py", line 144, in pack: No attribute 'rfind' on mercurial.thirdparty.attr._make._CountingAttr [attribute-error]
File "/mnt/c/Users/Matt/hg/mercurial/dirstateutils/v2.py", line 146, in pack: Built-in function len was called with the wrong arguments [wrong-arg-types]
Expected: (obj: Sized)
Actually passed: (obj: mercurial.thirdparty.attr._make._CountingAttr)
Attributes of protocol Sized are not implemented on mercurial.thirdparty.attr._make._CountingAttr: __len__
File "/mnt/c/Users/Matt/hg/mercurial/dirstateutils/v2.py", line 152, in pack: No attribute 'v2_data' on mercurial.thirdparty.attr._make._CountingAttr [attribute-error]
File "/mnt/c/Users/Matt/hg/mercurial/util.py", line 2817, in go: unsupported operand type(s) for /: 'count: mercurial.thirdparty.attr._make._CountingAttr' and 'float: float' [unsupported-operands]
No attribute '__truediv__' on 'count: mercurial.thirdparty.attr._make._CountingAttr' or '__rtruediv__' on 'float: float'
Called from (traceback):
line 2981, in __bytes__
This is essentially the same hack we've been using in TortoiseHg to add the
vendored PyQt5 stubs. What I don't understand is pytype *still* generates *.pyi
files under .pytype/pyi/mercurial/thirdparty/attr, even when the package is
explicitly ignored in the pytype command line args. But it avoids the errors,
which means we aren't stuck on pytype==2022.03.29.
https://github.com/google/pytype/issues/151
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 20:23:26 -0500] rev 49767
contrib: update check-pytype.sh to list stubs that caused pytype to crash
The same logic is in the TortoiseHg tests for running pytype, and it's useful to
know if a new version of pytype is better or worse.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 16:11:20 -0500] rev 49766
typing: add py.typed to mercurial.cext for PEP 561 support
Unfortunately, pytype doesn't support this yet. But it was included with the
attr package, so we might as well do it here for consistency. Unlike the attr
package, these type hints are only partial, so they are marked as such[1] (but
who knows if it matters, given these are C extensions, so no local source code
to scan).
[1] https://peps.python.org/pep-0561/#partial-stub-packages
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 15:50:20 -0500] rev 49765
typing: add missing signature for mercurial.cext.parsers.parse_index2()
Flagged by pytype 2022.11.18 when the cext stubs are made visible to it. There
are very likely other signatures that are missing, but this is enough to keep it
happy for now.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 23 Nov 2022 11:22:22 -0500] rev 49764
typing: minor tweaks to allow updating to pytype 2022.11.18
Matt Harbison <matt_harbison@yahoo.com> [Sun, 20 Nov 2022 22:54:43 -0500] rev 49763
typing: add type hints to mercurial/help.py
Was hoping to find more issues like f09bc2ed9100, but it may be that nothing
checks the args to that operation. In any event, the work is done and pytype
doesn't do a very good job inferring the types. A few of th emore complicated
things like the command table are left untyped, because they come from modules
that aren't typed yet.
Matt Harbison <matt_harbison@yahoo.com> [Sun, 20 Nov 2022 23:09:12 -0500] rev 49762
configitems: add a default value for "merge-tools.xxx.regappend"
When trying to figure out how `hg help -v` took the Set interpolation path in
f09bc2ed9100, I turned on devel warnings and noticed this (unrelated) warning:
devel-warn: specifying a mismatched default value for a registered config
item: 'merge-tools.beyondcompare4.regappend' ''
at: c:\Users\Matt\hg\mercurial\filemerge.py:46 (_toolstr)
The previous default value for this config was `None`, but that slightly
complicates the code at the only site it is used, referenced above.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 21 Nov 2022 15:04:42 -0500] rev 49761
attr: vendor 22.1.0
The previous version was 5 years old, and pytype 2022.06.30 started complaining
about various uses (e.g. seeing `mercurial.thirdparty.attr._make._CountingAttr`
instead of `bytearray`). Hopefully this helps. Additionally, this has official
python 3.11 support.
The `attrs` package is left out, because it is simply a bunch of *.pyi stubs and
`from attr.X import *`, and that's not how they've been used up to this point.
We'd probably need to customize those anyway to
`from mercurial.thirdparty.attr import *`.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 21 Nov 2022 16:18:28 -0500] rev 49760
tests: update test-util.py for modern attrs package
When updating to 22.1.0, this test started failing:
Traceback (most recent call last):
File "/tmp/mercurial-ci/tests/test-util.py", line 53, in <module>
_start_default = (util.timedcmstats.start.default, 'factory')
AttributeError: type object 'timedcmstats' has no attribute 'start'
Poking around in `hg debugshell`, the attribute is indeed missing, but looks to
be attached to `__attrs_attrs__` in both the currently vendored and the modern
version of attrs. The old attrs packages will print the same for both accesses,
so fingers crossed...
>>> print((util.timedcmstats.start.default, 'factory'))
(Factory(factory=<function timedcmstats.<lambda> at 0x000001EFDF0F21F0>, takes_self=False), 'factory')
>>> print((util.timedcmstats.__attrs_attrs__.start.default, 'factory'))
(Factory(factory=<function timedcmstats.<lambda> at 0x000001EFDF0F21F0>, takes_self=False), 'factory')
Raphaël Gomès <rgomes@octobus.net> [Tue, 15 Nov 2022 01:52:46 +0100] rev 49759
rhg: upgrade the remainder of the dependencies
These are painless, so they are all grouped in this changeset.
Raphaël Gomès <rgomes@octobus.net> [Tue, 15 Nov 2022 00:02:43 +0100] rev 49758
rhg: upgrade `clap` dependency
This one is the worst one to upgrade since v2 -> v4 broke a ton of API,
which thankfully seems saner now.
Contrary to what was done in the `hg-core/src/examples/nodemap` rewrite,
we're not switching from the "builder" pattern to the "derive" pattern,
since that would imply a much larger diff. It can be done incrementally.
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 17:18:56 +0100] rev 49757
hg-cpython: upgrade dependencies
`hg-cpython` has no BC breaking dependencies, we can group them all
in this changeset.
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 17:17:04 +0100] rev 49756
hg-core: upgrade all remaining dependencies
Finally, these dependencies do not require any code changes, so they are
all grouped in the same changeset.
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 17:14:20 +0100] rev 49755
hg-core: upgrade `clap` dependency
Upgrading is a finally possible now that we're supporting a more recent
version of Rust.
This required changes in the `nodemap` example.
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 16:35:57 +0100] rev 49754
hg-core: upgrade `zstd` dependency
Now that we support a newer version of Rust, we can update this dependency
to get all the latest bugfixes and improvements.
A slight API adjustment was needed.
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 15:43:05 +0100] rev 49753
hg-core: make use of `strip_suffix` now that we're using Rust 1.45+
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 15:34:51 +0100] rev 49752
rust: use `matches!` macro now that we're using Rust 1.42+
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 15:31:49 +0100] rev 49751
hg-core: remove unneeded util now that we support Rust 1.42+
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 15:29:58 +0100] rev 49750
hg-core: remove unneeded trait now that we support Rust 1.52+
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 15:20:48 +0100] rev 49749
rust: remove newly redundant `use` statements with the 2021 edition prelude
https://doc.rust-lang.org/edition-guide/rust-2021/prelude.html
Raphaël Gomès <rgomes@octobus.net> [Mon, 14 Nov 2022 15:19:27 +0100] rev 49748
rust: move all crates in the main workspace to edition 2021
We've changed our minimum Rust version to 1.61.0 in the previous patch,
and edition 2021 predates that version.
Raphaël Gomès <rgomes@octobus.net> [Thu, 20 Oct 2022 12:26:57 +0200] rev 49747
rust: upgrade supported Rust toolchain version
A few months ago¹, a decision was made to move the Rust toolchain target to
whatever Debian Testing was tracking. I didn't have the bandwidth to act on
it until now.
This is starting to be even more problematic than before, now that edition 2021
is out.
The CI has been updated to track the current Debian testing version, 1.61.0.
[1] https://lists.mercurial-scm.org/pipermail/mercurial-packaging/2022-April/000338.html
Raphaël Gomès <rgomes@octobus.net> [Sat, 19 Nov 2022 20:40:47 +0100] rev 49746
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 19 Nov 2022 16:43:02 +0100] rev 49745
tests: fix test-sparse-revlog
This one is not covered by the CIbecause I requires an expensive artifact to be
cached. So it goes out of think on regular basis (we should fix that…)
The test ouput was affected by e706bb41fdb3 as we filtering now happens sooner,
removing for the output.