mirrors/arti.git/crates/tor-error/src/lib.rs, branch arti-v1.4.4mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.42025-04-16T23:06:51Znetdoc: functionality for detecting missing subprotos.2025-04-16T23:06:51ZNick Mathewsonnickm@torproject.org2025-04-02T18:28:59Zurn:sha1:9ce35d06069892c5460b4c625c4a0d470ca56607
Also, add a new ErrorKind for this sort of error.
clippy: deny `mod_module_files`2025-01-06T23:09:41ZSteven Engleropara@torproject.org2025-01-06T23:02:49Zurn:sha1:252a3a803b2db65792db5bd51dee8950d8557e0d
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
add_warnings, *: Allow clippy::needless_lifetimes2024-12-03T14:27:26ZNick Mathewsonnickm@torproject.org2024-12-03T14:15:50Zurn:sha1:64cc3f2ed3eea0b7c5cc89ae07cbdadfdc1646fb
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
tor-error: add comment to `ErrorKind::TransientFailure`2024-11-21T18:36:02ZSteven Engleropara@torproject.org2024-11-21T18:34:29Zurn:sha1:a264f26025fe8b4f9bbe7ec06c8a737c6a8b34b4Remove Rpc* variants from tor_error::ErrorKind2024-10-17T23:16:58ZNick Mathewsonnickm@torproject.org2024-10-16T18:58:58Zurn:sha1:5219f4cee5a74c0abdd8ad548b4ead9e2066cb2c
These are not regular ErrorKinds, since they can never occur in an
error that's meant to be returned from a Rust API like
`arti-client`. Instead, they only exist for errors returned from
RpcError.
(I can't find the place where we discussed this previously, but the
rationale is that if an ErrorKind never makes sense in response to
something that the user does from Rust, we should never have that be
an ErrorKind. The fact that the removed kinds do not actually
appear outside the RPC system suggests that this is reasonable.)
tor-error: Make "futures" dependency optional.2024-10-09T19:59:21ZNick Mathewsonnickm@torproject.org2024-10-09T19:59:21Zurn:sha1:8f45f5bfa2574671b8d60ba273ddcb72aa6599bd
This is part of an effort to make arti-rpc-client-core (and future
similar tools) able to use our very-low-level crates
without depending on things they don't need.
tor-{error,rpcbase}: Add new RPC error codes from spec.2024-10-07T18:33:40ZNick Mathewsonnickm@torproject.org2024-10-07T18:33:40Zurn:sha1:5904bcd65c97cb21a336aecede918d1c47e5fccc
These, like the other RPC-only error kinds, probably don't belong in
`tor-error`. But for now, that's where they all are, and moving
them is out of scope for this branch. See #1668.
Upgrade to derive_more version 1.0.02024-09-25T14:37:18ZNick Mathewsonnickm@torproject.org2024-09-25T14:37:18Zurn:sha1:6a12c2ba8515226a772d5f4a81930bf42d67535a
The `derive_more` crate broke backward compatibility with this version,
so this change involved quite a few manual fixups.
With luck, they'll keep compatibility for some while in the future.
tor-error: implement HasKind on void::Void and Infallible.2024-08-13T00:27:03ZNick Mathewsonnickm@torproject.org2024-08-12T16:31:02Zurn:sha1:ef6f70c2cf6b947d6f42efb630e04721442dfe4d
`void::Void` represents the type of an object that can't be
constructed. It's especially useful as the error type of an
infallible function. `void::Void` already implements
`std::error::Error`, so all we need to do to use it as a "can't
happen" error type in our code is to have it also implement
`HasKind`.
Also implement HasKind for Infallible while we're at it.
rpc: Rename the error codes for something like consistency.2024-07-25T12:46:29ZNick Mathewsonnickm@torproject.org2024-07-24T18:51:54Zurn:sha1:847e80f307789c607ac3415254b292e20da9c7f0