mirrors/arti.git/crates/tor-cell/tests/test_relaycell.rs, branch arti-v1.5.0

Switch Cargo.toml files to edition 2024.

2025-08-07T15:28:36Z

First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.

tor-cell: change `UnparsedRelayMsg::data_len`

2025-07-15T06:04:44Z

It now performs some validation and can return a `Result`. We perform validation here since different cell formats may have different maximum data lengths in the future, and `UnparsedRelayMsg` doesn't expose the cell format so it's difficult to perform this validation at a higher layer.

tor-cell: add some testing for `UnparsedRelayMsg`

2025-05-01T01:51:55Z

cell: Implement parsing and encoding for V1 relay cells

2025-04-16T14:58:49Z

This is the main part of #1944, and will be needed for CGO.

Add a RelayCellFormat argument to encode().

2025-04-16T14:58:49Z

This will let us actually _send_ messages in the right format. This approach is not ideal for packed/fragmented messages; they will need a separate RelayCellEncoder. part of #1944.

squash! Upgrade rand dependency to 0.9.

2025-03-18T16:09:44Z

- `try_fill_bytes()` is no longer a member of RngCore.

relay-cell: Update relay cell decoding API for prop340

2024-03-12T15:58:12Z

Prop 340: https://spec.torproject.org/proposals/340-packed-and-fragmented.html This updates the decoding API to support multiple versions of the relay cell encoding, including the new encoding proposed in prop340 that supports relay message packing and fragmentation. This commit doesn't actually add support for that new encoding yet.

Rename UnparsedRelayCell -> UnparsedRelayMsg

2024-03-12T15:58:12Z

For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253

Rename {Any}RelayCell to {Any}RelayMsgOuter

2023-12-14T16:56:58Z

This commit is pure renaming, done automatically with rust-analyzer. Comment fixes and other cleanups will be in the subsequent commits. We're doing this renaming because we need a name for the combination of a `RelayMsg` and an `Option` that we use when we have a `RelayMsg` we intend to route to a given stream or circuit internally. Previously we called this a `RelayCell`, but that name was already somewhat inaccurate, and will become _very_ inaccurate with the arrival of prop340, which breaksthe 1:1 relationship between relay cells and relay messages. (If we didn't do this renaming now, we'd soon be making the relationship between `UnparsedRelayCell`and `RelayCell` many-to-many, which would be ridiculous and confusing.) The `RelayMsgOuter` name is a placeholder: We expect that we'll want to rename this type, and may also want to rename `RelayMsg`, and unify our vocabulary in other areas too. But such a renaming will have to wait for a larger discussion affecting the specifications, so that we can use the same vocabulary everywhere.

Convert StreamId to NonZeroU16

2023-10-25T20:34:55Z