mirrors/arti.git/crates/tor-basic-utils/Cargo.toml, branch arti-v1.0.0

Bump crate versions in preparation for Arti 1.0.0 release.

2022-09-01T12:59:49Z

Because we want to work more on ensuring that our semver stability story is solid, we are _not_ bumping arti-client to 1.0.0 right now. Here are the bumps we _are_ doing. Crates with "minor" bumps have had API breaks; crates with "patch" bumps have had new APIs added. Note that `tor-congestion` is not bumped here: it's a new crate, and hasn't been published before. ``` tor-basic-utils minor fs-mistrust minor tor-config minor tor-rtcompat minor tor-rtmock minor tor-llcrypto patch tor-bytes patch tor-linkspec minor tor-cell minor tor-proto minor tor-netdoc patch tor-netdir minor tor-persist patch tor-chanmgr minor tor-guardmgr minor tor-circmgr minor tor-dirmgr minor arti-client minor arti-hyper minor arti major arti-bench minor arti-testing minor ```

tor-basic-utils: Provide IoErrorExt is_not_a_directory()

2022-08-25T14:58:29Z

We're going to want this functionality, which isn't in the stable stdlib.

enable doc_auto_cfg feature on every crate when documenting for docs.rs

2022-08-24T16:22:41Z

Bump patch versions on crates that have new APIs.

2022-08-01T13:56:29Z

Do _not_ bump the dependency versions on crates that have had no changes since arti 0.0.5, since those crates do not depend on the new APIs. ``` cargo set-version -p tor-basic-utils --bump patch cargo set-version -p tor-llcrypto --bump patch git restore crates/tor-checkable git restore crates/tor-consdiff git restore crates/tor-rtmock ```

Provide maybe_send on postage::watch::Sender, via extension trait

2022-07-18T17:13:13Z

We need to replace the AtomicBool for dormant mode with something that can wake up tasks. postage::watch is the right shape. But we want to be able to update it but suppress no-op updates. (There is going to be a call site where no-op updates can occur.) In the absence of a suitable upstream method as requested here https://github.com/austinjones/postage-rs/issues/56 we introduce this facility via an extension trait.

Bump crate and dependency versions.

2022-06-24T16:00:22Z

These were done with the following commands: ``` cargo set-version -p tor-basic-utils --bump patch cargo set-version -p fs-mistrust --bump minor cargo set-version -p tor-error --bump patch cargo set-version -p tor-config --bump patch cargo set-version -p tor-units --bump patch cargo set-version -p tor-rtcompat --bump minor cargo set-version -p tor-llcrypto --bump patch cargo set-version -p tor-bytes --bump minor cargo set-version -p tor-socksproto --bump minor cargo set-version -p tor-cert --bump minor cargo set-version -p tor-cell --bump minor cargo set-version -p tor-proto --bump minor cargo set-version -p tor-netdoc --bump patch cargo set-version -p tor-netdir --bump minor cargo set-version -p tor-persist --bump patch cargo set-version -p tor-chanmgr --bump minor cargo set-version -p tor-guardmgr --bump minor cargo set-version -p tor-circmgr --bump patch cargo set-version -p tor-dirclient --bump patch cargo set-version -p tor-dirmgr --bump minor cargo set-version -p arti-client --bump patch cargo set-version -p arti --bump minor cargo set-version -p arti-bench --bump minor cargo set-version -p arti-testing --bump minor ```

New facility for deterministic and reproducible test PRNGs.

2022-06-02T18:51:51Z

The new `testing_rng()` function is meant as a replacement for thread_rng() for use in unit tests. By default, it uses a randomly seeded RNG, but prints the seed before the test so that you can reproduce any failures that occur. You can override this via the environment to use a previous seed, or by using a deterministic seed for all your tests. Backend for #486.

Lexically sort Cargo.toml dependencies

2022-05-28T17:05:51Z

Utilize cargo-sort: https://github.com/DevinR528/cargo-sort Signed-off-by: Orhun Parmaksız

Semantic version changes for Arti 0.4.0 release

2022-05-27T13:01:20Z

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.

channel: Provide and use Sink::prepare_send_from

2022-05-23T10:28:05Z

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.