Fix typos

crates/arti-bench/src/main.rs

@@ -89,7 +89,7 @@ pub struct ClientTiming {
     started_ts: SystemTime,
     /// When the client received the first byte from the server.
     first_byte_ts: SystemTime,
-    /// When the client finsihed reading the server's payload.
+    /// When the client finished reading the server's payload.
     read_done_ts: SystemTime,
     /// When the payload was successfully written to the server.
     copied_ts: SystemTime,

crates/arti-client/src/address.rs

@@ -99,7 +99,7 @@ pub struct TorAddr {
 }
 
 impl TorAddr {
-    /// Construct a TorAddr from its consituent parts, rejecting it if the
+    /// Construct a TorAddr from its constituent parts, rejecting it if the
     /// port is zero.
     fn new(host: Host, port: u16) -> Result<Self, TorAddrError> {
         if port == 0 {

crates/arti-config/src/cmdline.rs

@@ -46,7 +46,7 @@ impl CmdLine {
     /// Try to adjust the contents of a toml deserialization error so
     /// that instead it refers to a single command-line argument.
     fn convert_toml_error(&self, s: &str, pos: Option<(usize, usize)>) -> String {
-        /// Regex to match an error message fro the toml crate.
+        /// Regex to match an error message from the toml crate.
         static RE: Lazy<Regex> = Lazy::new(|| {
             Regex::new(r"^(.*?) at line [0-9]+ column [0-9]+$").expect("Can't compile regex")
         });

crates/arti/src/trace.rs

@@ -128,7 +128,7 @@ pub(crate) struct LogGuards {
 /// Set up logging.
 ///
 /// Note that the returned LogGuard must be dropped precisely when the program
-/// quits; they're used to ensure that all the log messges are flushed.
+/// quits; they're used to ensure that all the log messages are flushed.
 pub(crate) fn setup_logging(config: &LoggingConfig, cli: Option<&str>) -> Result<LogGuards> {
     // Important: We have to make sure that the individual layers we add here
     // are not filters themselves.  That means, for example, that we can't add

crates/tor-circmgr/src/mgr.rs

@@ -1235,7 +1235,7 @@ fn spawn_expiration_task<B, R>(
     let duration = exp_inst.saturating_duration_since(now);
 
     if duration == Duration::ZERO {
-        // Circuit should alread expire. Expire it now.
+        // Circuit should already expire. Expire it now.
         let cm = if let Some(cm) = Weak::upgrade(&circmgr) {
             cm
         } else {

crates/tor-proto/src/circuit.rs

@@ -88,7 +88,7 @@ pub const CIRCUIT_BUFFER_SIZE: usize = 128;
 /// mutable state, and does the actual work.
 //
 // Effectively, this struct contains two Arcs: one for `hops` and one for
-// `control` (which surely has soemthing Arc-like in it).  We cannot unify
+// `control` (which surely has something Arc-like in it).  We cannot unify
 // these by putting a single Arc around the whole struct, and passing
 // an Arc strong reference to the `Reactor`, because then `control` would
 // not be dropped when the last user of the circuit goes away.  We could

crates/tor-proto/src/circuit/sendme.rs

@@ -77,7 +77,7 @@ where
     _dummy: std::marker::PhantomData<P>,
 }
 
-/// Helper: parameterizes a window to determine its maximum and its increment.
+/// Helper: parametrizes a window to determine its maximum and its increment.
 pub(crate) trait WindowParams {
     /// Largest allowable value for this window.
     fn maximum() -> u16;

doc/CONFIG-NOTES.md

@@ -8,7 +8,7 @@ There should be one coherent schema/data model for our configuration.  It should
 
 The schema should be reified in serde implementations, our config reader, and builder pattern methods etc. - i.e., all these methods should be equivalent.  There shouldn't be different names or semantics depending how the config is fed into our code.
 
-We should make client construction using default config file locations easy (at leasat as easy as construction with hardcoded defaults).  That will make it easy for embedders to provide user-tweakable config.
+We should make client construction using default config file locations easy (at least as easy as construction with hardcoded defaults).  That will make it easy for embedders to provide user-tweakable config.
 
 We should add some warnings to the docs for configuration settings which have the potential to deanonymize users.  (Or possibly blanket warnings.)  This should aim to discourage not only users but also embedders from making poor choices.
 
@@ -34,11 +34,11 @@ Since the "built" config is now private, the builder-generated `build` method be
 
 ## Visibility of `FooConfig` structs
 
-We have decided that `tor-*` crates have much more unstable APIs than `arti-*`.  Configuration is exposed via the config file format, and therefore a semantically equivalent view should be avialable via the APIs.
+We have decided that `tor-*` crates have much more unstable APIs than `arti-*`.  Configuration is exposed via the config file format, and therefore a semantically equivalent view should be available via the APIs.
 
 So each `FooConfig` needs to be re-exported by `arti-client`, and semver-breaking changes to those are semver breaks for arti.
 
-## Division between sources and configs; Loading, embeddding, etc.
+## Division between sources and configs; Loading, embedding, etc.
 
 ### Discussion
 
@@ -57,7 +57,7 @@ All of the `FooConfig` structs should be made directly `Deserialize` and `Serial
 The knowledge of the default config file location(s) and sources should be (exposed) in `arti-client` (not `arti`), with the implication that we hope that most embedders will use it.
 (`tor-config` can continue to be the actual implementation of env vars, default path lookup, etc.)
 
-Individual `tor-*` crates will retain their knowledge of their own configuration.  arti-config will retain the the knowledge of executable-sepcific config settings (notably logging), and can be reused by shallow embedders if they like.
+Individual `tor-*` crates will retain their knowledge of their own configuration.  arti-config will retain the the knowledge of executable-specific config settings (notably logging), and can be reused by shallow embedders if they like.
 
 ### API suggestions
 
@@ -83,7 +83,7 @@ For embedders, `arti-client` should provide a method a bit like this
             #[flatten] tor: TorConfig,
             #[flatten] rest: T,
         }
-        ... load a CombinedCnfig from the usual Tor config files ...
+        ... load a CombinedConfig from the usual Tor config files ...
 ```
 
 On the principle of not having important knowledge only entangled in some more complicated machinery, there should probably be a ```fn usual_config_files() -> Vec<PathBuf>``` (or something).
@@ -107,9 +107,9 @@ For now I suggest retaining `config`.  At least, the code that knows we're using
  * Default config file location is currently `./arti-config.toml`.  This should 
 be changed (to XDG dirs probably)
 
- * `arti_defaults.toml`: this duplicates the default settings baked into the code.  This is kind of inevitable if we want to supplyy an example, but there is a big risk of divergence.  Either (a) there should be a test case that the defaults match the baked-in ones or (b) there should be no baked-in ones and instead things should be read from this file.  Also, it is in danger of being taken as an example config file, which is not great if we ever want to change the defaults.  Suggest we comment out every setting.  (The test case or run-time defaulting will now need to use a mechanically-uncommented versions.)
+ * `arti_defaults.toml`: this duplicates the default settings baked into the code.  This is kind of inevitable if we want to supply an example, but there is a big risk of divergence.  Either (a) there should be a test case that the defaults match the baked-in ones or (b) there should be no baked-in ones and instead things should be read from this file.  Also, it is in danger of being taken as an example config file, which is not great if we ever want to change the defaults.  Suggest we comment out every setting.  (The test case or run-time defaulting will now need to use a mechanically-uncommented versions.)
 
- * Configuration errors will continue to be mapped to `tor_config::ConfigBuildError`; in line with our new error handling proposal, at the toplevel these will turn into a kind on the portmanteau error returned from `bootstrap`.
+ * Configuration errors will continue to be mapped to `tor_config::ConfigBuildError`; in line with our new error handling proposal, at the top level these will turn into a kind on the portmanteau error returned from `bootstrap`.
 
  * IMO we should (generally) enable the `setter(into)` and `try_setter` features of `config`.
 

doc/Errors.md

@@ -30,7 +30,7 @@ Everywhere else besides arti_error::Error, we try to make our error types follow
  * Whenever appropriate, we have a `pub fn kind(&self) -> ErrorKind` function.
  * When a  public function can fail for a number of reasons that are much more limited than the crate's entire Error type, we should consider give that function its own Error type.
  * We use `Box<>` as needed to keep the size of the enumeration fairly small.
- * We allow more instability in these types than we allow in arti_client: these types should be inaccessable from the arti_client when "error-details" is not enabled.
+ * We allow more instability in these types than we allow in arti_client: these types should be inaccessible from the arti_client when "error-details" is not enabled.
 
 
 ## SOME EXAMPLES

doc/iOS.md

@@ -14,7 +14,7 @@ Finally: These guidelines are correct as far as we know, but they haven't
 been tested by many people. If you find any problems in them, please let us
 know!
 
-## Installing the requiremments
+## Installing the requirements
 
 First install targets so Rust know how to compile to iOS
 ```sh
@@ -108,7 +108,7 @@ OTHER_LDFLAGS = (
 
 In the Release section, add the same block, but replace `debug` at the end of each path with `release`.
 
-Now you can start calling your Rust functions from Swift like normal functions. Types are a bit unneasy to
+Now you can start calling your Rust functions from Swift like normal functions. Types are a bit difficult to
 work with, strings get transformed into char\* at the FFI interface, and Swift consider them as 
 `Optional<UnsafeMutablePointer<CChar>>` which need unwrapping and conversion before being used. You also
 need to free such a pointer by passing it back to Rust and dropping the value there. Otherwise these
@@ -119,10 +119,10 @@ You can now build your application, and test it in an emulator or on your device
 ## Tips and caveats
 
 You can find a sample project to build a very basic app using Arti [here](https://gitlab.torproject.org/trinity-1686a/arti-mobile-example/).
-It does not respect most good practices of app developement, but should otherwise be a good starting point.
+It does not respect most good practices of app development, but should otherwise be a good starting point.
 
 ## Generating C headers from Rust code
-Instead of writing C headers manually and hopping to not make misstakes, it's possible to generate them
+Instead of writing C headers manually and hopping to not make mistakes, it's possible to generate them
 automatically by using cbindgen. First install it.
 ```sh
 $ cargo install cbindgen

maint/with_coverage.sh

@@ -142,7 +142,7 @@ if [ "$format" == cobertura ]; then
 	echo "Full report: $COVERAGE_BASEDIR/$output"
 	exit
 elif [ "$format" != html ]; then
-	# no html post processing when outputing non html result
+	# no html post processing when outputting non html result
 	echo "Full report: $COVERAGE_BASEDIR/$output"
 	exit
 fi