Thu, 18 Jul 2024 13:35:39 +0200 rust: apply clippy lints
Raphaël Gomès <rgomes@octobus.net> [Thu, 18 Jul 2024 13:35:39 +0200] rev 51693
rust: apply clippy lints They are at most harmless and at best make the codebase more readable and simpler.
Thu, 18 Jul 2024 12:38:26 +0200 rustfmt: format the codebase with nightly-2024-07-16
Raphaël Gomès <rgomes@octobus.net> [Thu, 18 Jul 2024 12:38:26 +0200] rev 51692
rustfmt: format the codebase with nightly-2024-07-16 The CI has moved to a newer nightly, which slightly changes how it wraps comments (which is the very option we use nightly for).
Thu, 18 Jul 2024 12:37:13 +0200 hghave: update detection of black version to a newer minimum
Raphaël Gomès <rgomes@octobus.net> [Thu, 18 Jul 2024 12:37:13 +0200] rev 51691
hghave: update detection of black version to a newer minimum The CI has moved to version 23.3.0, which is the last one to support 3.7 at runtime.
Thu, 18 Jul 2024 12:36:12 +0200 black: format the codebase with 23.3.0
Raphaël Gomès <rgomes@octobus.net> [Thu, 18 Jul 2024 12:36:12 +0200] rev 51690
black: format the codebase with 23.3.0 The CI has moved to 23.3.0, which is the last version that supports 3.7 at runtime, so we should honor this change. # skip-blame mass-reformating only
Thu, 18 Jul 2024 12:03:29 +0200 pytype: work around wrong ImportError flagging
Raphaël Gomès <rgomes@octobus.net> [Thu, 18 Jul 2024 12:03:29 +0200] rev 51689
pytype: work around wrong ImportError flagging As documented in https://github.com/google/pytype/issues/163, newer versions of Pytype do not understand caught `ImportError`, so we temporarily ignore them where applicable.
Thu, 18 Jul 2024 12:02:01 +0200 zeroconf: fix boolean return value
Raphaël Gomès <rgomes@octobus.net> [Thu, 18 Jul 2024 12:02:01 +0200] rev 51688
zeroconf: fix boolean return value This was (wrongly) flagged by Pytype as being undefined since it doesn't seem to understand `try` blocks. However, the caller is expecting a boolean and the fix to appease Pytype is simple, so we do both.
Thu, 11 Jul 2024 21:54:02 -0400 convert: fix various leaked file descriptors
Matt Harbison <matt_harbison@yahoo.com> [Thu, 11 Jul 2024 21:54:02 -0400] rev 51687
convert: fix various leaked file descriptors Some of these only leaked if an exception occurred between the open and close, but a lot of these leaked unconditionally. A type hint is added to `parsesplicemap` because otherwise this change caused pytype to change the return type from this to `Dict[nothing, nothing]`.
Thu, 11 Jul 2024 21:16:45 -0400 convert: stringify `shlex` class argument
Matt Harbison <matt_harbison@yahoo.com> [Thu, 11 Jul 2024 21:16:45 -0400] rev 51686
convert: stringify `shlex` class argument The documentation is handwavy, but typeshed says this should be `str`[1]. I'm not sure if this is the correct encoding (vs `fsencode` or "latin1" like the tokens returned by the proxy class). While we're here, we can add a few more type hints that would have caused pytype to flag the problem. [1] https://github.com/python/typeshed/blob/6a9b53e719a139c2d6b41cf265ed0990cf438192/stdlib/shlex.pyi#L51
Thu, 11 Jul 2024 20:54:06 -0400 typing: add trivial type hints to the convert extension's common modules
Matt Harbison <matt_harbison@yahoo.com> [Thu, 11 Jul 2024 20:54:06 -0400] rev 51685
typing: add trivial type hints to the convert extension's common modules This started as ensuring that the `encoding` and `orig_encoding` attributes has a type other than `Any`, so pytype can catch problems where it needs to be str for stdlib encoding and decoding. It turns out that adding the hint in `mercurial.encoding` is what was needed, but I picked a bunch of low hanging fruit while here. There's definitely more to do, and I see a problem where `shlex.shlex` is being fed bytes instead of str, but there are not enough type hints yet to make pytype notice.
Thu, 11 Jul 2024 14:46:00 -0400 convert: drop a duplicate implementation of `dateutil.makedate()`
Matt Harbison <matt_harbison@yahoo.com> [Thu, 11 Jul 2024 14:46:00 -0400] rev 51684
convert: drop a duplicate implementation of `dateutil.makedate()` I noticed this because the signature generated by pytype recently changed to be less specific. When the method was introduced back in 337d728e644f, `util.makedate()` didn't take an optional timestamp arg. But now it does, and the methods are the same (except the `dateutil` version validates that the timestamp isn't a negative value). I left the old method in place in case anyone has custom convert code that monkey patches it.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip