doc: Updates paths to the top of the source tree.

Example:
.../doc/HACKING is now doc/HACKING

4 files changed, 21 insertions, 21 deletions

diff --git a/doc/HACKING/CodingStandards.md b/doc/HACKING/CodingStandards.md
index bcb945befd..73f8f95a2c 100644
--- a/doc/HACKING/CodingStandards.md
+++ b/doc/HACKING/CodingStandards.md
@@ -34,7 +34,7 @@ Did you remember...
 
 If you are submitting a major patch or new feature, or want to in the future...
 
-   - Set up Chutney and Stem, see `.../doc/HACKING/WritingTests.md`
+   - Set up Chutney and Stem, see `doc/HACKING/WritingTests.md`
    - Run `make test-full` to test against all unit and integration tests.
 
 If you have changed build system components:
diff --git a/doc/HACKING/CodingStandardsRust.md b/doc/HACKING/CodingStandardsRust.md
index f3b6485e90..22b6f93435 100644
--- a/doc/HACKING/CodingStandardsRust.md
+++ b/doc/HACKING/CodingStandardsRust.md
@@ -1,38 +1,38 @@
 Rust Coding Standards
 =======================
 
-You MUST follow the standards laid out in `.../doc/HACKING/CodingStandards.md`,
+You MUST follow the standards laid out in `doc/HACKING/CodingStandards.md`,
 where applicable.
 
 Module/Crate Declarations
 ---------------------------
 
 Each Tor C module which is being rewritten MUST be in its own crate.
-See the structure of `.../src/rust` for examples.
+See the structure of `src/rust` for examples.
 
 In your crate, you MUST use `lib.rs` ONLY for pulling in external
 crates (e.g. `extern crate libc;`) and exporting public objects from
 other Rust modules (e.g. `pub use mymodule::foo;`).  For example, if
-you create a crate in `.../src/rust/yourcrate`, your Rust code should
-live in `.../src/rust/yourcrate/yourcode.rs` and the public interface
-to it should be exported in `.../src/rust/yourcrate/lib.rs`.
+you create a crate in `src/rust/yourcrate`, your Rust code should
+live in `src/rust/yourcrate/yourcode.rs` and the public interface
+to it should be exported in `src/rust/yourcrate/lib.rs`.
 
 If your code is to be called from Tor C code, you MUST define a safe
 `ffi.rs`.  See the "Safety" section further down for more details.
 
 For example, in a hypothetical `tor_addition` Rust module:
 
-In `.../src/rust/tor_addition/addition.rs`:
+In `src/rust/tor_addition/addition.rs`:
 
     pub fn get_sum(a: i32, b: i32) -> i32 {
         a + b
     }
 
-In `.../src/rust/tor_addition/lib.rs`:
+In `src/rust/tor_addition/lib.rs`:
 
     pub use addition::*;
 
-In `.../src/rust/tor_addition/ffi.rs`:
+In `src/rust/tor_addition/ffi.rs`:
 
     #[no_mangle]
     pub extern "C" fn tor_get_sum(a: c_int, b: c_int) -> c_int {
@@ -41,7 +41,7 @@ In `.../src/rust/tor_addition/ffi.rs`:
 
 If your Rust code must call out to parts of Tor's C code, you must
 declare the functions you are calling in the `external` crate, located
-at `.../src/rust/external`.
+at `src/rust/external`.
 
 <!-- XXX get better examples of how to declare these externs, when/how they -->
 <!-- XXX are unsafe, what they are expected to do —isis                     -->
@@ -107,7 +107,7 @@ You MUST include `#![deny(missing_docs)]` in your crate.
 
 For function/method comments, you SHOULD include a one-sentence, "first person"
 description of function behaviour (see requirements for documentation as
-described in `.../src/HACKING/CodingStandards.md`), then an `# Inputs` section
+described in `src/HACKING/CodingStandards.md`), then an `# Inputs` section
 for inputs or initialisation values, a `# Returns` section for return
 values/types, a `# Warning` section containing warnings for unsafe behaviours or
 panics that could happen.  For publicly accessible
