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 51741
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 51740
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 51739
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 51738
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 51737
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 51736
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 51735
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 51734
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 51733
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 51732
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`.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip