With this
cargo +stable clippy --locked --offline -p tor-netdir --features=hs-client --all-targets
I got this:
64 | use {hsdir_params::HsDirParams, hsdir_ring::HsDirRing, itertools::chain, std::iter};
| ^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
These crates had no changes until just a moment ago. But since
we updated the versions on some of their dependents, they have now
changed themselves. Thus they get patchlevel bumps.
```
tor-rtmock
tor-protover
tor-socksproto
tor-consdiff
tor-chanmgr
tor-dirclient
tor-hsservice
```
For these crates, the changes are nontrivial, so we
_do_ bump the versions on which their dependent crates depend.
Fortunately, since they are all pre-1.0, we don't need to
distinguish semver-additions from other changes. (Except for arti,
which _is_ post-1.0, but gets a patchlevel bump anyway.)
These are unstable crates with breaking changes:
```
tor-hscrypto
tor-hsclient
```
These have new or extended APIs:
```
safelog
tor-bytes
tor-cell
tor-linkspec
tor-llcrypto
tor-proto
tor-cert
arti-client
```
These have new unstable APIs or features:
```
tor-netdoc
tor-circmgr (also broke some unstable APIs)
arti (is post-1.0)
```
These have bugfixes only:
```
caret
tor-dirmgr
```
Their dependents are _not_ updated to a more recent version.
These bumped the version of a dependency that they don't expose
```
tor-rtcompat
fs-mistrust
```
This one had internal refactoring:
```
tor-netdir
```
These had trivial changes only:
```
tor-checkable
tor-ptmgr
tor-guardmgr
arti-hyper
arti-bench
arti-testing
```
I don't think the server-side support will want to explicitly call
current and then secondary. Rather, it will want to iterate over all
the relevant ones.
And fix the name, and add another comment about whether we need this.
Change its name to hs_* like we do with things at this layer.
But, it turns out, that at least for hs client connections to fetch
the descriptor, I don't seem to need to call it yet ? Maybe it's not
needed.
There are too many things called "index" here. `idx` could be read to
mean the table index `RouterStatusIdx`, the hsdir hash `HsDirIndex`,
or an entry in some other one of these tables.
Here's, it's just the sequence number of the index in the test netdir.
Use `pos` for that. (`seq` would have been another possibility.)
The hidden services directory hashring is a ring of hsdir relays,
sorted by a hash that the spec calls the "index". That's `HsDirIndex`.
This was a bad idea because the word "index" is seriously overused,
but in Arti we must use the same terminology.
At least, qualify it everywhere. Now one of these hsdir sort position
hashes is always, in our code, an `hsdir_index`.
I think this is necessary even inside modules called `hsdir_*`,
because those can deal with other kind of "index" too.
This is an `IndexVec` key type. Some places used `idx`, some `rsi`,
some `rs_idx`.
Use `rsidx` for it everywhere, including in locals, function names,
and fields. `rsidx` is a compromise. `rsi` might be a bit opaque,
but we want a one-"word" name since it appears inside other names.
These crates have had small code changes, but no API additions:
tor-config
tor-socksproto
tor-cert
tor-chanmgr
tor-ptmgr
tor-guardmgr
tor-circmgr
tor-dirclient
tor-dirmgr
arti
tor-hsservice
tor-congestion
These crates have had API extensions:
fs-mistrust
tor-llcrypto
tor-bytes
tor-checkable
tor-linkspec
tor-netdoc
tor-persist
arti-client
These are API breaks, but the crates themselves are currently
100% experimental, so there's no need to bump the minor versions
according to our semver rules.
Nick Mathewson
Ian Jackson
Ian Jackson
gabi-250