Mon, 26 Jun 2023 21:31:41 +0200 tests: use packaging from setuptools instead of deprecated distutils
Mads Kiilerich <mads@kiilerich.com> [Mon, 26 Jun 2023 21:31:41 +0200] rev 51803
tests: use packaging from setuptools instead of deprecated distutils When invoking StrictVersion in 3.12 we got: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. distutils is dead in the standard library, and we have to move towards using `setuptools` as general extern dependency. Instead of also requiring the extern `packaging`, we will just use the packaging that is vendored in setuptools.
Mon, 26 Jun 2023 15:16:51 +0200 tests: drop test-demandimport.py distutils test that failed with warnings
Mads Kiilerich <mads@kiilerich.com> [Mon, 26 Jun 2023 15:16:51 +0200] rev 51802
tests: drop test-demandimport.py distutils test that failed with warnings The test would fail because warnings: /usr/lib/python3.11/site-packages/_distutils_hack/__init__.py:18: UserWarning: Distutils was imported before Setuptools, but importing Setuptools also replaces the `distutils` module in `sys.modules`. This may lead to undesirable behaviors or errors. To avoid these issues, avoid using distutils directly, ensure that setuptools is installed in the traditional way (e.g. not an editable install), and/or make sure that setuptools is always imported before distutils. warnings.warn( /usr/lib/python3.11/site-packages/_distutils_hack/__init__.py:33: UserWarning: Setuptools is replacing distutils. warnings.warn("Setuptools is replacing distutils.") The test for distutils.msvc9compiler comes from 2205d00b6d2b. But since then, distutils is going away, and this test must change somehow. It is unclear exactly how setuptools depended on msvc9compiler, but setuptools also moved forward, and this exact test no longer seems relevant. It thus seems like a fair solution to remove the test while keeping the demandimport blacklist of distutils.msvc9compiler.
Thu, 29 Jun 2023 20:02:27 +0200 utils: test coverage of makedate
Mads Kiilerich <mads@kiilerich.com> [Thu, 29 Jun 2023 20:02:27 +0200] rev 51801
utils: test coverage of makedate Explore the scenario from ae04af1ce78d to avoid future regressions. This was intended to give some coverage of the change in faccec1edc2c.
Tue, 09 Jul 2024 20:08:48 +0200 mmap: populate mapping in a background thread
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Jul 2024 20:08:48 +0200] rev 51800
mmap: populate mapping in a background thread When possible, we populate the memory mapping in a second thread. The mmap population does not only read the data from disk to memory. It also actually fill the memory mapping between process memory address and the physical memory used by the file system cache containing the mmap'ed data. Doing so buy back the slowdown from pre-population when it matters. When most data is accessed, only a few page fault will occurs, while the background thread fill the memory controller. When few data is accessed, the non-blocking mmap won't have to wait for all data to be populated. Here is a few example of improvement seen in benchmark around unbundle and push: ### data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog # benchmark.name = hg.command.unbundle # benchmark.variants.issue6528 = disabled # benchmark.variants.reuse-external-delta-parent = yes # benchmark.variants.revs = any-100-extra-rev before: 0.758101 after: 0.732129 (-3.43%, -0.03) ## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog before: 1.519941 after: 1.503473 (-1.08%, -0.02) ### data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog # benchmark.name = hg.command.push # bin-env-vars.hg.flavor = default # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.reuse-external-delta-parent = yes # benchmark.variants.revs = any-1-extra-rev before: 4.801442 after: 4.695810 (-1.46%, -0.07) # benchmark.variants.revs = any-100-extra-rev before: 4.848596 after: 4.794075 (-1.12%, -0.05) # bin-env-vars.hg.flavor = rust # benchmark.variants.revs = any-1-extra-rev before: 4.818410 after: 4.700053 (-2.46%, -0.12)
Thu, 25 Jul 2024 14:40:38 -0400 pure: stringify builtin exception messages
Matt Harbison <matt_harbison@yahoo.com> [Thu, 25 Jul 2024 14:40:38 -0400] rev 51799
pure: stringify builtin exception messages Builtin exceptions usually want strings, and display with a wierd b'' prefix if given bytes.
Mon, 29 Jul 2024 12:10:08 -0400 httppeer: avoid another bad reference before assignment warning
Matt Harbison <matt_harbison@yahoo.com> [Mon, 29 Jul 2024 12:10:08 -0400] rev 51798
httppeer: avoid another bad reference before assignment warning This wasn't a problem, because `b''` from the `AttributeError` handler is in `bundle2.bundletypes`, so the following loop and conditional always run at least once. But PyCharm can't figure that out on its own, and it took a little exploring to figure out it wasn't a problem. The usage in `bundle2.writebundle` is to look it up in the map of bundle types, so it will break in a more obvious way in the unlikely event that the empty string is removed from the map in the future.
Fri, 26 Jul 2024 21:59:34 -0400 httppeer: move a variable to avoid a bad reference before assignment warning
Matt Harbison <matt_harbison@yahoo.com> [Fri, 26 Jul 2024 21:59:34 -0400] rev 51797
httppeer: move a variable to avoid a bad reference before assignment warning No actual bug here, because the conditional used to assign is the same as the conditional in the `finally` block that guards the reference.
Fri, 26 Jul 2024 21:54:07 -0400 httppeer: simplify two-way stream cleanup
Matt Harbison <matt_harbison@yahoo.com> [Fri, 26 Jul 2024 21:54:07 -0400] rev 51796
httppeer: simplify two-way stream cleanup No need to conditionalize the cleanup if the filename is assigned outside the exception handler. I suppose `fd` leaks if `os.fdopen()` fails, but that was the case before too (and may trigger another exception in the `finally` block on Windows, when the file is still open).
Mon, 29 Jul 2024 10:07:53 +0200 rustfmt: update expected Rust edition
Raphaël Gomès <rgomes@octobus.net> [Mon, 29 Jul 2024 10:07:53 +0200] rev 51795
rustfmt: update expected Rust edition In this case it doesn't change anything, but we've been using 2021 for a while now.
Mon, 29 Jul 2024 10:04:00 +0200 hghave: update expected rustfmt version
Raphaël Gomès <rgomes@octobus.net> [Mon, 29 Jul 2024 10:04:00 +0200] rev 51794
hghave: update expected rustfmt version We still use nightly, but have moved to a newer nightly after the last CI image upgrade in 74f1bf147a6d and 3876d4c6c79e.
Mon, 29 Jul 2024 10:06:28 +0200 rustfmt: apply formatting expected by newer nightly version
Raphaël Gomès <rgomes@octobus.net> [Mon, 29 Jul 2024 10:06:28 +0200] rev 51793
rustfmt: apply formatting expected by newer nightly version This was missed in 3876d4c6c79ec5c71e8c51b876cc157e93a5eaac somehow.
Thu, 25 Jul 2024 15:56:04 -0400 tests: stop skipping `mercurial/pure/osutil.py` during pytype runs
Matt Harbison <matt_harbison@yahoo.com> [Thu, 25 Jul 2024 15:56:04 -0400] rev 51792
tests: stop skipping `mercurial/pure/osutil.py` during pytype runs Not sure when the original issue(s) were fixed, but it works for me now.
Thu, 25 Jul 2024 13:31:13 -0400 largefiles: avoid a potentially undefined variable in exception case
Matt Harbison <matt_harbison@yahoo.com> [Thu, 25 Jul 2024 13:31:13 -0400] rev 51791
largefiles: avoid a potentially undefined variable in exception case The `wlock` variable is used to release the lock in the `finally` block, so it would be undefined if `repo.wlock()` itself failed. Caught by pytype 2024.04.11 with py3.10.11.
Wed, 24 Jul 2024 22:40:22 -0400 typing: add trivial type hints to `mercurial.scmutil`
Matt Harbison <matt_harbison@yahoo.com> [Wed, 24 Jul 2024 22:40:22 -0400] rev 51790
typing: add trivial type hints to `mercurial.scmutil` There's still a lot to go, but there's a lot here already, so I tried to keep it to obvious/trivial things. I didn't bother with contexts, matchers, and revisions that can be `bytes | int | None`.
Wed, 24 Jul 2024 18:17:00 -0400 typing: narrow the scope of some recent disabled import warnings
Matt Harbison <matt_harbison@yahoo.com> [Wed, 24 Jul 2024 18:17:00 -0400] rev 51789
typing: narrow the scope of some recent disabled import warnings These comments were added in 39e2b2d062c1, but had the effect of changing the known type to `Any`, which cascaded through a few function signatures. Just ignore the import error instead.
Tue, 23 Jul 2024 19:20:22 -0400 typing: induce pytype to use the standard `attr` instead of the vendored copy
Matt Harbison <matt_harbison@yahoo.com> [Tue, 23 Jul 2024 19:20:22 -0400] rev 51788
typing: induce pytype to use the standard `attr` instead of the vendored copy What was previously happening with the vendored copy was that pytype would stub out all(?) classes that were decorated with `@attr.s` as `Any`. After this, we get a ton of classes defined, and numerous fields and methods now have proper types.
Tue, 23 Jul 2024 19:14:16 -0400 typing: disable some pytype errors in `mercurial.store`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 23 Jul 2024 19:14:16 -0400] rev 51787
typing: disable some pytype errors in `mercurial.store` These seem to be legitimate errors, since one of the two callers (`encodedstore.data_entries()`) was previously typed to generate `BaseStoreEntry`. However, that and the other caller only pass `RevlogStoreEntry` objects. I can't tell if this was a WIP or what, but don't want to get side tracked on this. So flag as a TODO for later.
Tue, 23 Jul 2024 19:05:26 -0400 linelog: correct the default value of `annotateresult.lines`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 23 Jul 2024 19:05:26 -0400] rev 51786
linelog: correct the default value of `annotateresult.lines` This was flagged by pytype once it was tricked into using the standard `attr` package instead of the vendored copy.
Tue, 23 Jul 2024 19:01:16 -0400 phabricator: correct the default value of `phabhunk.corpus`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 23 Jul 2024 19:01:16 -0400] rev 51785
phabricator: correct the default value of `phabhunk.corpus` There's only one caller to this constructor (which does provide this argument), and no direct assignments, so there's no runtime bug here. However, when pytype is tricked into using the standard `attr` package instead of the vendored version, it flags this because bytes is passed to the one constructor invocation. Tricking pytype into using the standard package will generate many more type hints, noteably around `@attr.s` decorated things.
Mon, 22 Jul 2024 18:20:29 +0200 rust-changelog: accessing the index
Georges Racinet <georges.racinet@cloudcrane.io> [Mon, 22 Jul 2024 18:20:29 +0200] rev 51784
rust-changelog: accessing the index The `Index` object is currently the one providing all DAG related algorithms, starting with simple ancestors iteration up to more advanced ones (ranges, common ancestors…). From pure Rust code, there was no way to access the changelog index for a given `Repository`, probably because `rhg` does not use any such algorithm yet.
Sat, 20 Jul 2024 17:03:30 -0400 typing: add type hints to `mercurial.policy`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 20 Jul 2024 17:03:30 -0400] rev 51783
typing: add type hints to `mercurial.policy` Mostly trivial, but this seems like the logical module to use to inject the hints from `cext`, `pure`, etc, given that this file has the fallback policy. This is a first step. There doesn't appear to be a predefined type for a module in py3.7, so those are omitted for now.
Sat, 20 Jul 2024 01:55:09 -0400 cext: correct the argument handling of `b85encode()`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 20 Jul 2024 01:55:09 -0400] rev 51782
cext: correct the argument handling of `b85encode()` The type stub indicated that this argument is `Optional`, which implies None is allowed. I don't see in the documentation where that's the case for `i`[1], and trying it in `hg debugshell` resulted in the method failing with a TypeError. I guess it was typed as an `int` argument because the `p` format unit wasn't added until Python 3.3[2]. In any event, 2 clients in core (`pvec` and `obsolete`) call this with no argument supplied, and `mdiff` calls it with True. So I guess we've avoided the None arg case, and when no arg is supplied, it defaults to the 0 initialization of the `pad` variable in C. Since the `p` format unit accepts both `int` and None, as well as `bool`, I'm not bothering to bump the module version- this code is more permissive than it was, in addition to being more correct. Interestingly, when I first imported the `cext` and `pure` methods in the same manner as the previous commit, it dropped the `Optional` part of the argument type when generating `util.pyi`. No idea why. [1] https://docs.python.org/3/c-api/arg.html#numbers [2] https://docs.python.org/3/c-api/arg.html#other-objects
Fri, 19 Jul 2024 20:09:48 -0400 typing: add type hints to the `charencode` module
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Jul 2024 20:09:48 -0400] rev 51781
typing: add type hints to the `charencode` module Since this module is dynamically imported from either `mercurial.pure` or `mercurial.cext`, these hints aren't detected in `mercurial.encoding`, and need to be imported directly there during the type-checking phase. This keeps the runtime selection via the policy config in place, but allows pytype to see these as functions with proper signatures instead of just `Any`. We don't attempt to import the `mercurial.cext` version yet because there's no types stubs for that module, but this will get the ball rolling. I thought this would spill over into other modules from there, but the only two *.pyi files that changed were for `encoding` and `charencode`. Applying this to other dynamically selected modules will clean some things up in other files, so this is a start. I had originally redefined the functions in the type-checking block (like some of the `os.path` aliasing in `mercurial.util`), but this is better because we won't have another duplication of the definitions that may get out of date.
Fri, 19 Jul 2024 16:49:46 -0400 typing: explicitly type some `mercurial.util` eol code to avoid @overload
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Jul 2024 16:49:46 -0400] rev 51780
typing: explicitly type some `mercurial.util` eol code to avoid @overload Unlike the previous commit, this makes a material difference in the generated stub file- the `pycompat.identity()` aliases generated an @overload like this: @overload def fromnativeeol(a: _T0) -> _T0: ... ... which might fail to detect a bad argument, like str. This drops the @overload for the 3 related methods, so there's a single definition for each. The `typelib.BinaryIO_Proxy` is used for subclassing (the same as was done in 8147abc05794), so that it is a `BinaryIO` type during type checking, but still inherits `object` at runtime. That way, we don't need to implement unused abstract methods.
Fri, 19 Jul 2024 16:38:53 -0400 typing: avoid some useless @overload definitions in `mercurial.util`
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Jul 2024 16:38:53 -0400] rev 51779
typing: avoid some useless @overload definitions in `mercurial.util` Apparently pytype considered the name as well as the type of each argument, and generates @overload definitions if they don't match. At best this is clutter, and can easily be removed.
Thu, 18 Jul 2024 22:46:36 -0400 dirstate: stringify a few exception messages
Matt Harbison <matt_harbison@yahoo.com> [Thu, 18 Jul 2024 22:46:36 -0400] rev 51778
dirstate: stringify a few exception messages Built in exceptions want str, and ProgrammingError converts bytes to str internally (because it subclasses RuntimeError).
Thu, 18 Jul 2024 20:34:35 -0400 typing: add type hints to `mercurial.verify._normpath()`
Matt Harbison <matt_harbison@yahoo.com> [Thu, 18 Jul 2024 20:34:35 -0400] rev 51777
typing: add type hints to `mercurial.verify._normpath()` Since 10db46e128d4, pytype almost figured this out, going from `Any` -> `_T0`, but the intent is obvious.
Thu, 18 Jul 2024 20:16:31 -0400 typing: add type hints to `i18n._msgcache`
Matt Harbison <matt_harbison@yahoo.com> [Thu, 18 Jul 2024 20:16:31 -0400] rev 51776
typing: add type hints to `i18n._msgcache` Since 10db46e128d4, pytype stopped inferring that the key is bytes.
Thu, 18 Jul 2024 19:57:42 -0400 typing: add type hints to `mercurial.dirstatemap`
Matt Harbison <matt_harbison@yahoo.com> [Thu, 18 Jul 2024 19:57:42 -0400] rev 51775
typing: add type hints to `mercurial.dirstatemap` Somewhere since 10db46e128d4, pytype stopped being able to infer the type of the `identity` field. Fill in some obvious other hints along the way. These hints caused pytype to flag a missing attribute: File "/mnt/c/Users/Matt/hg/mercurial/dirstatemap.py", line 714, in _v1_map: No attribute 'stat' on mercurial.windows.cachestat [attribute-error] In Union[Any, mercurial.posix.cachestat, mercurial.windows.cachestat] File "/mnt/c/Users/Matt/hg/mercurial/dirstatemap.py", line 715, in _v1_map: No attribute 'stat' on mercurial.windows.cachestat [attribute-error] In Union[Any, mercurial.posix.cachestat, mercurial.windows.cachestat] In practice, the `identity` field is NOT replaced with None if it isn't cacheable, so it's probably safer to just add the field and set it to None, since that check is already in place on line 715.
Thu, 18 Jul 2024 19:55:51 -0400 typing: add type hints to `cmdutil.findrepo()`
Matt Harbison <matt_harbison@yahoo.com> [Thu, 18 Jul 2024 19:55:51 -0400] rev 51774
typing: add type hints to `cmdutil.findrepo()` Since 10db46e128d4, pytype almost figured this out, going from `Any` -> `_T0`, but the intent is obvious.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 tip