@@ -133,7 +133,7 @@ describing how the function/object is expected to be used.
 
 Integration tests SHOULD go into a `tests/` directory inside your
 crate.  Unittests SHOULD go into their own module inside the module
-they are testing, e.g. in `.../src/rust/tor_addition/addition.rs` you
+they are testing, e.g. in `src/rust/tor_addition/addition.rs` you
 should put:
 
     #[cfg(test)]
@@ -172,7 +172,7 @@ for basic benchmarks, is only used when running benchmarks via `cargo
 bench --features bench`.
 
 Finally, to write your benchmark code, in
-`.../src/rust/tor_addition/addition.rs` you SHOULD put:
+`src/rust/tor_addition/addition.rs` you SHOULD put:
 
     #[cfg(all(test, features = "bench"))]
     mod bench {
diff --git a/doc/HACKING/GettingStarted.md b/doc/HACKING/GettingStarted.md
index cb116cb577..3be9917d33 100644
--- a/doc/HACKING/GettingStarted.md
+++ b/doc/HACKING/GettingStarted.md
@@ -57,7 +57,7 @@ Once you've reached this point, here's what you need to know.
      looking around it to see how it fits together!
 
      We do some unusual things in our codebase.  Our testing-related
-     practices and kludges are explained in `.../doc/HACKING/WritingTests.md`.
+     practices and kludges are explained in `doc/HACKING/WritingTests.md`.
 
      If you see something that doesn't make sense, we love to get
      questions!
@@ -120,7 +120,7 @@ Once you've reached this point, here's what you need to know.
      As you write your code, you'll probably want it to fit in with the
      standards of the rest of the Tor codebase so it will be easy for us
      to review and merge.  You can learn our coding standards in
-     `.../doc/HACKING` directory.
+     `doc/HACKING` directory.
 
      If your patch is large and/or is divided into multiple logical
      components, remember to divide it into a series of Git commits.  A
@@ -132,7 +132,7 @@ Once you've reached this point, here's what you need to know.
      ensure that it runs correctly.  Also, all code should actually be
      _run_ by somebody, to make sure it works.
 
-     See `.../doc/HACKING/WritingTests.md` for more information on how we test things
+     See `doc/HACKING/WritingTests.md` for more information on how we test things
      in Tor.  If you'd like any help writing tests, just ask!  We're
      glad to help out.
 
diff --git a/doc/HACKING/GettingStartedRust.md b/doc/HACKING/GettingStartedRust.md
index 14ab87136d..9c3101e9a6 100644
--- a/doc/HACKING/GettingStartedRust.md
+++ b/doc/HACKING/GettingStartedRust.md
@@ -5,7 +5,7 @@ Getting Started
 -----------------
 
 Please read or review our documentation on Rust coding standards
-(`.../doc/HACKING/CodingStandardsRust.md`) before doing anything.
+(`doc/HACKING/CodingStandardsRust.md`) before doing anything.
 
 Please also read
 [the Rust Code of Conduct](https://www.rust-lang.org/en-US/conduct.html). We
@@ -142,8 +142,8 @@ Adding your Rust module to Tor's build system
 -----------------------------------------------
 
 0. Your translation of the C module should live in its own crate(s)
-   in the `.../tor/src/rust/` directory.
-1. Add your crate to `.../tor/src/rust/Cargo.toml`, in the
+   in the `src/rust/` directory.
+1. Add your crate to `src/rust/Cargo.toml`, in the
    `[workspace.members]` section.
 2. Add your crate's files to src/rust/include.am
 
@@ -158,7 +158,7 @@ How to test your Rust code
 
 Everything should be tested full stop.  Even non-public functionality.
 
-Be sure to edit `.../tor/src/test/test_rust.sh` to add the name of your
+Be sure to edit `src/test/test_rust.sh` to add the name of your
 crate to the `crates` variable! This will ensure that `cargo test` is
 run on your crate.
 
@@ -177,4 +177,4 @@ Tor's integration tests should also pass:
 Submitting a patch
 =====================
 
-Please follow the instructions in `.../doc/HACKING/GettingStarted.md`.
+Please follow the instructions in `doc/HACKING/GettingStarted.md`.