<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mirrors/arti.git/crates/tor-dirmgr/src/lib.rs, branch ios-sqlite-hacks</title>
<subtitle>mirror of https://gitlab.torproject.org/tpo/core/arti
</subtitle>
<id>http://git.dilluti0n.com/mirrors/arti.git/atom?h=ios-sqlite-hacks</id>
<link rel='self' href='http://git.dilluti0n.com/mirrors/arti.git/atom?h=ios-sqlite-hacks'/>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/'/>
<updated>2023-09-06T02:34:56Z</updated>
<entry>
<title>Add cognitive-complexity exceptions for clippy.</title>
<updated>2023-09-06T02:34:56Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-08-30T18:43:38Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=8b8faacd1cbcdd841a02cd0273f75377d5a91b3f'/>
<id>urn:sha1:8b8faacd1cbcdd841a02cd0273f75377d5a91b3f</id>
<content type='text'>
I have no idea why these became necessary.
</content>
</entry>
<entry>
<title>Run maint/add_warning to add lint block everywhere</title>
<updated>2023-08-23T09:34:00Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-08-22T14:28:12Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=42df88d6bf6dbb460d2e5e1cd4838aafaffbe9ac'/>
<id>urn:sha1:42df88d6bf6dbb460d2e5e1cd4838aafaffbe9ac</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Run add_warnings on all files.</title>
<updated>2023-08-04T11:45:04Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-08-04T11:45:04Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=cec6d0ce33b4b5cebbce57f55faec83397e9c953'/>
<id>urn:sha1:cec6d0ce33b4b5cebbce57f55faec83397e9c953</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Run maint/add_warning to actually apply new lint allows</title>
<updated>2023-07-10T12:49:51Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-07-10T11:19:32Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=473447a82e099fd52a674c28f5bc24b3e05208c0'/>
<id>urn:sha1:473447a82e099fd52a674c28f5bc24b3e05208c0</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Throughout: Use *_report!() macros for reporting Errors.</title>
<updated>2023-07-07T17:00:21Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-07-07T13:54:27Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=25c6fe61e4cf230210dffdac2d3c281fcb31c5a9'/>
<id>urn:sha1:25c6fe61e4cf230210dffdac2d3c281fcb31c5a9</id>
<content type='text'>
I identified the cases to replace by searching for the string
`.report()`.  There are a few that I didn't change:

  * A couple of cases that used anyhow::Error,
  * One case that reported two Errors.
  * Two cases in `tor_hsclient::err` that just did
    `error!("Bug: {}")`.

I have also not audited the cases in `tor-hsclient` where we're using
`tor_error::Report` manually.

Nonetheless, closes #949.
</content>
</entry>
<entry>
<title>Run add_warning to remove `missing_panics_doc` deny.</title>
<updated>2023-07-06T18:32:23Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-07-06T18:32:23Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=03f9f9987a7ba42368d82363bef7f569e32ffe2c'/>
<id>urn:sha1:03f9f9987a7ba42368d82363bef7f569e32ffe2c</id>
<content type='text'>
Closes #950.
</content>
</entry>
<entry>
<title>lints: Run maint/add_warning to actually apply new lints</title>
<updated>2023-06-21T11:15:41Z</updated>
<author>
<name>Ian Jackson</name>
<email>ijackson@chiark.greenend.org.uk</email>
</author>
<published>2023-06-21T10:29:46Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=161b9844dae0aaa2e63bbc77c512d061be6bb390'/>
<id>urn:sha1:161b9844dae0aaa2e63bbc77c512d061be6bb390</id>
<content type='text'>
</content>
</entry>
<entry>
<title>DirMgr: More logs in top-level bootstrapping code.</title>
<updated>2023-05-03T15:08:19Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-04-10T15:00:37Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=a7612ecdf8a49ea4c25ab750505d1934e5ab5044'/>
<id>urn:sha1:a7612ecdf8a49ea4c25ab750505d1934e5ab5044</id>
<content type='text'>
Closes #803, I hope.
</content>
</entry>
<entry>
<title>DirMgr: Log at trace! when starting a new "AttemptId".</title>
<updated>2023-05-03T15:08:19Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-04-10T14:06:23Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=b2486bba1e6360859b16a9cb0f853b4111944799'/>
<id>urn:sha1:b2486bba1e6360859b16a9cb0f853b4111944799</id>
<content type='text'>
</content>
</entry>
<entry>
<title>tor-dirmgr: Don't try to mark consensus usable in a read-only store.</title>
<updated>2023-03-08T12:08:17Z</updated>
<author>
<name>Nick Mathewson</name>
<email>nickm@torproject.org</email>
</author>
<published>2023-03-08T12:08:17Z</published>
<link rel='alternate' type='text/html' href='http://git.dilluti0n.com/mirrors/arti.git/commit/?id=ac5469d0b6eeecd3fe73d561f7f0602f67749796'/>
<id>urn:sha1:ac5469d0b6eeecd3fe73d561f7f0602f67749796</id>
<content type='text'>
Doing this means that any attempt to use a read-only store would
crash as soon as it found that the consensus was usable.

It seems that this bug was introduced at some point doing all the
dirmgr refactors we did over the past year.  Perhaps there should be
a test for running with a read-only store.

Fixes #779
</content>
</entry>
</feed>
