mirrors/arti.git/crates/tor-rtcompat, branch arti-v1.4.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.02025-02-06T18:17:34ZVersion bumps to 0.27.02025-02-06T18:17:34ZIan Jacksonijackson@chiark.greenend.org.uk2025-02-06T18:13:25Zurn:sha1:e590ba4d522b44ffc7adc0eea463309df2de12f3
See Release.md.
maint/list_crates | grep -P '^tor-|^arti-' | xargs -n1 nailing-cargo -Eu set-version --bump minor -p
This completes the version bumps.
The report of changed crates, before I started the release work, is:
$ maint/changed_crates -v "arti-v$LAST_VERSION"
oneshot-fused-workaround: No change.
slotmap-careful: No change.
test-temp-dir: No change.
fslock-guard: No change.
hashx: No change.
equix: No change.
tor-basic-utils: No change.
caret: No change.
fs-mistrust
safelog: No change.
retry-error: No change.
tor-error
tor-general-addr: No change.
tor-geoip: No change.
tor-rtcompat
tor-rtmock
tor-async-utils
tor-config
tor-config-path
tor-rpc-connect
tor-log-ratelim: No change.
tor-rpcbase
tor-memquota: No change.
tor-units
tor-llcrypto: No change.
tor-protover: No change.
tor-bytes
tor-checkable: No change.
tor-cert
tor-key-forge
tor-hscrypto: No change.
tor-socksproto: No change.
tor-linkspec: No change.
tor-cell: No change.
tor-proto
tor-netdoc: No change.
tor-consdiff: No change.
tor-netdir
tor-relay-selection: No change.
tor-persist
tor-chanmgr
tor-ptmgr: No change.
tor-guardmgr: No change.
tor-circmgr
tor-dirclient: No change.
tor-dirmgr: No change.
tor-keymgr
tor-hsclient
tor-hsservice
tor-hsrproxy: No change.
tor-relay-crypto
arti-client
arti-relay
arti-rpcserver
arti
arti-rpc-client-core
$
tor-rtcompat: Rename UnsupportedStreamOps to NoOpStreamOpsHandle (fmt).2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-13T11:49:37Zurn:sha1:dc4fe47d5388074352ac00b561bed978779446e0tor-rtcompat: Rename UnsupportedStreamOps to NoOpStreamOpsHandle.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-13T11:48:16Zurn:sha1:4ec53ca4dea324c2c170885d8556a67c802e491d
This renames UnsupportedStreamOpsHandle to NoOpStreamOpsHandle for
clarity (the old name kind of sounded like the name of an error type).
tor-rtcompat: Fix doc warning.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-09T13:33:20Zurn:sha1:b900e8b9e874498b37bede2d91ef2abfe71f6921tor-rtcompat: Big invasive change adding StreamOps bound everywhere.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T19:08:57Zurn:sha1:f04709c16d0ebf039779c404cf0c907f13965852
This is unfortunately necessary, because after the channel handshake, we
need to give the channel reactor a `StreamOps` handle to the underlying
stream.
tor-rtcompat: Implement StreamOps for TLS stream types.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T19:07:56Zurn:sha1:1569a9d0d224659158cb87586f8d2c65f28183b0tor-rtcompat: Implement StreamOps for Framed.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T11:15:12Zurn:sha1:0f0bf7f68183608f27ef67b90a81b5687a3f7a35tor-rtcompat: Implement new_handle() using TcpSockFd.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T19:35:08Zurn:sha1:f70ef5e04483c2d41f2efd98c9854e6447654bc6tor-rtcompat: Add the ability to get a StreamOps handle.2025-01-15T13:49:17ZGabriela Moldovangabi@torproject.org2025-01-08T11:06:59Zurn:sha1:267235969df65d975b5deb01c342e1073d4c3847
Needed for cases where we wrap an object that implements `StreamOps` in
an external type, thereby losing access to the `StreamOps`
functionality. For example, during the channel handshake, we `.split()`
the stream that implements `StreamOps`, which leaves us with a
`SplitSink` and a `SplitStream`, neither of which implement `StreamOps`.
Getting a handle to the underlying object that implements `StreamOps`
(for example, a file handle) *before* the stream is `.split()` enables
us to use `StreamOps` to manipulate the underlying split stream.
This commit also introduces a special `UnsupportedStreamOpsHandle`,
which is a type that implements `StreamOps`, but always returns an
error. This type is meant to simplify error handling and usage, and is
meant to be used in cases where `StreamOps` is not supported. TODO: the
name of this type is pretty confusing (it's very similar to
`UnsupportedStreamOp`, which is an error type), and should probably be
renamed to something else (`NoOpStreamOpsHandle`,
`BrokenStreamOpsHandle`, `DummyStreamOpsHandle` come to mind...).
Note: this changes the `StreamOps` trait to be slightly different from
what I originally envisioned in !2660 and #1769
tor-rtcompat: Note that SpawnBlocking isn't for CPU-bound tasks.2025-01-07T18:27:14ZWesley Aptekar-Casselsme@wesleyac.com2025-01-07T16:21:59Zurn:sha1:d05dc32108ef6e11fde481024543cd943268ee8d