mirrors/arti.git/crates/tor-config/src/lib.rs, branch arti-v2.4.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.4.02026-05-27T12:05:52Zconfig: Simplify ConfigurationTree::merge_from to take &mut self.2026-05-27T12:05:52ZNick Mathewsonnickm@torproject.org2026-05-21T14:28:43Zurn:sha1:54c99e93b5d9cd0a3e1cfb66c249c7aeeba2ecceconfig: Add a method to fill in a builder with unset defaults2026-05-27T12:05:52ZNick Mathewsonnickm@torproject.org2026-05-18T14:13:34Zurn:sha1:f1df3d1c8d83fd63d484cccf0bf45534f0369761
This new method modifies a builder by replacing any unset values
that have a default with that default. We're using this method
so that we can re-serialize a builder into a `ConfigurationTree`
with all of its default values included.
In all cases, `b.apply_defaults()?; b.build()` should produce
the same output as `b.build()`.
The interesting parts of this commit are in tor_config::load
and tor_config::derive. The rest of this commit just adds
`apply_defaults` to other builders that _aren't_ made with
`derive_deftly(TorConfig)`.
Move metrics config types to tor-config.2026-05-26T15:47:40ZWesley Aptekar-Casselsme@wesleyac.com2026-05-12T21:50:35Zurn:sha1:e1fa3995ed7e247aa63483c6c39653b6059ab529
This will allow these types to be shared by arti and arti-relay.
This does change these types from being behind the experimental-api
flag. I think this is okay, as tor-config is not a stable crate anyways,
but it's worth keeping in mind.
There is also an argument to be made for having two separate types, one
in arti and one in arti-relay, as we do for LoggingConfig. I think that
using a single type has benefits, and we should strive to eventually
merge the LoggingConfigs, for instance, and perhaps other types, but it
doesn't seem critical in either direction at the moment.
config: Implement Default for ConfigurationTree.2026-05-18T15:53:37ZNick Mathewsonnickm@torproject.org2026-05-05T14:51:31Zurn:sha1:9b50c0e66a22f893e374240be2d33cd2377fc218config: Add a merge_from method to ConfigurationTree2026-05-18T15:53:24ZNick Mathewsonnickm@torproject.org2026-05-04T17:50:05Zurn:sha1:ff772adf75b81d33a4339846e56cde62b1f8c127
We'll use this in RPC to implement configuration changing.
tor-config: Allow inspecting parts of a ConfigurationTree.2026-05-12T13:06:25ZNick Mathewsonnickm@torproject.org2026-05-04T17:18:48Zurn:sha1:e96596491026848ab93b7e3ea567209d2bb4bd3a
This will be used by RPC. Probably. It might actually be a better
to re-serialize the configuration after parsing it, so that our
inspection functions can see default values.
Document resolve_option_general behavior2026-02-18T17:43:51Zmoumenalaouimoumenalaoui@proton.me2026-02-13T21:49:03Zurn:sha1:071d739a342fefc9381c46469e6a24b4c279f62bAllow clippy::collapsible_if to trigger2026-02-16T15:22:24ZGabriela Moldovangabi@torproject.org2026-02-09T11:49:02Zurn:sha1:ade1d59e8e44c93b6ee447b72a2948a9652ec44e
`clippy::collapsible_if` started triggering after bumping the MSRV to
1.88.
Since this triggers from a lot of places, and since there even are a
couple of instances where we explicitly allow `clippy::collapsible_ifs`,
I've opened #2342 for deciding what to do about it.
tor-config: remove `resolve_alternative_specs` function2026-02-02T03:26:01ZSteven Engleropara@torproject.org2026-02-02T02:47:20Zurn:sha1:883c182da88ef05ba2126304f793c63ea7402630arti: remove `resolve_listen_port!` macro2026-01-30T02:36:23ZSteven Engleropara@torproject.org2026-01-30T02:02:24Zurn:sha1:7050faf87709ac99403813ac4d7d5ef0df60f4a1
I'm undecided whether we want to keep `resolve_alternative_specs`
around, but it seems possible/likely that we'll want it in the future,
so I think we can keep it.