| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | | |
This is the first version that builds correctly on our CI. It's
from back in 2018, so requiring it shouldn't cause any major
problems.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/262#note_2772816
|
| | | |
| | |
| | |
| | |
| | | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/262#note_2772810
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This will get quite large and boxing it here is very convenient.
This also avoids us exposing a large error type to our callers.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The motivation for doing this now is to remove the `#[from]` so we
would spot where operationsl circuit setup failures were handled.
(But it turns out that they are turned into internal errors!)
Perhaps this will want to become a different error type from circmgr
in due course, but for now we simply use a bespoke variant of
TorError.
It will want its own Kind. The TODO in the HasKind impl marks
this (amongst much else here).
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Two ? in the tests become expects, which will do. That avoids having
to construct a proper error with context here.
|
| | | |
| | |
| | |
| | |
| | | |
Right now we must always expose the `Error` type since we haven't
converted everything.
|
| | | |
| | |
| | |
| | | |
We are going to make the top-level Error type conditionally hidden.
|
| | | |
| | |
| | |
| | | |
Still much to do here.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This involves making a temporary ErrorKind::TODO. That will continue
to exist until all errors (at least, the ones that make it out to
here) can be properly categorised.
Introducing this will let us work from the top and bottom towards the
middle.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This makes this like all the others, and is marginally shorter
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Provide an enum variant to contain the SpawnError and a From impl.
We use `#[from]` here because it doesn't really make sense to attach
any context, as it's not likely to be very relevant.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This needs two kinds. We have decided to treat a non-shutdown
SpawnError as "unexplained" rather than as an InternalError.
There are many crates whose
From<futures::task::SpawnError> for Error
erroneously treat it as an internal error. We will fix them in a moment.
|
| | | |
| | |
| | |
| | |
| | | |
And change the comments to slightly reinterpret these errors, to
relate to the circumstances rather than error generation site.
|
| | | |
| | |
| | |
| | | |
Doing this here makes it easier when I rebase/reorder things
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This can be used in call sites where an error is thought not to be
possible.
The `source` will be used only for formatting messages.
|
| | | |
| | |
| | |
| | | |
This can contain a backtrace, which will be printed.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
As per doc/Errors.md.
Currently there are no error kinds. Some will be added as we go along.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This will be used for error handling, and perhaps other things.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The type annotation may not be necessary for inference, but as a
comment it risks becoming false. So it should be uncommented, or
deleted.
Error types round here are not entirely trivial so uncomment it.
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Properly linkify two doc comment xrefs to issues
See merge request tpo/core/arti!290
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes these messages:
warning: this URL is not a hyperlink
--> crates/arti/src/watch_cfg.rs:115:5
|
115 | /// https://github.com/notify-rs/notify/issues/165 and
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://github.com/notify-rs/notify/issues/165>`
|
= note: `#[warn(rustdoc::bare_urls)]` on by default
= note: bare URLs are not automatically turned into clickable links
warning: this URL is not a hyperlink
--> crates/arti/src/watch_cfg.rs:116:5
|
116 | /// https://github.com/notify-rs/notify/pull/166 .
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<https://github.com/notify-rs/notify/pull/166>`
|
= note: bare URLs are not automatically turned into clickable links
|
| |\ \
| | |
| | |
| | |
| | | |
arti-bench: run the benchmarks in CI, and keep the results
See merge request tpo/core/arti!283
|
| | | |
| | |
| | |
| | |
| | | |
This adds `arti-bench` to the `integration` job in the CI pipelines, and
keeps around the JSON benchmark output for later comparison.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Remove file ending of shellcheck_all and downgrade_dependencies script
See merge request tpo/core/arti!278
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Watch configuration files and reload them when they change
Closes #270
See merge request tpo/core/arti!280
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(More specifically, `notify` behaves differently on different
platforms. On some, it can watch specific directory objects on the
filesystem, and so it only notices when _those_ directories change.
If you change a symlink so that the canonical configuration file
location is now in some other directory, `notify` won't notice. But
on other platforms, notify just does "stat()" in a loop. On those,
it _will_ notice if the configuration file changes.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since the user can put their logfiles and configuration files in the
same directory, writing to the log can trigger an event from
`notify`. If we log every non-interesting event from `notify`, then
we'll trigger the logs every time we log, and fill up the disk.
This commit removes the offending log and adds a comment about why.
If we someday decide we do need to log here, maybe we can rate-limit
the messages or something.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This way, if there are a bunch of changes at once, we only reload
one time.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Due to limitations in notify and the OS APIs it uses, it isn't
actually so useful to watch a single file. Instead, we have to
watch the directories that contain the files, and filter out any
events that aren't about the specific files we care about.
I've put the logic here into a new type, but I've left the type
un-exported: its API is pretty ugly, inasmuch as the caller needs to
jump through hoops to only get the events that they want. That's
not too bad so long as the API is private, but we'd want better if
we were exposing this.
|
| | | | | |
|
| | | | | |
|