| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| | |
The redundant method was a `to_owned` that probably shouldn't have
been called that. It was only used in one place.
The tests should get tor-linkspec's line coverage up above 90%.
|
| |/
|
|
|
|
|
| |
This was a relic of the old, now-unused "caret_enum!" macro.
Removing it gets caret's coverage to 100%.
Yes, technically this is a semver breaker on caret.
|
| |
|
|
|
|
|
| |
For this one I just wrote some "are things completely broken" tests
for the rand_compat wrappers. These won't detect subtle biases in
the RNGs! They'll only let you know if the wrappers have screwed up
in some way that always sets a given bit to 1 or 0.
|
| |
|
|
|
| |
This is just a matter of writing a few tests for some very easy
functions.
|
| |
|
|
| |
This was just a matter of adding a call to one function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is mostly a finger exercise, and an experiment in "what does
grcov consider to be coverage". Here's what I've found out...
* In grcov's eyes, most #[derive(Foo)] lines count as containing code;
but calling any one derived function counts as calling those lines.
* Unlike with tarpaulin, it is actually possible to reach 100% grcov
line coverage. (Tarpaulin likes to pick "}" lines and tell you that
you never reached them; or sometimes it picks expression
statements that have the effect of a return, and tells you that
they're unreached. Even with these tests, tarpaulin claims that
the line coverage of tor-units is only 97.3%.)
* In rust, it may be a bit hopeless trying to get high function
coverage. Even though we've hit every line of the tor-units crate,
the function coverage from its own tests is only 9.38% (55.41%
from other crates). I think this is probably due to derived
functions, or maybe due to generics getting instantiated?
I've got no idea; the denominator for the function coverage
lines fluctuates oddly.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Don't warn in bootstrap_from_config when error is Error::ManagerDropped
See merge request tpo/core/arti!157
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
This makes sure that we're checking for a nonzero port in all cases.
|
| |\ \ |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The new CircMgr::build_circuits_preemptively function actually causes
preemptive circuits to be built; it gets called from arti-client, like
the other daemon tasks the CircMgr has.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In preparation for making Arti build circuits preemptively, this commit
introduces `TargetCircUsage::Preemptive`, a circuit usage that works
somewhat differently from other ones: it requires at least 2 circuits to
exist that can exit the port it contains in order for an existing
circuit to match against it (path-spec.txt § 2.1.1); if that's not the
case, that usage will require building new circuits (in order that we
build enough to have 2 available).
This required refactoring how circuit reuse worked; now,
`CircList::find_open` uses the new `AbstractSpec::find_supported` trait
method, which we customize to implement the above check in the case of
`Preemptive` circuit usages. To make that work, `OpenEntry` now takes
two type parameters (the spec and circuit types), instead of taking a
builder type parameter and using its associated types. (We also got rid
of type constraints on that struct, yay!)
A WIP implementation of a preemptive circuit predictor that implements
path-spec.txt § 2.1.1 is also included, but this will require additional
effort to wire it up with the `CircMgr` properly.
|
| | | | | |
|
| |\ \ \ \ |
|
| | | | | | |
|
| | | | | | |
|
| |\ \ \ \ \ |
|
| | | |_|_|/
| |/| | | |
|
| |\ \ \ \ \ |
|
| | |/ / / / |
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | |/ / /
| |/| | | |
|
| | |/ / /
|/| | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Change sane_defaults() and with_directories()
See merge request tpo/core/arti!155
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The sane_defaults() call is now the same as you get from a default
builder: by convention, we just call that method Default::default().
The with_directories() constructor makes more sense as a constructor
for the TorClientConfigBuilder than for TorClientConfig.
|
| | | | | | |
|
| |/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also fix a couple of warnings introduced by now-unneeded imports
with new ed25519 crate.
This is part of the process for releasing our next version.
|
| |\ \ \ \
| |_|_|/
|/| | | |
|
| | | | |
| | | |
| | | |
| | | | |
(Also fix a couple of typos)
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Make sure that we can change elements, and we can reconstruct builders
that give us the same thing.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This commit implements the "metabuilder" pattern and the "builder
reconstruction" pattern for the ArtiConfig type.
I'm not 100% that this will be necessary, but it will certainly help
with testing.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
When we deserialize a configuration, we should reject unknown variables
(except when we have an explicit reason to allow them).
|
| | | | |
| | | |
| | | |
| | | | |
These don't need to be exposed any longer.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm still not 100% sure this is the right move: should we encourage
app developers to always pick their own directories? Or should we
make it easy for them to use, well, `sane_defaults`?
This patch takes the second approach.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This test seems unreliable on CI: we've got to disable them for now
so that we have a working CI system. The CI failure is #238; the
ticket to repair them is #244.
|
| |\ \ \ |
|
