mirrors/arti.git/crates/tor-persist/src/testing.rs, branch arti-v1.1.3mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.32023-01-27T13:28:02ZAllow clippy::unchecked_duration_subtraction in tests2023-01-27T13:28:02ZNick Mathewsonnickm@torproject.org2023-01-27T13:01:45Zurn:sha1:a6dd92843edf2bd4c58de62a0d562921e4191ada
This panics on error, and we're fine with a panic on misbehavior in
tests.
test lint blocks: Add many many automatically2022-12-12T18:00:30ZIan Jacksonijackson@chiark.greenend.org.uk2022-12-12T17:58:40Zurn:sha1:125a455bdcca841931f33f83f206e57637ae85c4
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
add feature annotation not added by doc_auto_cfg2022-08-24T16:22:41Ztrinity-1686atrinity@deuxfleurs.fr2022-08-18T00:04:46Zurn:sha1:426a59b2ba591e20a13c568d665310c55e2f8e53tor-persist: Big refactoring on Error type.2022-07-06T15:47:17ZNick Mathewsonnickm@torproject.org2022-07-05T14:28:18Zurn:sha1:853aed685983a83e97c273f2135d23f09ff2bef0
Every error now has an action (what we were trying to do), a
resource (what we were trying to do it to), and a source (what
problem we encountered).
Initially I tried to add "action" and "resource" fields to error
variants individually, but that led to a combinatorial explosion.
Part of #323.
tor-persist: Move Error to a module.2022-07-06T10:38:10ZNick Mathewsonnickm@torproject.org2022-07-05T14:05:08Zurn:sha1:aeef36a5386faee95aa2279740ea5d05bef22547Fix clippy::significant_drop_in_scrutinee warnings2022-06-15T15:52:30ZNick Mathewsonnickm@torproject.org2022-06-14T18:52:39Zurn:sha1:647d4410bb263499f11f21a82ff6b414140e820d
This is apparently a new warning from clippy nightly, documented in
https://rust-lang.github.io/rust-clippy/master/index.html#significant_drop_in_scrutinee .
I'm not in love with the temporary variables that this warning wants
me to introduce, but it does seem like a decent way to avoid some
kinds of deadlock.
arti-client: Unlock the state manager on failure to bootstrap2022-02-24T19:55:59Zetator@eta.st2022-02-18T16:02:18Zurn:sha1:c6fdd7c0037df821a7cfc475993322958c2f006a
`StateMgr` got a new `unlock()` method that does what it says on the
tin. We now call it from `bootstrap()` using the new
`util::StateMgrUnlockGuard`, which works in a manner similar to the
`BoolResetter` from `tor_dirmgr`.
(A decent small little task in future might be to unify these types in
some sort of general arti utility crate?)
closes arti#335
tor-persist: Distinguish load vs. store json errors2022-02-04T14:33:09ZIan Jacksonijackson@chiark.greenend.org.uk2022-01-13T16:50:14Zurn:sha1:a4765717da64cc287f09e429989c79b97d794ded
Serialisation errors ought not to occur, since they would represent an
attempt to store malformed data, or something. (We always convert to
a string, so the JSON error never contains IO errors or the like.)
Deserialisation errors mean the persistent state is corrupt.
address clippy's latest lint2021-12-20T09:46:41ZDaniel Eadesdanieleades@hotmail.com2021-12-20T09:46:41Zurn:sha1:9b51a52b53acf3efd468d17296b3671ed9a1af47Change how TestingStateMgr handles locking.2021-11-03T17:27:01ZNick Mathewsonnickm@torproject.org2021-11-03T17:05:52Zurn:sha1:619ae65064861f844966e45194dbc8ffb74cee28
Previously it was either all-locked or all-not-locked. Now you can
simulate having the same shared storage opened by multiple managers,
only one of which has the lock.