Wed, 02 Nov 2022 12:54:12 -0400 packaging: refresh dependency hashes (issue6750) stable
Jason R. Coombs <jaraco@jaraco.com> [Wed, 02 Nov 2022 12:54:12 -0400] rev 49606
packaging: refresh dependency hashes (issue6750) Also, add some documentation to the `.in` files.
Wed, 16 Nov 2022 15:39:10 +0100 matcher: do not prepend '.*' to pattern using ^ after flags stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 16 Nov 2022 15:39:10 +0100] rev 49605
matcher: do not prepend '.*' to pattern using ^ after flags Since the previous commit (fixing wider issue), the code generated strange regex. This is now fixed and tested.
Wed, 16 Nov 2022 16:38:42 +0100 matcher: fix the issue with regex inline-flag in rust oo stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 16 Nov 2022 16:38:42 +0100] rev 49604
matcher: fix the issue with regex inline-flag in rust oo Same problem same solution.
Wed, 16 Nov 2022 13:05:01 +0100 matcher: fix issues regex flag contained in pattern (issue6759) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 16 Nov 2022 13:05:01 +0100] rev 49603
matcher: fix issues regex flag contained in pattern (issue6759) Python 3.11 is now enforcing that flag must be at the beginning of the regex This creates a serious regression for people using Python 3.11 with an hgignore using flag in a "relre" pattern. We now detect any flags in such pattern and "prepend" our ".*" pattern after them. In addition, we now insert the flag in the regexp to only affect the pattern we are rewriting. Otherwise, the regex built from the combined pattern would these flags in the middle of it anyway. As a side effect of this last change, we fix a bug… before this change regex flag in a pattern would affect all combined patterns. That was bad and is not longer the case. The Rust code needs to be updated to fix that very bug, but we will do it in another changeset.
Wed, 16 Nov 2022 14:40:27 +0100 release: removed the 6.3.0 tag stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 16 Nov 2022 14:40:27 +0100] rev 49602
release: removed the 6.3.0 tag The revision having two tags confuses some of the build script trying to fetch the version. So, remove the "bad" tag for now.
Tue, 08 Nov 2022 18:05:19 -0500 cffi: fix a bytes vs str issue on macOS when listing directories
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Nov 2022 18:05:19 -0500] rev 49601
cffi: fix a bytes vs str issue on macOS when listing directories This code hasn't been touched in recent years, and the other implementation return bytes for the filename, so I assume this is a holdover from the py2 days. I was unable to test it on mac though, because the `_osutil` import failed.
Tue, 08 Nov 2022 14:31:10 -0500 typing: fix the typehint for `skip` arg on `osutil.listdir()` to be optional
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Nov 2022 14:31:10 -0500] rev 49600
typing: fix the typehint for `skip` arg on `osutil.listdir()` to be optional The cffi and pure implementations both default to `None`, and the args are parsed in C with `"y#|OO:listdir"`, with the C variable initialized to NULL.
Tue, 08 Nov 2022 14:17:56 -0500 typing: add type hints to mpatch implementations
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Nov 2022 14:17:56 -0500] rev 49599
typing: add type hints to mpatch implementations Again, using `merge-pyi` to apply the stubs in cext and then manually type the private methods. The generated stub without these hints inferred very little, and the stuff it did was wrong.
Tue, 08 Nov 2022 13:59:16 -0500 typing: add type hints to bdiff implementations
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Nov 2022 13:59:16 -0500] rev 49598
typing: add type hints to bdiff implementations Not super important code, but this was an exercise in using `merge-pyi` to fold type stubs back into the code on something small. The cext stubs don't seem to be getting used (at least the only thing in `.pytype/pyi/mercurial/cext` after a run generating the stubs is `__init__.pyi`), so maybe this will help some.
Tue, 08 Nov 2022 13:52:46 -0500 cffi: adjust the list returned by bdiff.blocks to never have a None entry
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Nov 2022 13:52:46 -0500] rev 49597
cffi: adjust the list returned by bdiff.blocks to never have a None entry This was flagged by pytype after merging the corresponding bdiff.pyi in cext: File ".../mercurial/cffi/bdiff.py", line 44, in blocks: bad return type [bad-return-type] Expected: List[Tuple[int, int, int, int]] Actually returned: List[None] AFAICT, all callers immediately unpack the tuple into 4 variables, so a `None` entry would simply crash if they aren't all overwritten. As long a `count` and the link list are consistent, this shouldn't be a problem. This placates both pytype and PyCharm (which complained about the `i` in `rl[i]` having the wrong type with the old code).
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip