| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| | |
Fix typos (using the typos-cli tool).
See merge request tpo/core/arti!486
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Builders additionally derive: Debug, Serialize, Deserialize.
* Validated structs no longer derive: Serialize, Deserialize
and all related attributes deleted.
* As a consequence, all the `#[serde(deny_unknown_fields)]`
are gone. That means that right now unknown fields are totally
ignored. This is good for compatibility but poor for useability.
Doing something better here is arti#417, in progress.
* As a consequence, delete tor_dirmgr::retry::default_parallelism.
(The default value was already duplicated into a builder attr.)
|
| |
|
|
|
| |
Apropos
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/474#note_2800481
|
| | |
|
| |
|
|
| |
This is for lists of plain types (non-builder types).
|
| |
|
|
|
|
| |
This allows us to use this with an item builder type which doesn't
impl Default. (Obviously this only makes sense for items which aren't
actually builders.)
|
| |
|
|
|
|
|
|
| |
It is Quite Vexing that we have to use [ ] rather than the < > around
the generics, particularly given that we are also using [ ] to signal
"this is arrayish".
Signed-off-by: Ian Jackson <[email protected]>
|
| |
|
|
|
|
| |
The docs were a lie. $docs_and_attrs was missing from the expander.
And add a note about how any supplied docs are handled.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new API is (roughly) as discussed in
https://gitlab.torproject.org/tpo/core/arti/-/issues/451
This is quite a large commit and it is not convenient to split it up.
It contains the following changes:
* Redo the list builder and accessor macros implemnetation,
including docs and tests.
* Change uses of define_list_config_builder. In each case:
- Move the docs about the default value to the containing field.
- Remove the other docs (which were just recapitulations, and
are now not needed since the ListBuilder is no longer public).
- Rewmove or replace `pub` in the define_list_builder_helper call,
so that the builder is no longer public.
- Change the main macro call site to use define_list_builder_helper.
- Add a call to define_list_builder_accessors.
* Make the module `list_builder` pub so that we have somewhere to
put the overview documentation.
* Consequential changes:
- Change `outer.inner().replace(X)` to `outer.set_inner(X)`
- Consequential changes to imports (`use` statements).
|
| |
|
|
|
| |
This removes a caveat from the API and will be convenient for what is
coming.
|
| |
|
|
| |
The list accessor macro is going to want this.
|
| |
|
|
|
|
| |
Use MessagePack.
Signed-off-by: Ian Jackson <[email protected]>
|
| |
|
|
|
|
| |
And provide round-trip tests.
As per https://gitlab.torproject.org/tpo/core/arti/-/issues/371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document that this can contain either a string for expansion, or a
literal PathBuf not for expansion.
Rename the `from_path` method to `new_literal`: a very important
difference is whether it gets expanded - less important than the Rust
type. Also, now it takes `Into<PathBuf>`, which avoids a needless
clone.
(We don't change the API in `arti-client` because
`&tempfile::Tempdir()` doesn't implement `Into<PathBuf>`, so
`arti-client` has to have some new `as_ref` calls.)
Provide accessors `as_unexpanded_str` and `as_literal_path`. The
deserialisation already makes this part of the stable API,l so not
pvoding accessors seems just obstructive. They are useful for tests,
too.
Add tests for the new entrypoints, and for deserialisation of both
variants from TOML (via config, or directly) and JSON.
|
| |
|
|
|
|
|
|
| |
We introduce LiteralPath struct, so that a literal path deserialises
from
some_path = { literal: "actual path string" }
This makes the deserialisation unambiguous.
|
| |
|
|
|
| |
Because the macro output is private, if we miss one out of the tests,
it doesn't fail due to dead code :-).
|
| |
|
|
|
|
|
|
|
| |
Really, we probably don't want any of these not to be pub, but it
triggers "unreachable pub" in my test cases, and making it not pub by
mistake seems not very serious, and likely to be noticed.
Making the struct private in the test cases has the useful effect of
checking that all the methods are tested.
|
| |
|
|
|
|
|
| |
I don't think we need to bother with things in the prelude,
but doing it for serde and ConfigBuildError seems nice.
Noticed while writing a test case.
|
| |
|
|
|
|
|
| |
And add an imprecation in define_list_config_builder's doc comment do
do so in future for other invocations of the macro.
Add add the missing full stops.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/471#note_2798027
|
| |
|
|
|
| |
Requested in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/471#note_2798022
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/471#note_2798026
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/471#note_2798024
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/471#note_2798020
|
| |
|
|
|
| |
This will be useful especially for simple lists where the entry
doesn't need a separate builder type.
|
| |
|
|
|
|
| |
This replaces two almost-identical sets of structs and impls. More
are on the way, as per
https://gitlab.torproject.org/tpo/core/arti/-/issues/447
|
| |
|
|
| |
We are going to be using sub-field builders.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Disable clippy::clone_on_ref_ptr
See merge request tpo/core/arti!352
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This lint is IMO inherently ill-conceived.
I have looked for the reasons why this might be thought to be a good
idea and there were basically two (and they are sort of contradictory):
I. "Calling ‘.clone()` on an Rc, Arc, or Weak can obscure the fact
that only the pointer is being cloned, not the underlying data."
This is the wording from
https://rust-lang.github.io/rust-clippy/v0.0.212/#clone_on_ref_ptr
It is a bit terse; we are left to infer why it is a bad idea to
obscure this fact. It seems to me that if it is bad to obscure some
fact, that must be because the fact is a hazard. But why would it be
a hazard to not copy the underlying data ?
In other languages, faliing to copy the underlying data is a serious
correctness hazard. There is a whose class of bugs where things were
not copied, and then mutated and/or reused in multiple places in ways
that were not what the programmer intended. In my experience, this is
a very common bug when writing Python and Javascript. I'm told it's
common in golang too.
But in Rust this bug is much much harder to write. The data inside an
Arc is immutable. To have this bug you'd have use interior mutability
- ie mess around with Mutex or RefCell. That provides a good barrier
to these kind of accidents.
II. "The reason for writing Rc::clone and Arc::clone [is] to make it
clear that only the pointer is being cloned, as opposed to the
underlying data. The former is always fast, while the latter can
be very expensive depending on what is being cloned."
This is the reasoning found here
https://github.com/rust-lang/rust-clippy/issues/2048
This is saying that *not* using Arc::clone is hazardous.
Specifically, that a deep clone is a performance hazard.
But for this argument, the lint is precisely backwards. It's linting
the "good" case and asking for it to be written in a more explicit
way; while the supposedly bad case can be written conveniently.
Also, many objects (in our codebase, and in all the libraries we use)
that are Clone are in fact simply handles. They contain Arc(s) (or
similar) and are cheap to clone. Indeed, that is the usual case.
It does not make sense to distinguish in the syntax we use to clone
such a handle, whether the handle is a transparent Arc, or an opaque
struct containing one or more other handles.
Forcing Arc::clone to be written as such makes for code churn when a
type is changed from Arc<Something> to Something: Clone, or vice
versa.
|
| |/ |
|
| |
|
|
| |
Closes #338.
|
| |
|
|
| |
This required a few new ErrorKinds.
|
| | |
|
| |
|
|
| |
Closes #246.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
We don't want MutCfg to be automatially coneable, or we'll wind up with
surprises like the one that this patch fixes in TorClient.
(The "surprise" is that reconfigure() would only apply its
client-specific options to one client instance.)
|
| |
|
|
|
| |
This will help in the case when a configuration can only partially
change.
|
| |
|
|
|
|
|
|
|
| |
It's useful to keep configuration objects inside a RwLock<Arc<>>, so we
can have slightly-stale pointers to the existing configuration structure
without holding locks too long.
This code adds a MutCfg type with basic support for this pattern,
and functions to make it a bit more ergonomic.
|
| |
|
|
|
|
|
| |
This patch doesn't actually make anything reconfigurable, but it
does create an API that will tell you "you can't change the value of
that!" If the API looks reasonable, I can start making it possible
to change the values of individual items.
|
| |
|
|
|
|
|
|
| |
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.
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
