summaryrefslogtreecommitdiff
path: root/crates/tor-config/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* Improve error from bad escapes in a toml config.Nick Mathewson2022-08-251-1/+1
| | | | | | | | | | | | | | | | | Whereas previously we would say: ``` target/debug/arti: error: invalid escape character in string: `Z` at line 9 column 14 in ../../.config/arti/arti.toml ``` we now say: ``` target/debug/arti: error: invalid escape character in string: `Z` at line 9 column 14 in ../../.config/arti/arti.toml (If you wanted to include a literal \ character, you need to escape it by writing two in a row: \\) ``` The implementation is a bit of a hack, I'm afraid, but I don't think it's all that bad. Closes #549.
* tor-config: Provide resolve_alternative_specsIan Jackson2022-08-251-0/+78
|
* tor-config: Introduce ResolutionResultsIan Jackson2022-08-251-1/+1
| | | | This will allow us to handle new kinds of warnigns etc.
* tor-config: Replace dir detection with ConfigurationSource enumIan Jackson2022-08-251-1/+1
| | | | | | | | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/682#note_2830860 And subsequent IRC discussion. Having done the work as per review comments, I don't much like the result. It's quite un-ergonomiuc. If we can't have fs autodetection, I think syntactic autodetection within sources.rs would be nearly as nice. However, I seem to be outvoted. At least the externally visible functionality (of an arti binary, say) is reasonably ergonomic.
* enable doc_auto_cfg feature on every crate when documenting for docs.rstrinity-1686a2022-08-241-0/+1
|
* tor-config: resolve_option_general: Add TODO about exampleIan Jackson2022-08-231-0/+5
|
* Fix syntax in doc comment.Nick Mathewson2022-08-231-1/+1
|
* tor-config: Provide resolve_option_general, for T: !Default etc.Ian Jackson2022-08-221-4/+43
| | | | | | | | | At one point in this MR I thought I was going to want this for arti::cfg::ListenConfig (which we don't want to be Default). In fact ListenConfig is being handled specially, but having written this function it seemed sensible to keep it. Since resolve_option becomes a wrapper for it, the existing tests exercise it.
* tor-config: Introduce PaddingLevelIan Jackson2022-08-161-0/+2
| | | | This will be used for controlling channel padding, for now.
* Run maint/add_warning crates/*/src/{lib,main}.rsIan Jackson2022-06-231-0/+3
| | | | Update all lint blocks
* impl_standard_builder: Allow for !DefaultIan Jackson2022-06-161-13/+54
|
* tor-config: impl_standard_builder: handle contexts with local ResultIan Jackson2022-06-161-1/+1
|
* config: Suppose that we might extend resolve_option to non-T::DefaultIan Jackson2022-06-101-0/+2
| | | | | As per point 3 in https://gitlab.torproject.org/tpo/core/arti/-/issues/488
* config: Do not strip_option for journald (and in future)Ian Jackson2022-06-101-0/+3
| | | | | As per point 1 in https://gitlab.torproject.org/tpo/core/arti/-/issues/488
* Fix typosDimitris Apostolou2022-06-051-2/+2
|
* tor-config: Fix a doc linkIan Jackson2022-06-011-1/+1
| | | | Nightly cargo doc complaints about this.
* Merge branch 'lint' into 'main'Ian Jackson2022-05-311-0/+3
|\ | | | | | | | | | | | | lints: Make lint blocks consistent and ensure they stay that way Closes #469 See merge request tpo/core/arti!557
| * lints: Add let_unit_value allow to all cratesIan Jackson2022-05-311-0/+1
| | | | | | | | | | From running add_warning, with manual picking of the right hunks/lines.
| * lints: Add lint block delimiters to every crateIan Jackson2022-05-311-0/+2
| | | | | | | | | | | | This was the result of: maint/add_warning crates/*/src/{lib,main}.rs and then manually curating the results.
* | tor-config: Suppress unwrap lint in testsIan Jackson2022-05-311-0/+1
| | | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/546#note_2808892
* | tor-config: resolve_option tests: disable rsutfmtIan Jackson2022-05-311-0/+1
| |
* | tor-config: Add comprehensive tests for resolve_optionIan Jackson2022-05-311-0/+71
| |
* | config: Provide tor_config::resolve_option and resolve journaldIan Jackson2022-05-301-0/+36
|/ | | | | | | | | | | | | | Canonicalise the `logging.journald` setting in the validated configuration. Now it will never be `Some("")`, even if that is what was written in the config file. This allows us to write `journald = ""` in the example configuration. (Without the canonicalisation the default builder produces `None` and the example would produce `Some("")`, which are semantically identical but fail the test.) See https://gitlab.torproject.org/tpo/core/arti/-/issues/488 for some background.
* tor-config: docs: add a lot of context and overview and xrefsIan Jackson2022-05-251-1/+41
|
* Run rustfmt following renamingIan Jackson2022-05-251-1/+1
| | | | Split into its own commit to avoid churn in the rename commits.
* tor-config: Rename resolve_return_unrecognized, ..._ignore_...Ian Jackson2022-05-251-1/+1
| | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807077
* tor-config: Rename "ignored" to "unrecognized" throughoutIan Jackson2022-05-251-1/+1
| | | | | As per review comments https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/529#note_2807076
* tor-config: Track and (by default) warn on ignored config keysIan Jackson2022-05-241-1/+1
|
* Split TorClientConfig out of ArtiConfig, and Resolvable traitIan Jackson2022-05-241-0/+2
| | | | | | | | | | | | This gets rid of `#[serde(flatten)]` which prevents serde_ignored (and other kinds of introspection) from working properly. The price is now that the toplevel has to deal with two configuration objects. The Resolvable trait is overkill right now, but is going to do More Things in a moment. In particular, we need the impl on tuples, so that the whole config can be processed in one go.
* tor-config: Introduce Builder trait and ConfigReolveErrorIan Jackson2022-05-241-5/+31
| | | | | | | | | We are going to need this for some generic code which is going to appear shortly. Having it produced by impl_standard_builder seems best. But that does mean being able to disable it, so extra stuff in the macro. Nothing uses this trait yet. ConfigResolveError is not used now either, but will be in a moment.
* tor-config: Add a lint allowIan Jackson2022-05-241-0/+1
| | | | | | | I don't understand why this isn't tripping all the time. Maybe because this is in a macro. Anyway, I am going to add a new invocation of this macro from within a test where, empirically, it trips.
* Merge branch 'arti-config-2' into 'main'Nick Mathewson2022-05-131-0/+2
|\ | | | | | | | | Abolish arti-config, replacing with tombstone crate See merge request tpo/core/arti!508
| * arti-config abolition: Move functionality to tor-configIan Jackson2022-05-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This crate no longer has any reason to exist. All its remaining functionality is generic enough to go into tor-config. In this commit, we move the contents of lib.rs into a new file in tor-config. It contains: * Code motion * The minimal "mod" and "use" changes * The minimal doc comment * A new a compat alias for ConfigurationSources. The compat alias is there because various crates currently speak of arti_config::ConfigurationSources and it is most convenient to fix them up after the type is available in tor_config.
* | impl_standard_builder: Better comments explaining the parserIan Jackson2022-05-131-1/+7
| |
* | impl_standard_builder: Have it generate FooConfig::builderIan Jackson2022-05-121-0/+7
| | | | | | | | | | This deletes many handcoded impls. It also generates lots of impls that we previously didn't have.
* | impl_standard_builder: Test the Deserialize implIan Jackson2022-05-121-14/+69
|/ | | | | | | | | | Test the Deserialize impl of every config struct. This detects bugs like the one fixed in !502. The macro now becomes more complex because it needs to take options. Right now this tt-munching option parser is overkill, but this leave space for further options in the future.
* Rename impl_standard_builder from impl_default_via_builderIan Jackson2022-05-121-3/+8
| | | | | | | | | | | | I have Plans for this macro. In particular: * I have a wip branch which tests that the Builder can be deserialised from an empty config (ie, that config reading of a config with a blank section for this item works). * I think we should autogenerate $Config::builder(), and promote that, rather than $ConfigBuilder::default(). This macro could do that.
* Merge branch 'arti-config-1' into 'main'eta2022-05-121-0/+2
|\ | | | | | | | | arti-config: Move cmdline to tor-config See merge request tpo/core/arti!498
| * arti-config: Move cmdline to tor-configIan Jackson2022-05-111-0/+2
| | | | | | | | | | | | This does not know anything about arti, only about TOML and Config. Code motion, plus necessary import adjustments.
* | Define and use impl_default_via_builderIan Jackson2022-05-111-0/+25
|/
* tor-config: Export CfgPathErrorIan Jackson2022-05-111-1/+1
| | | | | It is not clear to me how this `pub enum` survived the "inaccessible pub" lint.
* list_builder: Use Educe to derive DefaultIan Jackson2022-05-041-0/+1
| | | | | | 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.)
* Change builder list APIIan Jackson2022-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Add dependency on paste crateIan Jackson2022-05-041-0/+1
| | | | The list accessor macro is going to want this.
* list_builder: Use $crate namespaced importsIan Jackson2022-04-251-0/+1
| | | | | | | 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.
* Rename macro_first_nonempty (from macro_coalesce_args)Ian Jackson2022-04-251-1/+1
| | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/471#note_2798026
* config list-builder: Allow overriding the per-item build methodIan Jackson2022-04-251-0/+2
| | | | | This will be useful especially for simple lists where the entry doesn't need a separate builder type.
* Introduce define_list_config_builder macroIan Jackson2022-04-251-0/+1
| | | | | | 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
* Merge branch 'clippy-allow-arc-clone' into 'main'Nick Mathewson2022-03-011-1/+0
|\ | | | | | | | | Disable clippy::clone_on_ref_ptr See merge request tpo/core/arti!352
| * Disable clippy::clone_on_ref_ptrIan Jackson2022-02-241-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 07:32:39 +0000