These crates have had trivial changes only: typically,
changes to documentation or to clippy warnings. There's no
good reason to update which version of them other crates depend on,
so we only bump _their_ patchlevels.
```
tor-async-utils
caret
safelog
tor-events
tor-units
tor-rtcompat
tor-rpcbase
tor-llcrypto
tor-protover
tor-bytes
tor-hscrypto
tor-socksproto
tor-cert
tor-cell
tor-consdiff
tor-congestion
arti-rpcserver
arti-testing
arti-bench
arti-config
arti-hyper
```
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
```
Done with the commands below.
The following crates have had various changes, and should get a
patchlevel bump. Since they are pre-1.0, we do not need to
distinguish new APIs from other changes.
```
cargo set-version --bump patch -p arti-client
cargo set-version --bump patch -p safelog
cargo set-version --bump patch -p tor-bytes
cargo set-version --bump patch -p tor-cert
cargo set-version --bump patch -p tor-circmgr
cargo set-version --bump patch -p tor-config
cargo set-version --bump patch -p tor-consdiff
cargo set-version --bump patch -p tor-dirclient
cargo set-version --bump patch -p tor-dirmgr
cargo set-version --bump patch -p tor-error
cargo set-version --bump patch -p tor-hsservice
cargo set-version --bump patch -p tor-linkspec
cargo set-version --bump patch -p tor-llcrypto
cargo set-version --bump patch -p tor-netdir
cargo set-version --bump patch -p tor-netdoc
cargo set-version --bump patch -p tor-proto
cargo set-version --bump patch -p tor-rpcbase
cargo set-version --bump patch -p tor-socksproto
```
This crate has new features, but no new non-experimental Rust APIs.
So even though it is post-1.0, it gets a patchlevel bump.
```
cargo set-version --bump patch -p arti
```
It's now not actually possible to write code that doesn't work, even
if `Tr` *isn't* 'static, because of the bounds on `CastTable::insert`.
I tried to produce a non-working setup with a non-static `Simple`, but
you can't implement `Object` for such a thing. Removing 'static from
Object would stop the downcasts from Any to Object working.
Prior to the new typesafe insert, this change
- let f: fn(&dyn $crate::Object) -> &(dyn $traitname + 'static) = |self_| {
+ let f: fn(&dyn $crate::Object) -> &(dyn $traitname) = |self_| {
would result in a runtime crash. Now it results in a compiler error.
This was locally bound to `S` in one place. Bind and use it throughout.
Since this is an RPC object, `O` is a better name.
In each item, use the description once and thereafter just the name.
This is a rather tricky piece of functionality. It works as
follows.
We introduce a `CastTable` type. Each `CastTable` tells us how to
downcast `dyn Object` for objects of a single concrete type.
The `Object` type now has a `get_casttable` method that returns
an empty `CastTable` by default.
`CastTable` is, internally, a map from the `TypeId` of the target
dyn Trait reference type to a function
`fn(&dyn Object) -> &dyn Trait`. These functions are stored as
`Box<dyn Any + ...>`. (They are Boxed because they may refer to
generic functions, which you can't get a static reference to,
and they're Any because the functions have different types.)
The `decl_object!` macro now implements `get_casttable` as
appropriate. (The syntax is a bit janky, but that's what we get
for not using derive_adhoc.) For non-generic types, `get_casttable`
uses a Lazy<CastTable>`. to initialize a CastTable exactly once.
For generic types, it use a `Lazy<RwLock<HashMap<..>>` to
build one CastTable per instantiation of the generic type.
This could probably be optimized a bit more, the yaks could be
shaved in a more scintillating hairstyle, and the syntax for
generic `decl_object` could definitely be improved.
Rationale: Our weak-vs-strong design is a bit confused at the moment
due to concerns about deduplication and capability semantics. It's
not clear that a general "change strong to weak" method is
compatible with what we want to provide.
I've made doing some design choices here:
* Reserving "rpc" as a prefix for post-authentication
functionality that is not arti-specific.
* Declaring these to be methods on the session rather than methods
on the objects themselves.
There's a problem with defining an API to drop a weak reference; see
comment in code.
This does the following:
- Gives every crate a `full`.
- Cause every `full` to depend on `full` from the lower-level
crates.
- Makes every feature listed _directly_ in `experimental` depend
on `__is_experimental`.
Right now, this lets us say whether the method was unrecognized or
whether the parameter type was incorrect.
We'll use this to enforce correct method names later on.
(I have to add another `inventory` here, since the `typetag`
maintainer does not want to expose this functionality: see
https://github.com/dtolnay/typetag/issues/57#issuecomment-1506106290
)
Now that the sink is not part of the context, RPC functions that are
able to send an update have to declare an `impl Sink` as their
fourth argument. This syntax is not final.
Part of #824.
Well, mostly correct. Our current serde implementation doesn't
tell us much about what went wrong with the object, so we can't
tell why we couldn't convert it into a Request.
Also, our output for the data field is not as the spec says:
we should bring them into conformance.
Part of #825.
Ian Jackson
Nick Mathewson
Dimitris Apostolou
Ian Jackson