mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.7 2023-08-01T14:57:55Z 2023-08-01T14:57:55Z Nick Mathewson nickm@torproject.org 2023-08-01T14:57:55Z urn:sha1:3acdf102c705314aec63679e97240bb7d981d1c8 These crates are at version 0.x.y, so we don't need to distinguish new-feature changes from other changes: ``` tor-basic-utils fs-mistrust tor-error tor-geoip tor-checkable tor-linkspec tor-netdoc tor-netdir tor-persist tor-ptmgr tor-hsservice ``` This crate has a breaking change, but only when the semver-breaking feature `experimental-api` is enabled: ``` tor-config ``` This crate is at version 1.x.y, but has no new public APIs, and therefore does not need a minor version bump: ``` arti ``` 2023-08-01T14:51:25Z Nick Mathewson nickm@torproject.org 2023-08-01T14:51:25Z urn:sha1:6f2ae5960393b64c1d7615d2d523e050d3bebe5a These crates had first-order breaking changes: ``` retry-error tor-keymgr tor-proto tor-hsclient tor-rtmock ``` Additionally, these broke because they re-exposed RetryError: ``` tor-circmgr ``` Additionally, these broke because they may re-expose something from tor-proto: ``` arti-client tor-chanmgr tor-dirclient tor-dirmgr tor-guardmgr ``` Additionally, these broke for other fiddly reasons: `tor-ptmgr` implements traits from tor-chanmgr, which has a breaking change above. `arti-hyper` exposes types from arti-client in its API. 2023-07-11T09:37:42Z Ian Jackson iwj@torproject.org 2023-07-11T09:37:42Z urn:sha1:3acc2af4f3411588f80669ae1980679dd260b119 clippy: Allow some of our existing code patterns See merge request tpo/core/arti!1396 2023-07-10T15:08:03Z Ian Jackson ijackson@chiark.greenend.org.uk 2023-07-07T13:19:55Z urn:sha1:b151237a7f8651ed8694748832af05786a7eccfd 2023-07-10T12:49:51Z Ian Jackson ijackson@chiark.greenend.org.uk 2023-07-10T11:19:32Z urn:sha1:473447a82e099fd52a674c28f5bc24b3e05208c0 2023-07-07T19:27:20Z Nick Mathewson nickm@torproject.org 2023-07-07T19:27:20Z urn:sha1:b6b7edad593fbb245a2a31be6456c7588c56981c Throughout: Use event_report!() macros for reporting Errors. Closes #949 See merge request tpo/core/arti!1383 2023-07-07T17:00:21Z Nick Mathewson nickm@torproject.org 2023-07-07T13:54:27Z urn:sha1:25c6fe61e4cf230210dffdac2d3c281fcb31c5a9 I identified the cases to replace by searching for the string `.report()`. There are a few that I didn't change: * A couple of cases that used anyhow::Error, * One case that reported two Errors. * Two cases in `tor_hsclient::err` that just did `error!("Bug: {}")`. I have also not audited the cases in `tor-hsclient` where we're using `tor_error::Report` manually. Nonetheless, closes #949. 2023-07-07T15:13:52Z Ian Jackson ijackson@chiark.greenend.org.uk 2023-07-07T13:10:23Z urn:sha1:bcc3e6fef8b863fa6a863aae2d6234fba7fb99f6 Many of these call sites would panic if, somehow, the upper bound was zero. In most cases it is very complicated to see if whether this could happen. However, there is a better answer: Durations are (conceptually) dense, so picking the closed set (which includes its boundary) rather than the open one (which doesn't) will make little practical difference. So change four call sites to use `..=` instead of just `..`. 2023-07-06T18:32:23Z Nick Mathewson nickm@torproject.org 2023-07-06T18:32:23Z urn:sha1:03f9f9987a7ba42368d82363bef7f569e32ffe2c Closes #950. 2023-07-06T14:14:41Z Ian Jackson ijackson@chiark.greenend.org.uk 2023-07-05T15:30:07Z urn:sha1:1f41281cfda21e16db6769d8646c3b8fe4029990 This seems to have been overlooked.