fix: prefix the actual file name if referenced listing is in another ch.md

Author: gaoyuan

src/ch01-03-hello-cargo.md

@@ -98,7 +98,7 @@ fn main() {
 ```
 
 Cargo has generated a “Hello, world!” program for you, just like the one we
-wrote in [Listing 1-1](#listing-1-1)! So far, the differences between our project and the
+wrote in [Listing 1-1](ch01-02-hello-world.md#listing-1-1)! So far, the differences between our project and the
 project Cargo generated are that Cargo placed the code in the _src_ directory
 and we have a _Cargo.toml_ configuration file in the top directory.
 

src/ch04-02-references-and-borrowing.md

@@ -1,6 +1,6 @@
 ## References and Borrowing
 
-The issue with the tuple code in [Listing 4-5](#listing-4-5) is that we have to return the
+The issue with the tuple code in [Listing 4-5](ch04-01-what-is-ownership.md#listing-4-5) is that we have to return the
 `String` to the calling function so we can still use the `String` after the
 call to `calculate_length`, because the `String` was moved into
 `calculate_length`. Instead, we can provide a reference to the `String` value.

src/ch06-03-if-let.md

@@ -47,7 +47,7 @@ runs code when the value matches one pattern and then ignores all other values.
 We can include an `else` with an `if let`. The block of code that goes with the
 `else` is the same as the block of code that would go with the `_` case in the
 `match` expression that is equivalent to the `if let` and `else`. Recall the
-`Coin` enum definition in [Listing 6-4](#listing-6-4), where the `Quarter` variant also held a
+`Coin` enum definition in [Listing 6-4](ch06-02-match.md#listing-6-4), where the `Quarter` variant also held a
 `UsState` value. If we wanted to count all non-quarter coins we see while also
 announcing the state of the quarters, we could do that with a `match`
 expression, like this:

src/ch07-03-paths-for-referring-to-an-item-in-the-module-tree.md

@@ -15,7 +15,7 @@ A path can take two forms:
 Both absolute and relative paths are followed by one or more identifiers
 separated by double colons (`::`).
 
-Returning to [Listing 7-1](#listing-7-1), say we want to call the `add_to_waitlist` function.
+Returning to [Listing 7-1](ch07-02-defining-modules-to-control-scope-and-privacy.md#listing-7-1), say we want to call the `add_to_waitlist` function.
 This is the same as asking: what’s the path of the `add_to_waitlist` function?
 [Listing 7-3](#listing-7-3) contains [Listing 7-1](#listing-7-1) with some of the modules and functions
 removed.

src/ch07-04-bringing-paths-into-scope-with-the-use-keyword.md

@@ -1,7 +1,7 @@
 ## Bringing Paths into Scope with the `use` Keyword
 
 Having to write out the paths to call functions can feel inconvenient and
-repetitive. In [Listing 7-7](#listing-7-7), whether we chose the absolute or relative path to
+repetitive. In [Listing 7-7](ch07-03-paths-for-referring-to-an-item-in-the-module-tree.md#listing-7-7), whether we chose the absolute or relative path to
 the `add_to_waitlist` function, every time we wanted to call `add_to_waitlist`
 we had to specify `front_of_house` and `hosting` too. Fortunately, there’s a
 way to simplify this process: we can create a shortcut to a path with the `use`
@@ -221,7 +221,7 @@ crate.
 
 If we’re using multiple items defined in the same crate or same module, listing
 each item on its own line can take up a lot of vertical space in our files. For
-example, these two `use` statements we had in the guessing game in [Listing 2-4](#listing-2-4)
+example, these two `use` statements we had in the guessing game in [Listing 2-4](ch02-00-guessing-game-tutorial.md#listing-2-4)
 bring items from `std` into scope:
 
 <Listing file-name="src/main.rs">

src/ch07-05-separating-modules-into-different-files.md

@@ -4,7 +4,7 @@ So far, all the examples in this chapter defined multiple modules in one file.
 When modules get large, you might want to move their definitions to a separate
 file to make the code easier to navigate.
 
-For example, let’s start from the code in [Listing 7-17](#listing-7-17) that had multiple
+For example, let’s start from the code in [Listing 7-17](ch07-04-bringing-paths-into-scope-with-the-use-keyword.md#listing-7-17) that had multiple
 restaurant modules. We’ll extract modules into files instead of having all the
 modules defined in the crate root file. In this case, the crate root file is
 _src/lib.rs_, but this procedure also works with binary crates whose crate root

src/ch10-01-syntax.md

@@ -24,7 +24,7 @@ function that uses generics.
 
 </Listing>
 
-The `largest_i32` function is the one we extracted in [Listing 10-3](#listing-10-3) that finds
+The `largest_i32` function is the one we extracted in [Listing 10-3](ch10-00-generics.md#listing-10-3) that finds
 the largest `i32` in a slice. The `largest_char` function finds the largest
 `char` in a slice. The function bodies have the same code, so let’s eliminate
 the duplication by introducing a generic type parameter in a single function.
@@ -179,7 +179,7 @@ The `Result` enum is generic over two types, `T` and `E`, and has two variants:
 `E`. This definition makes it convenient to use the `Result` enum anywhere we
 have an operation that might succeed (return a value of some type `T`) or fail
 (return an error of some type `E`). In fact, this is what we used to open a
-file in [Listing 9-3](#listing-9-3), where `T` was filled in with the type `std::fs::File` when
+file in [Listing 9-3](ch09-02-recoverable-errors-with-result.md#listing-9-3), where `T` was filled in with the type `std::fs::File` when
 the file was opened successfully and `E` was filled in with the type
 `std::io::Error` when there were problems opening the file.
 

src/ch10-03-lifetime-syntax.md

@@ -391,10 +391,10 @@ the `ImportantExcerpt` goes out of scope, so the reference in the
 
 You’ve learned that every reference has a lifetime and that you need to specify
 lifetime parameters for functions or structs that use references. However, we
-had a function in [Listing 4-9](#listing-4-9), shown again in [Listing 10-25](#listing-10-25), that compiled
+had a function in [Listing 4-9](ch04-03-slices.md#listing-4-9), shown again in [Listing 10-25](#listing-10-25), that compiled
 without lifetime annotations.
 
-<Listing number="10-25" file-name="src/lib.rs" caption="A function we defined in [Listing 4-9](#listing-4-9) that compiled without lifetime annotations, even though the parameter and return type are references">
+<Listing number="10-25" file-name="src/lib.rs" caption="A function we defined in [Listing 4-9](ch04-03-slices.md#listing-4-9) that compiled without lifetime annotations, even though the parameter and return type are references">
 
 ```rust
 {{#rustdoc_include ../listings/ch10-generic-types-traits-and-lifetimes/listing-10-25/src/main.rs:here}}
@@ -516,7 +516,7 @@ annotate lifetimes in method signatures very often.
 ### Lifetime Annotations in Method Definitions
 
 When we implement methods on a struct with lifetimes, we use the same syntax as
-that of generic type parameters, as shown in [Listing 10-11](#listing-10-11). Where we declare and
+that of generic type parameters, as shown in [Listing 10-11](ch10-01-syntax.md#listing-10-11). Where we declare and
 use the lifetime parameters depends on whether they’re related to the struct
 fields or the method parameters and return values.
 

src/ch11-01-writing-tests.md

@@ -185,7 +185,7 @@ to ensure that some condition in a test evaluates to `true`. We give the
 `assert!` macro calls `panic!` to cause the test to fail. Using the `assert!`
 macro helps us check that our code is functioning in the way we intend.
 
-In Chapter 5, [Listing 5-15](#listing-5-15), we used a `Rectangle` struct and a `can_hold`
+In Chapter 5, [Listing 5-15](ch05-03-method-syntax.md#listing-5-15), we used a `Rectangle` struct and a `can_hold`
 method, which are repeated here in [Listing 11-5](#listing-11-5). Let’s put this code in the
 _src/lib.rs_ file, then write some tests for it using the `assert!` macro.
 
@@ -344,7 +344,7 @@ the standard library types implement these traits. For structs and enums that
 you define yourself, you’ll need to implement `PartialEq` to assert equality of
 those types. You’ll also need to implement `Debug` to print the values when the
 assertion fails. Because both traits are derivable traits, as mentioned in
-[Listing 5-12](#listing-5-12) in Chapter 5, this is usually as straightforward as adding the
+[Listing 5-12](ch05-02-example-structs.md#listing-5-12) in Chapter 5, this is usually as straightforward as adding the
 `#[derive(PartialEq, Debug)]` annotation to your struct or enum definition. See
 Appendix C, [“Derivable Traits,”][derivable-traits]<!-- ignore --> for more
 details about these and other derivable traits.
@@ -413,7 +413,7 @@ debug what happened instead of what we were expecting to happen.
 
 In addition to checking return values, it’s important to check that our code
 handles error conditions as we expect. For example, consider the `Guess` type
-that we created in Chapter 9, [Listing 9-13](#listing-9-13). Other code that uses `Guess`
+that we created in Chapter 9, [Listing 9-13](ch09-03-to-panic-or-not-to-panic.md#listing-9-13). Other code that uses `Guess`
 depends on the guarantee that `Guess` instances will contain only values
 between 1 and 100. We can write a test that ensures that attempting to create a
 `Guess` instance with a value outside that range panics.

src/ch11-03-test-organization.md

@@ -225,7 +225,7 @@ function from the `it_adds_two` test in _tests/integration_test.rs_:
 ```
 
 Note that the `mod common;` declaration is the same as the module declaration
-we demonstrated in [Listing 7-21](#listing-7-21). Then, in the test function, we can call the
+we demonstrated in [Listing 7-21](ch07-05-separating-modules-into-different-files.md#listing-7-21). Then, in the test function, we can call the
 `common::setup()` function.
 
 #### Integration Tests for Binary Crates