mirrors/arti.git/crates/tor-hsservice/src/publish/backoff.rs, branch mainmirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=main2026-07-15T18:05:29ZRemove now-unneeded allow(clippy::cognitive_complexity)2026-07-15T18:05:29ZJim Newsomejnewsome@torproject.org2026-07-15T18:05:29Zurn:sha1:e4c00405e703b6e274af2e3cfb000cab5a7c7837maint: Run maint/add_warning to deny string slices2026-06-09T15:36:01ZClara Englercve@cve.cx2026-06-09T15:36:01Zurn:sha1:9f5752a77fb57052c06ead0eeae606831f1e8e97
This commit executes maint/add_warning with the just added change to
deny string slices except in tests.
I recommend auditing this by checking out the previous commit followed
by running the script yourself and then verifying that the diff is
identical to this commit.
This commit makes cargo clippy fail. We will add exceptions in the next
commit.
refactor: clean code2025-12-17T14:48:03ZNihal4218-nihalxkumar@gitlab.torproject.org2025-12-09T20:02:02Zurn:sha1:380c70e3c13fbd5c2b0b949c08f5a2dc4d437e9bfeat(retry-error): add timestamps to retry errors2025-12-17T14:48:03ZNihal4218-nihalxkumar@gitlab.torproject.org2025-11-28T10:21:26Zurn:sha1:555cc5a25fa65f8780c717e03a6f8fddce7a799aFix name of clippy lint to unchecked_time_subtraction (2)2025-11-06T11:28:22ZIan Jacksonijackson@chiark.greenend.org.uk2025-11-06T11:23:25Zurn:sha1:a5fd5c48ea059a80cc1f6c50e248654b5ff3aaff
Run maint/add_warning
*: suppress cognitive_complexity warnings from nightly2025-05-29T14:21:17ZNick Mathewsonnickm@torproject.org2025-05-21T14:48:35Zurn:sha1:5327d3e22a83b8469a5d4191d92e1364344ddc93
Apparently clippy nightly is better (or worse?) about detecting
complex functions than before, so I'm suppressing these warnings
where they occur.
I have mixed feelings about these warnings: On the plus side,
they really do help to detect functions that are twistier than they
need to be. On the minus side, they get confused by tracing macros,
and the "allows" do pile up. But on the plus side, those "allows"
do provide a way to find functions that need to be refactored,
and they are never uglier than the functions they decorate.
Resolve clippy warnings from 1.832025-05-13T18:53:41ZNick Mathewsonnickm@torproject.org2025-05-13T18:53:41Zurn:sha1:b182a9d05902bc5320ab486d055521f18b6b7832
Now that our MSRV is 1.83, clippy is happy to make more
recommendations for us.
tor-rt*: Apply deferred formatting churn2025-03-04T17:30:43ZIan Jacksonijackson@chiark.greenend.org.uk2025-02-26T18:13:00Zurn:sha1:39409be0db4def9ca5ffbd3bd14766112bcab527
rustfmt.
tor-rtcompat: Rename BlockOn to ToplevelBlockOn2025-03-04T17:30:43ZIan Jacksonijackson@chiark.greenend.org.uk2025-02-13T17:39:39Zurn:sha1:849558047071897b9bbdbdd28d06d15b52b3af10
We're going to distinguish top-level runtime entry, from *re*-entry to
an existing executor. It is most convenient to rename this trait
first. Documentation of the distinction will come later.
(We're going to retain the function name `block_on`, but we want the trait
to be more obviously a top-level only thing, though, so we give it a
name that will hopefully avoid it peroulating throughout the codebase..)
extract tor_async_utils::oneshot into ::oneshot-fused-workaround2024-08-28T14:27:46ZJim Newsomejnewsome@torproject.org2024-08-22T19:20:36Zurn:sha1:46f7f01092e6ac55e3e958dc3a2228b1d36e26a1
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.