| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Check `unwrap_used` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#unwrap_used
This adds the following Clippy configuration to crates;
#![deny(clippy::unwrap_used)]
**Warning** while tests and compiler do not show any errors, the submitted
changes are very much a Work In Progress and mistakes may have been made. Check
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/67
Merge Request thread for more details.
|
| |
|
|
| |
Issue #74
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
> Check `missing_panics_doc` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#missing_panics_doc
This adds the following Clippy configuration to crates;
#![deny(clippy::missing_panics_doc)]
And adds necessary doc-comments to methods that may panic.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
> Check `implicit_clone` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#implicit_clone
This adds, and addresses, the following Clippy configuration to crates;
#![deny(clippy::implicit_clone)]
And moves related line within `maint/add_warning.py` file. My intent is to
mitigate extra edits after merging, so please let me know if I need to do this
last bit differently.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
> Check `cast_lossless` section of Clippy documentation for details;
>
> https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless
This adds the following Clippy configuration to crates;
#![deny(clippy::cast_lossless)]
And applies suggested Clippy and `cargo fmt` fixes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Thanks to cargo's version-2 feature resolver, we can require a
runtime for tests only.
I'm also making it so that the functions that create or fetch
Runtimes only exist when one of the runtime features is enabled.
For now that seems like a better solution than having those
functions exist but panic.
Closes #129.
|
| | |
|
| | |
|
| |
|
|
|
| |
Improve testing for cases where change_state() is given a bad
function.
|
| |
|
|
|
|
|
| |
To make this work we have to wrap std::io::Error in an Arc. The
benefit of having these errors implement Clone is that we can
provide the same Error in response to multiple requests when they
are all waiting on the same operation.
|
| | |
|
| |
|
|
|
|
| |
This would have saved ahf and me a lot of confusion in debugging a
situation where we were cloning a reference of a type that didn't
implement Clone.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is a somewhat obnoxious change in its scope and requirements,
but it makes it easier to understand what the real public and
private parts of our APIs are.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Since these parts are testing-only, let's take steps to make sure we
don't ship them in production by accident.
|
| |
|
|
|
|
| |
Now that we have MockNetRuntime and MockSleepRuntime, we can use
them to test a channel-builder by replaying the contents of a TLS
stream that it will accept.
|
| | |
|
| |
|
|
|
|
|
|
| |
These lints force us to declare our exported enums and
exhaustive-looking structs as non-exhaustive (so that we can add to
them in the future without breaking our API) or to explicitly
disable the warning for a given enum/struct (to say that we _intend_
for additions to be a breaking change).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Additionally:
Use futures::future::Shared instead of event_listener.
|
| |
|
|
|
| |
It seemed like a good idea at first, but we need to be able to
tell the difference between these error types more easily.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is a big change, but it is a step towards our goal of removing
tor_rtcompat:: calls directly.
|
| |
|
|
|
| |
Now there is nothing in principle that you couldn't access from a
Runtime implementation.
|
| | |
|
| |
|
|
| |
Now we don't need runtime-specific stuff in tor-chanmgr.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now other crates don't need any 'ifdef tokio' code, since there
are wrappers that implement 'futures' right.
Technically, the 'futures' traits are in some ways less good than
the tokio ones, but we need a consistent API if we want to support
WASM someday and keep support for async_std. I'd rather hold out
hope for a future version of futures::io working like tokio than to
fix ourselves into the tokioverse forever.
|
| | |
|