mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.4.0 2022-05-27T14:18:52Z 2022-05-27T14:18:52Z Nick Mathewson nickm@torproject.org 2022-05-27T14:18:52Z urn:sha1:4326aa1de9875ea399c3a608c0320bbe4b214a42 This commit was made by reverting the previous commit, then re-running the script I used to generate it. In theory there should be no semantic changes: only changes due to improved formatting from cargo edit. 2022-05-27T13:01:20Z Nick Mathewson nickm@torproject.org 2022-05-27T13:01:20Z urn:sha1:b232365a75249d6f767127feb2a47286f9ece762 I followed the following procedure to make these changes: * I used maint/changed_crates to find out which crates had changed since 0.3.0. * I used grep and maint/list_crates to sort those crates in topological (dependency) order. * I looked through semver_status to find which crates were listed as having semver-relevant changes (new APIs and breaking changes). * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no changes. For those crates, I incremented their patch-level version _without_ changing the version that other crates depend on. * I scanned through the git logs of the crates with no semver-relevant changes listed to confirm that, indeed, they had no obvious breaking changes. * I treated all crates that depend on `arti` and/or `arti-client` as having breaking changes. * I identified crates that depend on crates that have changed, even if they have not changed themselves, and identified them as having a non-breaking change. * For all of the crates, I used `cargo set-version -p $CRATE --bump $STATUS` (where `STATUS` is `patch` or `minor`) to update the versions, and the depended-upon versions. 2022-05-25T19:57:19Z Nick Mathewson nickm@torproject.org 2022-05-25T15:43:09Z urn:sha1:bbc7470dc555a532f7fa9cbbd139ef63a5308beb 2022-05-23T10:28:05Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-20T15:49:30Z urn:sha1:2fc6c8a194fa668e5bdb9d94d25e29c5e1666a21 2022-05-23T10:28:05Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-18T15:02:52Z urn:sha1:793782acc80c05e2d2e125c65721c7a0b967d113 This is a general-purpose implementation of the ad-hoc approach currently taken in (eg) crates/tor-proto/src/channel/reactor.rs, with an API intended to defned against the more obvious mistakes. This allows us to separate the two concerns: the channel reactor can focus on handling channel cells and control messages and is over 2.5x shorter. The complexity of the manual sink implementation, and the machinery needed to avoid having to suspend while holding an item, are dealt with separately. That separate implemenation now has proper documentation. (Tests are in the nest commit to avoid this one being even more unwieldy.) We use `extend` to define this as an extension trait. A competitor is `ext` but in my personal projects I have found `extend` slightly better. 2022-05-16T15:10:00Z Nick Mathewson nickm@torproject.org 2022-05-16T15:10:00Z urn:sha1:fb432924a39119ccdb61e92616295024993398e3 # Conflicts: # doc/semver_status.md 2022-05-11T17:52:12Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-05-11T14:30:28Z urn:sha1:0cc94d449ed5853838221a882f66c7838a36ee3f The type of ret.map_err(codec_err_to_chan)? is (). ISTM that writing `let () = ` makes it clear that there is nothing there, but the lint forbids this. This lint is warn by default and trips here for me on current nightly. It seems wrong to me. We should be able to make it clear to the reader that there is nothing here - note how this differs from the lines below where Ready contains msg. A let () binding is a good way to do that. I think the lint allow ought to be added everywhere, but that doesn't seem easy right now - see this issue about maint/add_warning: https://gitlab.torproject.org/tpo/core/arti/-/issues/469 2022-05-11T17:02:36Z Nick Mathewson nickm@torproject.org 2022-05-11T13:03:52Z urn:sha1:0c05baa68b704f39d4c3835f35e6be33ea22c79e I need this so that I can expose the skew time for the directory that a circuit will use, when I only have the circuit. 2022-05-06T14:03:15Z Nick Mathewson nickm@torproject.org 2022-05-06T14:03:15Z urn:sha1:7b93091f57f43ec8543a17052d60a2c8f7f2b0cc * Except for safelog and fs-mistrust, which are new. 2022-05-04T18:41:50Z Nick Mathewson nickm@torproject.org 2022-05-04T18:36:27Z urn:sha1:fc33fc3efbfabd6d7d38334caedbea51ad6c8064