From d179c23616984733a73c4c1a28c7aed7806cba10 Mon Sep 17 00:00:00 2001 From: Eric Huss Date: Mon, 29 Jul 2024 11:32:29 -0700 Subject: [PATCH 01/14] mdbook-trpl-listing: Add missing elided lifetimes --- packages/mdbook-trpl-listing/src/lib.rs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/packages/mdbook-trpl-listing/src/lib.rs b/packages/mdbook-trpl-listing/src/lib.rs index 7be63e4ae..619cafdf3 100644 --- a/packages/mdbook-trpl-listing/src/lib.rs +++ b/packages/mdbook-trpl-listing/src/lib.rs @@ -157,7 +157,7 @@ fn rewrite_listing(src: &str, mode: Mode) -> Result { } ev => state.events.push(Ok(ev)), }; - Ok::(state) + Ok::, String>(state) }, )?; @@ -190,7 +190,7 @@ struct ListingState<'e> { impl<'e> ListingState<'e> { fn open_listing( &mut self, - tag: pulldown_cmark::CowStr, + tag: pulldown_cmark::CowStr<'_>, mode: Mode, ) -> Result<(), String> { // We do not *keep* the version constructed here, just temporarily @@ -247,7 +247,7 @@ impl<'e> ListingState<'e> { Ok(()) } - fn close_listing(&mut self, tag: pulldown_cmark::CowStr, mode: Mode) { + fn close_listing(&mut self, tag: pulldown_cmark::CowStr<'_>, mode: Mode) { let trailing = if !tag.ends_with('>') { tag.replace("", "") } else { From de6e35c52fcdb2df7f8b156d72e3588d64f2abc5 Mon Sep 17 00:00:00 2001 From: Chris Krycho Date: Wed, 31 Jul 2024 06:59:05 -0600 Subject: [PATCH 02/14] infra: add robots.txt for GH Pages previews Block *everything*. We do not want any of this to be indexed, because we *only* use it for previews, and do not want its content to be cached or (especially!) surfaced to readers, since it may have a variety of issues ranging from pedagogical missteps to outright errors! --- ADMIN_TASKS.md | 10 ++++++++++ tools/generate-preview.sh | 4 ++++ tools/preview-robots.txt | 2 ++ 3 files changed, 16 insertions(+) create mode 100755 tools/generate-preview.sh create mode 100644 tools/preview-robots.txt diff --git a/ADMIN_TASKS.md b/ADMIN_TASKS.md index 7e9ba2cc0..9caff3004 100644 --- a/ADMIN_TASKS.md +++ b/ADMIN_TASKS.md @@ -133,3 +133,13 @@ $ dot dot/trpl04-01.dot -Tsvg > src/img/trpl04-01.svg In the generated SVG, remove the width and the height attributes from the `svg` element and set the `viewBox` attribute to `0.00 0.00 1000.00 1000.00` or other values that don't cut off the image. + +## Publish a preview to GitHub Pages + +We sometimes publish to GitHub Pages for in-progress previews. The recommended +flow for publishing is: + +- Install the `ghp-import` tool by running `pip install ghp-import` (or `pipx install ghp-import`, using [pipx][pipx]). +- In the root, run `tools/generate-preview.sh` + +[pipx]: https://pipx.pypa.io/stable/#install-pipx diff --git a/tools/generate-preview.sh b/tools/generate-preview.sh new file mode 100755 index 000000000..c2b0f2f1d --- /dev/null +++ b/tools/generate-preview.sh @@ -0,0 +1,4 @@ +#!/usr/bin/env bash + +mdbook build +cp ./tools/preview-robots.txt ./book/robots.txt diff --git a/tools/preview-robots.txt b/tools/preview-robots.txt new file mode 100644 index 000000000..1f53798bb --- /dev/null +++ b/tools/preview-robots.txt @@ -0,0 +1,2 @@ +User-agent: * +Disallow: / From df78a37109d23cd15061c36e81956ff9973edd89 Mon Sep 17 00:00:00 2001 From: Chris Krycho Date: Wed, 31 Jul 2024 07:13:14 -0600 Subject: [PATCH 03/14] infra: include ghp-import and git push in generate-preview script --- tools/generate-preview.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/generate-preview.sh b/tools/generate-preview.sh index c2b0f2f1d..a5d9022b9 100755 --- a/tools/generate-preview.sh +++ b/tools/generate-preview.sh @@ -2,3 +2,5 @@ mdbook build cp ./tools/preview-robots.txt ./book/robots.txt +ghp-import -m "rebuild GitHub Pages from generated-book" book +git push origin gh-pages From 79bce29cd716bd1d387af533661e0cbef3674cbf Mon Sep 17 00:00:00 2001 From: Vox Dai Date: Wed, 7 Aug 2024 22:51:04 +0800 Subject: [PATCH 04/14] Fix: typo Fix a typo in ch03-05-control-flow.md --- src/ch03-05-control-flow.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/ch03-05-control-flow.md b/src/ch03-05-control-flow.md index 0c7aeff13..3b72b9653 100644 --- a/src/ch03-05-control-flow.md +++ b/src/ch03-05-control-flow.md @@ -191,7 +191,7 @@ like this: When we run this program, we’ll see `again!` printed over and over continuously until we stop the program manually. Most terminals support the keyboard shortcut -ctrl-c to interrupt a program that is stuck in a continual +ctrl-c to interrupt a program that is stuck in a continual loop. Give it a try: provides functionality that generates random numbers. Most of the time when Rustaceans say “crate”, they mean library crate, and they -use “crate” interchangeably with the general programming concept of a “library". +use “crate” interchangeably with the general programming concept of a “library”. The *crate root* is a source file that the Rust compiler starts from and makes up the root module of your crate (we’ll explain modules in depth in the From 75bc5551057d73c77034f23f0bce1dc444c3ef17 Mon Sep 17 00:00:00 2001 From: "Carol (Nichols || Goulding)" Date: Tue, 13 Aug 2024 13:19:16 -0400 Subject: [PATCH 07/14] Updates to ch7 snapshot, not to send to nostarch --- nostarch/chapter07.md | 131 +++++++++++++++++++++--------------------- 1 file changed, 64 insertions(+), 67 deletions(-) diff --git a/nostarch/chapter07.md b/nostarch/chapter07.md index 9fef53de7..a9a48eff0 100644 --- a/nostarch/chapter07.md +++ b/nostarch/chapter07.md @@ -75,7 +75,7 @@ executable. Instead, they define functionality intended to be shared with multiple projects. For example, the `rand` crate we used in Chapter 2 provides functionality that generates random numbers. Most of the time when Rustaceans say “crate”, they mean library crate, and they -use “crate” interchangeably with the general programming concept of a “library". +use “crate” interchangeably with the general programming concept of a “library”. The *crate root* is a source file that the Rust compiler starts from and makes up the root module of your crate (we’ll explain modules in depth in the @@ -139,37 +139,35 @@ in the compiler, and how most developers organize their code. We’ll be going through examples of each of these rules throughout this chapter, but this is a great place to refer to as a reminder of how modules work. -- **Start from the crate root**: When compiling a crate, the compiler first +* **Start from the crate root**: When compiling a crate, the compiler first looks in the crate root file (usually *src/lib.rs* for a library crate or *src/main.rs* for a binary crate) for code to compile. -- **Declaring modules**: In the crate root file, you can declare new modules; -say you declare a “garden” module with `mod garden;`. The compiler will look -for the module’s code in these places: - - Inline, within curly brackets that replace the semicolon following `mod - garden` - - In the file *src/garden.rs* - - In the file *src/garden/mod.rs* -- **Declaring submodules**: In any file other than the crate root, you can +* **Declaring modules**: In the crate root file, you can declare new modules; + say you declare a “garden” module with `mod garden;`. The compiler will look + for the module’s code in these places: + * Inline, within curly brackets that replace the semicolon following `mod garden` + * In the file *src/garden.rs* + * In the file *src/garden/mod.rs* +* **Declaring submodules**: In any file other than the crate root, you can declare submodules. For example, you might declare `mod vegetables;` in *src/garden.rs*. The compiler will look for the submodule’s code within the directory named for the parent module in these places: - - Inline, directly following `mod vegetables`, within curly brackets instead + * Inline, directly following `mod vegetables`, within curly brackets instead of the semicolon - - In the file *src/garden/vegetables.rs* - - In the file *src/garden/vegetables/mod.rs* -- **Paths to code in modules**: Once a module is part of your crate, you can + * In the file *src/garden/vegetables.rs* + * In the file *src/garden/vegetables/mod.rs* +* **Paths to code in modules**: Once a module is part of your crate, you can refer to code in that module from anywhere else in that same crate, as long as the privacy rules allow, using the path to the code. For example, an `Asparagus` type in the garden vegetables module would be found at `crate::garden::vegetables::Asparagus`. -- **Private vs. public**: Code within a module is private from its parent +* **Private vs. public**: Code within a module is private from its parent modules by default. To make a module public, declare it with `pub mod` instead of `mod`. To make items within a public module public as well, use `pub` before their declarations. -- **The `use` keyword**: Within a scope, the `use` keyword creates shortcuts to +* **The `use` keyword**: Within a scope, the `use` keyword creates shortcuts to items to reduce repetition of long paths. In any scope that can refer to - `crate::garden::vegetables::Asparagus`, you can create a shortcut with `use - crate::garden::vegetables::Asparagus;` and from then on you only need to + `crate::garden::vegetables::Asparagus`, you can create a shortcut with `use crate::garden::vegetables::Asparagus;` and from then on you only need to write `Asparagus` to make use of that type in the scope. Here, we create a binary crate named `backyard` that illustrates these rules. @@ -243,8 +241,7 @@ chefs and cooks work in the kitchen, dishwashers clean up, and managers do administrative work. To structure our crate in this way, we can organize its functions into nested -modules. Create a new library named `restaurant` by running `cargo new -restaurant --lib`. Then enter the code in Listing 7-1 into *src/lib.rs* to +modules. Create a new library named `restaurant` by running `cargo new restaurant --lib`. Then enter the code in Listing 7-1 into *src/lib.rs* to define some modules and function signatures; this code is the front of house section. @@ -594,26 +591,27 @@ changes to your public API to make it easier for people to depend on your crate. These considerations are out of the scope of this book; if you’re interested in this topic, see The Rust API Guidelines at *https://rust-lang.github.io/api-guidelines/*. -> #### Best Practices for Packages with a Binary and a Library -> -> We mentioned that a package can contain both a *src/main.rs* binary crate -> root as well as a *src/lib.rs* library crate root, and both crates will have -> the package name by default. Typically, packages with this pattern of -> containing both a library and a binary crate will have just enough code in the -> binary crate to start an executable that calls code within the library crate. -> This lets other projects benefit from most of the functionality that the -> package provides because the library crate’s code can be shared. -> -> The module tree should be defined in *src/lib.rs*. Then, any public items can -> be used in the binary crate by starting paths with the name of the package. -> The binary crate becomes a user of the library crate just like a completely -> external crate would use the library crate: it can only use the public API. -> This helps you design a good API; not only are you the author, you’re also a -> client! -> -> In Chapter 12, we’ll demonstrate this organizational -> practice with a command-line program that will contain both a binary crate -> and a library crate. + > + > #### Best Practices for Packages with a Binary and a Library + > + > We mentioned that a package can contain both a *src/main.rs* binary crate + > root as well as a *src/lib.rs* library crate root, and both crates will have + > the package name by default. Typically, packages with this pattern of + > containing both a library and a binary crate will have just enough code in the + > binary crate to start an executable that calls code within the library crate. + > This lets other projects benefit from most of the functionality that the + > package provides because the library crate’s code can be shared. + > + > The module tree should be defined in *src/lib.rs*. Then, any public items can + > be used in the binary crate by starting paths with the name of the package. + > The binary crate becomes a user of the library crate just like a completely + > external crate would use the library crate: it can only use the public API. + > This helps you design a good API; not only are you the author, you’re also a + > client! + > + > In Chapter 12, we’ll demonstrate this organizational + > practice with a command-line program that will contain both a binary crate + > and a library crate. ### Starting Relative Paths with `super` @@ -856,8 +854,7 @@ the shortcut in the parent module with `super::hosting` within the child ### Creating Idiomatic `use` Paths -In Listing 7-11, you might have wondered why we specified `use -crate::front_of_house::hosting` and then called `hosting::add_to_waitlist` in +In Listing 7-11, you might have wondered why we specified `use crate::front_of_house::hosting` and then called `hosting::add_to_waitlist` in `eat_at_restaurant`, rather than specifying the `use` path all the way out to the `add_to_waitlist` function to achieve the same result, as in Listing 7-13. @@ -1002,8 +999,7 @@ from a new scope with `pub use` Before this change, external code would have to call the `add_to_waitlist` function by using the path `restaurant::front_of_house::hosting::add_to_waitlist()`, which also would have -required the `front_of_house` module to be marked as `pub`. Now that this `pub -use` has re-exported the `hosting` module from the root module, external code +required the `front_of_house` module to be marked as `pub`. Now that this `pub use` has re-exported the `hosting` module from the root module, external code can use the path `restaurant::hosting::add_to_waitlist()` instead. Re-exporting is useful when the internal structure of your code is different @@ -1246,29 +1242,30 @@ root, and not declared as a child of the `front_of_house` module. The compiler’s rules for which files to check for which modules’ code mean the directories and files more closely match the module tree. -> ### Alternate File Paths -> -> So far we’ve covered the most idiomatic file paths the Rust compiler uses, -> but Rust also supports an older style of file path. For a module named -> `front_of_house` declared in the crate root, the compiler will look for the -> module’s code in: -> -> * *src/front_of_house.rs* (what we covered) -> * *src/front_of_house/mod.rs* (older style, still supported path) -> -> For a module named `hosting` that is a submodule of `front_of_house`, the -> compiler will look for the module’s code in: -> -> * *src/front_of_house/hosting.rs* (what we covered) -> * *src/front_of_house/hosting/mod.rs* (older style, still supported path) -> -> If you use both styles for the same module, you’ll get a compiler error. -> Using a mix of both styles for different modules in the same project is -> allowed, but might be confusing for people navigating your project. -> -> The main downside to the style that uses files named *mod.rs* is that your -> project can end up with many files named *mod.rs*, which can get confusing -> when you have them open in your editor at the same time. + > + > ### Alternate File Paths + > + > So far we’ve covered the most idiomatic file paths the Rust compiler uses, + > but Rust also supports an older style of file path. For a module named + > `front_of_house` declared in the crate root, the compiler will look for the + > module’s code in: + > + > * *src/front_of_house.rs* (what we covered) + > * *src/front_of_house/mod.rs* (older style, still supported path) + > + > For a module named `hosting` that is a submodule of `front_of_house`, the + > compiler will look for the module’s code in: + > + > * *src/front_of_house/hosting.rs* (what we covered) + > * *src/front_of_house/hosting/mod.rs* (older style, still supported path) + > + > If you use both styles for the same module, you’ll get a compiler error. + > Using a mix of both styles for different modules in the same project is + > allowed, but might be confusing for people navigating your project. + > + > The main downside to the style that uses files named *mod.rs* is that your + > project can end up with many files named *mod.rs*, which can get confusing + > when you have them open in your editor at the same time. We’ve moved each module’s code to a separate file, and the module tree remains the same. The function calls in `eat_at_restaurant` will work without any From 48a3c173c12462eac754a30648397376606f37ba Mon Sep 17 00:00:00 2001 From: "Carol (Nichols || Goulding)" Date: Tue, 13 Aug 2024 13:19:29 -0400 Subject: [PATCH 08/14] Upstream changes to ch7 to consider sending to nostarch --- nostarch/chapter07.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/nostarch/chapter07.md b/nostarch/chapter07.md index a9a48eff0..0a7a40793 100644 --- a/nostarch/chapter07.md +++ b/nostarch/chapter07.md @@ -196,7 +196,7 @@ pub mod garden; fn main() { let plant = Asparagus {}; - println!("I'm growing {:?}!", plant); + println!("I'm growing {plant:?}!"); } ``` @@ -563,7 +563,7 @@ and `fn add_to_waitlist` lets us call the function from `eat_at_restaurant` Now the code will compile! To see why adding the `pub` keyword lets us use -these paths in `add_to_waitlist` with respect to the privacy rules, let’s look +these paths in `eat_at_restaurant` with respect to the privacy rules, let’s look at the absolute and the relative paths. In the absolute path, we start with `crate`, the root of our crate’s module From 8880eacd339876c9a53d606720176bb02a4e5b3f Mon Sep 17 00:00:00 2001 From: "Carol (Nichols || Goulding)" Date: Tue, 13 Aug 2024 13:25:01 -0400 Subject: [PATCH 09/14] Backported edits of ch12 from print to src --- nostarch/chapter12.md | 2 +- src/ch12-00-an-io-project.md | 16 +++-- ...h12-01-accepting-command-line-arguments.md | 16 ++--- src/ch12-02-reading-a-file.md | 12 ++-- ...improving-error-handling-and-modularity.md | 59 +++++++++---------- ...2-04-testing-the-librarys-functionality.md | 54 ++++++++--------- ...2-05-working-with-environment-variables.md | 42 ++++++------- ...-06-writing-to-stderr-instead-of-stdout.md | 9 +-- 8 files changed, 104 insertions(+), 106 deletions(-) diff --git a/nostarch/chapter12.md b/nostarch/chapter12.md index 86e986173..aa34be3c2 100644 --- a/nostarch/chapter12.md +++ b/nostarch/chapter12.md @@ -1022,7 +1022,7 @@ principles, we’ll add just enough code to get the test to compile and run by adding a definition of the `search` function that always returns an empty vector, as shown in Listing 12-16. Then the test should compile and fail because an empty vector doesn’t match a vector containing the line `"safe, -fast, productive."`. +fast, productive."` Filename: src/lib.rs diff --git a/src/ch12-00-an-io-project.md b/src/ch12-00-an-io-project.md index bae99c75f..79e84c943 100644 --- a/src/ch12-00-an-io-project.md +++ b/src/ch12-00-an-io-project.md @@ -18,8 +18,8 @@ Along the way, we’ll show how to make our command line tool use the terminal features that many other command line tools use. We’ll read the value of an environment variable to allow the user to configure the behavior of our tool. We’ll also print error messages to the standard error console stream (`stderr`) -instead of standard output (`stdout`), so, for example, the user can redirect -successful output to a file while still seeing error messages onscreen. +instead of standard output (`stdout`) so that, for example, the user can +redirect successful output to a file while still seeing error messages onscreen. One Rust community member, Andrew Gallant, has already created a fully featured, very fast version of `grep`, called `ripgrep`. By comparison, our @@ -29,17 +29,15 @@ background knowledge you need to understand a real-world project such as Our `grep` project will combine a number of concepts you’ve learned so far: -* Organizing code (using what you learned about modules in [Chapter 7][ch7]) -* Using vectors and strings (collections, [Chapter 8][ch8]) +* Organizing code ([Chapter 7][ch7]) +* Using vectors and strings ([Chapter 8][ch8]) * Handling errors ([Chapter 9][ch9]) -* Using traits and lifetimes where appropriate ([Chapter 10][ch10]) +* Using traits and lifetimes where appropriate ([Chapter 10][ch10]) * Writing tests ([Chapter 11][ch11]) We’ll also briefly introduce closures, iterators, and trait objects, which -Chapters [13][ch13] and [17][ch17] will cover in -detail. +[Chapter 13][ch13] and [Chapter 17][ch17] will +cover in detail. [ch7]: ch07-00-managing-growing-projects-with-packages-crates-and-modules.html [ch8]: ch08-00-common-collections.html diff --git a/src/ch12-01-accepting-command-line-arguments.md b/src/ch12-01-accepting-command-line-arguments.md index 9dc28209b..34e450424 100644 --- a/src/ch12-01-accepting-command-line-arguments.md +++ b/src/ch12-01-accepting-command-line-arguments.md @@ -37,7 +37,7 @@ to turn it into a collection, such as a vector, that contains all the elements the iterator produces. The code in Listing 12-1 allows your `minigrep` program to read any command -line arguments passed to it and then collect the values into a vector. +line arguments passed to it, and then collect the values into a vector. @@ -47,7 +47,7 @@ line arguments passed to it and then collect the values into a vector. -First, we bring the `std::env` module into scope with a `use` statement so we +First we bring the `std::env` module into scope with a `use` statement so we can use its `args` function. Notice that the `std::env::args` function is nested in two levels of modules. As we discussed in [Chapter 7][ch7-idiomatic-use], in cases where the desired function is @@ -63,14 +63,14 @@ mistaken for a function that’s defined in the current module. > Unicode. If your program needs to accept arguments containing invalid > Unicode, use `std::env::args_os` instead. That function returns an iterator > that produces `OsString` values instead of `String` values. We’ve chosen to -> use `std::env::args` here for simplicity, because `OsString` values differ -> per platform and are more complex to work with than `String` values. +> use `std::env::args` here for simplicity because `OsString` values differ per +> platform and are more complex to work with than `String` values. On the first line of `main`, we call `env::args`, and we immediately use `collect` to turn the iterator into a vector containing all the values produced by the iterator. We can use the `collect` function to create many kinds of collections, so we explicitly annotate the type of `args` to specify that we -want a vector of strings. Although we very rarely need to annotate types in +want a vector of strings. Although you very rarely need to annotate types in Rust, `collect` is one function you do often need to annotate because Rust isn’t able to infer the kind of collection you want. @@ -89,8 +89,8 @@ Notice that the first value in the vector is `"target/debug/minigrep"`, which is the name of our binary. This matches the behavior of the arguments list in C, letting programs use the name by which they were invoked in their execution. It’s often convenient to have access to the program name in case you want to -print it in messages or change behavior of the program based on what command -line alias was used to invoke the program. But for the purposes of this +print it in messages or change the behavior of the program based on what +command line alias was used to invoke the program. But for the purposes of this chapter, we’ll ignore it and save only the two arguments we need. ### Saving the Argument Values in Variables @@ -109,7 +109,7 @@ we can use the values throughout the rest of the program. We do that in Listing As we saw when we printed the vector, the program’s name takes up the first -value in the vector at `args[0]`, so we’re starting arguments at index `1`. The +value in the vector at `args[0]`, so we’re starting arguments at index 1. The first argument `minigrep` takes is the string we’re searching for, so we put a reference to the first argument in the variable `query`. The second argument will be the file path, so we put a reference to the second argument in the diff --git a/src/ch12-02-reading-a-file.md b/src/ch12-02-reading-a-file.md index 910850b06..e45dded65 100644 --- a/src/ch12-02-reading-a-file.md +++ b/src/ch12-02-reading-a-file.md @@ -1,13 +1,13 @@ ## Reading a File Now we’ll add functionality to read the file specified in the `file_path` -argument. First, we need a sample file to test it with: we’ll use a file with a +argument. First we need a sample file to test it with: we’ll use a file with a small amount of text over multiple lines with some repeated words. Listing 12-3 has an Emily Dickinson poem that will work well! Create a file called *poem.txt* at the root level of your project, and enter the poem “I’m Nobody! Who are you?” -+ ```text {{#include ../listings/ch12-an-io-project/listing-12-03/poem.txt}} @@ -26,7 +26,7 @@ shown in Listing 12-4. -First, we bring in a relevant part of the standard library with a `use` +First we bring in a relevant part of the standard library with a `use` statement: we need `std::fs` to handle files. In `main`, the new statement `fs::read_to_string` takes the `file_path`, opens @@ -50,6 +50,6 @@ responsibilities: generally, functions are clearer and easier to maintain if each function is responsible for only one idea. The other problem is that we’re not handling errors as well as we could. The program is still small, so these flaws aren’t a big problem, but as the program grows, it will be harder to fix -them cleanly. It’s good practice to begin refactoring early on when developing -a program, because it’s much easier to refactor smaller amounts of code. We’ll -do that next. +them cleanly. It’s a good practice to begin refactoring early on when +developing a program because it’s much easier to refactor smaller amounts of +code. We’ll do that next. diff --git a/src/ch12-03-improving-error-handling-and-modularity.md b/src/ch12-03-improving-error-handling-and-modularity.md index 0de3ec2c2..2e76e82d9 100644 --- a/src/ch12-03-improving-error-handling-and-modularity.md +++ b/src/ch12-03-improving-error-handling-and-modularity.md @@ -41,8 +41,8 @@ community has developed guidelines for splitting the separate concerns of a binary program when `main` starts getting large. This process has the following steps: -* Split your program into a *main.rs* and a *lib.rs* and move your program’s - logic to *lib.rs*. +* Split your program into a *main.rs* file and a *lib.rs* file and move your + program’s logic to *lib.rs*. * As long as your command line parsing logic is small, it can remain in *main.rs*. * When the command line parsing logic starts getting complicated, extract it @@ -57,7 +57,7 @@ should be limited to the following: * Handling the error if `run` returns an error This pattern is about separating concerns: *main.rs* handles running the -program, and *lib.rs* handles all the logic of the task at hand. Because you +program and *lib.rs* handles all the logic of the task at hand. Because you can’t test the `main` function directly, this structure lets you test all of your program’s logic by moving it into functions in *lib.rs*. The code that remains in *main.rs* will be small enough to verify its correctness by reading @@ -163,7 +163,7 @@ named for their purpose. So far, we’ve extracted the logic responsible for parsing the command line arguments from `main` and placed it in the `parse_config` function. Doing so -helped us to see that the `query` and `file_path` values were related and that +helped us see that the `query` and `file_path` values were related, and that relationship should be conveyed in our code. We then added a `Config` struct to name the related purpose of `query` and `file_path` and to be able to return the values’ names as struct field names from the `parse_config` function. @@ -208,8 +208,8 @@ they should do instead. Let’s fix that now. #### Improving the Error Message In Listing 12-8, we add a check in the `new` function that will verify that the -slice is long enough before accessing index 1 and 2. If the slice isn’t long -enough, the program panics and displays a better error message. +slice is long enough before accessing index 1 and index 2. If the slice isn’t +long enough, the program panics and displays a better error message. @@ -222,10 +222,10 @@ enough, the program panics and displays a better error message. This code is similar to [the `Guess::new` function we wrote in Listing 9-13][ch9-custom-types], where we called `panic!` when the `value` argument was out of the range of valid values. Instead of checking for -a range of values here, we’re checking that the length of `args` is at least 3 -and the rest of the function can operate under the assumption that this +a range of values here, we’re checking that the length of `args` is at least +`3` and the rest of the function can operate under the assumption that this condition has been met. If `args` has fewer than three items, this condition -will be true, and we call the `panic!` macro to end the program immediately. +will be `true`, and we call the `panic!` macro to end the program immediately. With these extra few lines of code in `new`, let’s run the program without any arguments again to see what the error looks like now: @@ -235,8 +235,8 @@ arguments again to see what the error looks like now: ``` This output is better: we now have a reasonable error message. However, we also -have extraneous information we don’t want to give to our users. Perhaps using -the technique we used in Listing 9-13 isn’t the best to use here: a call to +have extraneous information we don’t want to give to our users. Perhaps the +technique we used in Listing 9-13 isn’t the best one to use here: a call to `panic!` is more appropriate for a programming problem than a usage problem, [as discussed in Chapter 9][ch9-error-guidelines]. Instead, we’ll use the other technique you learned about in Chapter 9—[returning a @@ -306,15 +306,15 @@ In this listing, we’ve used a method we haven’t covered in detail yet: `unwrap_or_else`, which is defined on `Result` by the standard library. Using `unwrap_or_else` allows us to define some custom, non-`panic!` error handling. If the `Result` is an `Ok` value, this method’s behavior is similar -to `unwrap`: it returns the inner value `Ok` is wrapping. However, if the value -is an `Err` value, this method calls the code in the *closure*, which is an -anonymous function we define and pass as an argument to `unwrap_or_else`. We’ll -cover closures in more detail in [Chapter 13][ch13]. For now, -you just need to know that `unwrap_or_else` will pass the inner value of the -`Err`, which in this case is the static string `"not enough arguments"` that we -added in Listing 12-9, to our closure in the argument `err` that appears -between the vertical pipes. The code in the closure can then use the `err` -value when it runs. +to `unwrap`: it returns the inner value that `Ok` is wrapping. However, if the +value is an `Err` value, this method calls the code in the *closure*, which is +an anonymous function we define and pass as an argument to `unwrap_or_else`. +We’ll cover closures in more detail in [Chapter 13][ch13]. For +now, you just need to know that `unwrap_or_else` will pass the inner value of +the `Err`, which in this case is the static string `"not enough arguments"` +that we added in Listing 12-9, to our closure in the argument `err` that +appears between the vertical pipes. The code in the closure can then use the +`err` value when it runs. We’ve added a new `use` line to bring `process` from the standard library into scope. The code in the closure that will be run in the error case is only two @@ -386,7 +386,7 @@ know that `Box` means the function will return a type that implements the `Error` trait, but we don’t have to specify what particular type the return value will be. This gives us flexibility to return error values that may be of different types in different error cases. The `dyn` keyword is short -for “dynamic.” +for *dynamic*. Second, we’ve removed the call to `expect` in favor of the `?` operator, as we talked about in [Chapter 9][ch9-question-mark]. Rather than @@ -423,11 +423,11 @@ with `Config::build` in Listing 12-10, but with a slight difference: ``` We use `if let` rather than `unwrap_or_else` to check whether `run` returns an -`Err` value and call `process::exit(1)` if it does. The `run` function doesn’t -return a value that we want to `unwrap` in the same way that `Config::build` -returns the `Config` instance. Because `run` returns `()` in the success case, -we only care about detecting an error, so we don’t need `unwrap_or_else` to -return the unwrapped value, which would only be `()`. +`Err` value and to call `process::exit(1)` if it does. The `run` function +doesn’t return a value that we want to `unwrap` in the same way that +`Config::build` returns the `Config` instance. Because `run` returns `()` in +the success case, we only care about detecting an error, so we don’t need +`unwrap_or_else` to return the unwrapped value, which would only be `()`. The bodies of the `if let` and the `unwrap_or_else` functions are the same in both cases: we print the error and exit. @@ -435,10 +435,10 @@ both cases: we print the error and exit. ### Splitting Code into a Library Crate Our `minigrep` project is looking good so far! Now we’ll split the -*src/main.rs* file and put some code into the *src/lib.rs* file. That way we +*src/main.rs* file and put some code into the *src/lib.rs* file. That way, we can test the code and have a *src/main.rs* file with fewer responsibilities. -Let’s move all the code that isn’t the `main` function from *src/main.rs* to +Let’s move all the code that isn’t in the `main` function from *src/main.rs* to *src/lib.rs*: * The `run` function definition @@ -476,8 +476,7 @@ binary crate in *src/main.rs*, as shown in Listing 12-14. We add a `use minigrep::Config` line to bring the `Config` type from the library crate into the binary crate’s scope, and we prefix the `run` function with our crate name. Now all the functionality should be connected and should -work. Run the program with `cargo run` and make sure everything works -correctly. +work. Run the program with `cargo run` and make sure everything works correctly. Whew! That was a lot of work, but we’ve set ourselves up for success in the future. Now it’s much easier to handle errors, and we’ve made the code more diff --git a/src/ch12-04-testing-the-librarys-functionality.md b/src/ch12-04-testing-the-librarys-functionality.md index c4a435bc0..7034783d7 100644 --- a/src/ch12-04-testing-the-librarys-functionality.md +++ b/src/ch12-04-testing-the-librarys-functionality.md @@ -6,21 +6,21 @@ for the core functionality of our code. We can call functions directly with various arguments and check return values without having to call our binary from the command line. -In this section, we’ll add the searching logic to the `minigrep` program -using the test-driven development (TDD) process with the following steps: +In this section, we’ll add the searching logic to the `minigrep` program using +the test-driven development (TDD) process with the following steps: 1. Write a test that fails and run it to make sure it fails for the reason you expect. 2. Write or modify just enough code to make the new test pass. -3. Refactor the code you just added or changed and make sure the tests - continue to pass. +3. Refactor the code you just added or changed and make sure the tests continue + to pass. 4. Repeat from step 1! Though it’s just one of many ways to write software, TDD can help drive code design. Writing the test before you write the code that makes the test pass helps to maintain high test coverage throughout the process. -We’ll test drive the implementation of the functionality that will actually do +We’ll test-drive the implementation of the functionality that will actually do the searching for the query string in the file contents and produce a list of lines that match the query. We’ll add this functionality in a function called `search`. @@ -29,11 +29,11 @@ lines that match the query. We’ll add this functionality in a function called Because we don’t need them anymore, let’s remove the `println!` statements from *src/lib.rs* and *src/main.rs* that we used to check the program’s behavior. -Then, in *src/lib.rs*, add a `tests` module with a test function, as we did in -[Chapter 11][ch11-anatomy]. The test function specifies the -behavior we want the `search` function to have: it will take a query and the -text to search, and it will return only the lines from the text that contain -the query. Listing 12-15 shows this test, which won’t compile yet. +Then, in *src/lib.rs*, we’ll add a `tests` module with a test function, as we +did in [Chapter 11][ch11-anatomy]. The test function specifies +the behavior we want the `search` function to have: it will take a query and +the text to search, and it will return only the lines from the text that +contain the query. Listing 12-15 shows this test, which won’t compile yet. @@ -44,7 +44,7 @@ the query. Listing 12-15 shows this test, which won’t compile yet. This test searches for the string `"duct"`. The text we’re searching is three -lines, only one of which contains `"duct"` (Note that the backslash after the +lines, only one of which contains `"duct"` (note that the backslash after the opening double quote tells Rust not to put a newline character at the beginning of the contents of this string literal). We assert that the value returned from the `search` function contains only the line we expect. @@ -95,9 +95,9 @@ syntax. Other programming languages don’t require you to connect arguments to return values in the signature, but this practice will get easier over time. You might -want to compare this example with the [“Validating References with -Lifetimes”][validating-references-with-lifetimes] section in -Chapter 10. +want to compare this example with the examples in the [“Validating References +with Lifetimes”][validating-references-with-lifetimes] section +in Chapter 10. Now let’s run the test: @@ -112,19 +112,19 @@ Great, the test fails, exactly as we expected. Let’s get the test to pass! Currently, our test is failing because we always return an empty vector. To fix that and implement `search`, our program needs to follow these steps: -* Iterate through each line of the contents. -* Check whether the line contains our query string. -* If it does, add it to the list of values we’re returning. -* If it doesn’t, do nothing. -* Return the list of results that match. +1. Iterate through each line of the contents. +2. Check whether the line contains our query string. +3. If it does, add it to the list of values we’re returning. +4. If it doesn’t, do nothing. +5. Return the list of results that match. Let’s work through each step, starting with iterating through lines. #### Iterating Through Lines with the `lines` Method Rust has a helpful method to handle line-by-line iteration of strings, -conveniently named `lines`, that works as shown in Listing 12-17. Note this -won’t compile yet. +conveniently named `lines`, that works as shown in Listing 12-17. Note that +this won’t compile yet. @@ -144,7 +144,7 @@ of using an iterator in [Listing 3-5][ch3-iter], where we used a Next, we’ll check whether the current line contains our query string. Fortunately, strings have a helpful method named `contains` that does this for us! Add a call to the `contains` method in the `search` function, as shown in -Listing 12-18. Note this still won’t compile yet. +Listing 12-18. Note that this still won’t compile yet. @@ -154,8 +154,8 @@ Listing 12-18. Note this still won’t compile yet. -At the moment, we’re building up functionality. To get it to compile, we need -to return a value from the body as we indicated we would in the function +At the moment, we’re building up functionality. To get the code to compile, we +need to return a value from the body as we indicated we would in the function signature. #### Storing Matching Lines @@ -205,20 +205,20 @@ will print each line returned from `search`: We’re still using a `for` loop to return each line from `search` and print it. Now the entire program should work! Let’s try it out, first with a word that -should return exactly one line from the Emily Dickinson poem, “frog”: +should return exactly one line from the Emily Dickinson poem: *frog*. ```console {{#include ../listings/ch12-an-io-project/no-listing-02-using-search-in-run/output.txt}} ``` -Cool! Now let’s try a word that will match multiple lines, like “body”: +Cool! Now let’s try a word that will match multiple lines, like *body*: ```console {{#include ../listings/ch12-an-io-project/output-only-03-multiple-matches/output.txt}} ``` And finally, let’s make sure that we don’t get any lines when we search for a -word that isn’t anywhere in the poem, such as “monomorphization”: +word that isn’t anywhere in the poem, such as *monomorphization*: ```console {{#include ../listings/ch12-an-io-project/output-only-04-no-matches/output.txt}} diff --git a/src/ch12-05-working-with-environment-variables.md b/src/ch12-05-working-with-environment-variables.md index f050b5b47..bea2a3f7d 100644 --- a/src/ch12-05-working-with-environment-variables.md +++ b/src/ch12-05-working-with-environment-variables.md @@ -25,7 +25,7 @@ tests, as shown in Listing 12-20. Note that we’ve edited the old test’s `contents` too. We’ve added a new line -with the text `"Duct tape."` using a capital D that shouldn’t match the query +with the text `"Duct tape."` using a capital *D* that shouldn’t match the query `"duct"` when we’re searching in a case-sensitive manner. Changing the old test in this way helps ensure that we don’t accidentally break the case-sensitive search functionality that we’ve already implemented. This test should pass now @@ -33,9 +33,9 @@ and should continue to pass as we work on the case-insensitive search. The new test for the case-*insensitive* search uses `"rUsT"` as its query. In the `search_case_insensitive` function we’re about to add, the query `"rUsT"` -should match the line containing `"Rust:"` with a capital R and match the line -`"Trust me."` even though both have different casing from the query. This is -our failing test, and it will fail to compile because we haven’t yet defined +should match the line containing `"Rust:"` with a capital *R* and match the +line `"Trust me."` even though both have different casing from the query. This +is our failing test, and it will fail to compile because we haven’t yet defined the `search_case_insensitive` function. Feel free to add a skeleton implementation that always returns an empty vector, similar to the way we did for the `search` function in Listing 12-16 to see the test compile and fail. @@ -44,7 +44,7 @@ for the `search` function in Listing 12-16 to see the test compile and fail. The `search_case_insensitive` function, shown in Listing 12-21, will be almost the same as the `search` function. The only difference is that we’ll lowercase -the `query` and each `line` so whatever the case of the input arguments, +the `query` and each `line` so that whatever the case of the input arguments, they’ll be the same case when we check whether the line contains the query. @@ -55,8 +55,8 @@ they’ll be the same case when we check whether the line contains the query. -First, we lowercase the `query` string and store it in a shadowed variable with -the same name. Calling `to_lowercase` on the query is necessary so no +First we lowercase the `query` string and store it in a shadowed variable with +the same name. Calling `to_lowercase` on the query is necessary so that no matter whether the user’s query is `"rust"`, `"RUST"`, `"Rust"`, or `"rUsT"`, we’ll treat the query as if it were `"rust"` and be insensitive to the case. While `to_lowercase` will handle basic Unicode, it won’t be 100% accurate. If @@ -64,7 +64,7 @@ we were writing a real application, we’d want to do a bit more work here, but this section is about environment variables, not Unicode, so we’ll leave it at that here. -Note that `query` is now a `String` rather than a string slice, because calling +Note that `query` is now a `String` rather than a string slice because calling `to_lowercase` creates new data rather than referencing existing data. Say the query is `"rUsT"`, as an example: that string slice doesn’t contain a lowercase `u` or `t` for us to use, so we have to allocate a new `String` containing @@ -83,10 +83,10 @@ Let’s see if this implementation passes the tests: ``` Great! They passed. Now, let’s call the new `search_case_insensitive` function -from the `run` function. First, we’ll add a configuration option to the -`Config` struct to switch between case-sensitive and case-insensitive search. -Adding this field will cause compiler errors because we aren’t initializing -this field anywhere yet: +from the `run` function. First we’ll add a configuration option to the `Config` +struct to switch between case-sensitive and case-insensitive search. Adding +this field will cause compiler errors because we aren’t initializing this field +anywhere yet: Filename: src/lib.rs @@ -110,7 +110,7 @@ function, as shown in Listing 12-22. This still won’t compile yet. Finally, we need to check for the environment variable. The functions for working with environment variables are in the `env` module in the standard library, so we bring that module into scope at the top of *src/lib.rs*. Then -we’ll use the `var` function from the `env` module to check if any value +we’ll use the `var` function from the `env` module to check to see if any value has been set for an environment variable named `IGNORE_CASE`, as shown in Listing 12-23. @@ -122,7 +122,7 @@ Listing 12-23. -Here, we create a new variable `ignore_case`. To set its value, we call the +Here, we create a new variable, `ignore_case`. To set its value, we call the `env::var` function and pass it the name of the `IGNORE_CASE` environment variable. The `env::var` function returns a `Result` that will be the successful `Ok` variant that contains the value of the environment variable if @@ -132,7 +132,7 @@ if the environment variable is not set. We’re using the `is_ok` method on the `Result` to check whether the environment variable is set, which means the program should do a case-insensitive search. If the `IGNORE_CASE` environment variable isn’t set to anything, `is_ok` will -return false and the program will perform a case-sensitive search. We don’t +return `false` and the program will perform a case-sensitive search. We don’t care about the *value* of the environment variable, just whether it’s set or unset, so we’re checking `is_ok` rather than using `unwrap`, `expect`, or any of the other methods we’ve seen on `Result`. @@ -141,9 +141,9 @@ We pass the value in the `ignore_case` variable to the `Config` instance so the `run` function can read that value and decide whether to call `search_case_insensitive` or `search`, as we implemented in Listing 12-22. -Let’s give it a try! First, we’ll run our program without the environment +Let’s give it a try! First we’ll run our program without the environment variable set and with the query `to`, which should match any line that contains -the word “to” in all lowercase: +the word *to* in all lowercase: ```console {{#include ../listings/ch12-an-io-project/listing-12-23/output.txt}} @@ -163,14 +163,14 @@ run the program as separate commands: PS> $Env:IGNORE_CASE=1; cargo run -- to poem.txt ``` -This will make `IGNORE_CASE` persist for the remainder of your shell -session. It can be unset with the `Remove-Item` cmdlet: +This will make `IGNORE_CASE` persist for the remainder of your shell session. +It can be unset with the `Remove-Item` cmdlet: ```console PS> Remove-Item Env:IGNORE_CASE ``` -We should get lines that contain “to” that might have uppercase letters: +We should get lines that contain *to* that might have uppercase letters: + + + +#### Returning a `Result` Instead of Calling `panic!` We can instead return a `Result` value that will contain a `Config` instance in the successful case and will describe the problem in the error case. We’re also @@ -622,14 +640,14 @@ going to change the function name from `new` to `build` because many programmers expect `new` functions to never fail. When `Config::build` is communicating to `main`, we can use the `Result` type to signal there was a problem. Then we can change `main` to convert an `Err` variant into a more -practical error for our users without the surrounding text about `thread -'main'` and `RUST_BACKTRACE` that a call to `panic!` causes. +practical error for our users without the surrounding text about `thread 'main'` and `RUST_BACKTRACE` that a call to `panic!` causes. Listing 12-9 shows the changes we need to make to the return value of the function we’re now calling `Config::build` and the body of the function needed to return a `Result`. Note that this won’t compile until we update `main` as well, which we’ll do in the next listing. + Filename: src/main.rs ``` @@ -647,7 +665,7 @@ impl Config { } ``` -Listing 12-9: Returning a `Result` from `Config::build` +Listing 12-9: Returning a Result from Config::build Our `build` function returns a `Result` with a `Config` instance in the success case and an `&'static str` in the error case. Our error values will always be @@ -662,7 +680,11 @@ Returning an `Err` value from `Config::build` allows the `main` function to handle the `Result` value returned from the `build` function and exit the process more cleanly in the error case. -#### Calling Config::build and Handling Errors + + + + +#### Calling `Config::build` and Handling Errors To handle the error case and print a user-friendly message, we need to update `main` to handle the `Result` being returned by `Config::build`, as shown in @@ -671,41 +693,42 @@ tool with a nonzero error code away from `panic!` and instead implement it by hand. A nonzero exit status is a convention to signal to the process that called our program that the program exited with an error state. + Filename: src/main.rs ``` -1 use std::process; +use std::process; fn main() { let args: Vec = env::args().collect(); - 2 let config = Config::build(&args).3 unwrap_or_else(|4 err| { - 5 println!("Problem parsing arguments: {err}"); - 6 process::exit(1); + let config = Config::build(&args).unwrap_or_else(|err| { + println!("Problem parsing arguments: {err}"); + process::exit(1); }); - --snip-- + // --snip-- ``` -Listing 12-10: Exiting with an error code if building a `Config` fails +Listing 12-10: Exiting with an error code if building a Config fails In this listing, we’ve used a method we haven’t covered in detail yet: -`unwrap_or_else`, which is defined on `Result` by the standard library -[2]. Using `unwrap_or_else` allows us to define some custom, non-`panic!` error +`unwrap_or_else`, which is defined on `Result` by the standard library. +Using `unwrap_or_else` allows us to define some custom, non-`panic!` error handling. If the `Result` is an `Ok` value, this method’s behavior is similar to `unwrap`: it returns the inner value that `Ok` is wrapping. However, if the value is an `Err` value, this method calls the code in the *closure*, which is -an anonymous function we define and pass as an argument to `unwrap_or_else` -[3]. We’ll cover closures in more detail in Chapter 13. For now, you just need -to know that `unwrap_or_else` will pass the inner value of the `Err`, which in -this case is the static string `"not enough arguments"` that we added in -Listing 12-9, to our closure in the argument `err` that appears between the -vertical pipes [4]. The code in the closure can then use the `err` value when -it runs. +an anonymous function we define and pass as an argument to `unwrap_or_else`. +We’ll cover closures in more detail in Chapter 13. For +now, you just need to know that `unwrap_or_else` will pass the inner value of +the `Err`, which in this case is the static string `"not enough arguments"` +that we added in Listing 12-9, to our closure in the argument `err` that +appears between the vertical pipes. The code in the closure can then use the +`err` value when it runs. We’ve added a new `use` line to bring `process` from the standard library into -scope [1]. The code in the closure that will be run in the error case is only -two lines: we print the `err` value [5] and then call `process::exit` [6]. The +scope. The code in the closure that will be run in the error case is only two +lines: we print the `err` value and then call `process::exit`. The `process::exit` function will stop the program immediately and return the number that was passed as the exit status code. This is similar to the `panic!`-based handling we used in Listing 12-8, but we no longer get all the @@ -721,25 +744,26 @@ Problem parsing arguments: not enough arguments Great! This output is much friendlier for our users. -### Extracting Logic from main +### Extracting Logic from `main` Now that we’ve finished refactoring the configuration parsing, let’s turn to the program’s logic. As we stated in “Separation of Concerns for Binary -Projects” on page XX, we’ll extract a function named `run` that will hold all -the logic currently in the `main` function that isn’t involved with setting up -configuration or handling errors. When we’re done, `main` will be concise and -easy to verify by inspection, and we’ll be able to write tests for all the -other logic. +Projects”, we’ll +extract a function named `run` that will hold all the logic currently in the +`main` function that isn’t involved with setting up configuration or handling +errors. When we’re done, `main` will be concise and easy to verify by +inspection, and we’ll be able to write tests for all the other logic. Listing 12-11 shows the extracted `run` function. For now, we’re just making the small, incremental improvement of extracting the function. We’re still defining the function in *src/main.rs*. + Filename: src/main.rs ``` fn main() { - --snip-- + // --snip-- println!("Searching for {}", config.query); println!("In file {}", config.file_path); @@ -754,17 +778,16 @@ fn run(config: Config) { println!("With text:\n{contents}"); } ---snip-- +// --snip-- ``` -Listing 12-11: Extracting a `run` function containing the rest of the program -logic +Listing 12-11: Extracting a run function containing the rest of the program logic The `run` function now contains all the remaining logic from `main`, starting from reading the file. The `run` function takes the `Config` instance as an argument. -#### Returning Errors from the run Function +#### Returning Errors from the `run` Function With the remaining program logic separated into the `run` function, we can improve the error handling, as we did with `Config::build` in Listing 12-9. @@ -774,42 +797,45 @@ us further consolidate the logic around handling errors into `main` in a user-friendly way. Listing 12-12 shows the changes we need to make to the signature and body of `run`. + Filename: src/main.rs ``` -1 use std::error::Error; +use std::error::Error; ---snip-- +// --snip-- -2 fn run(config: Config) -> Result<(), Box> { - let contents = fs::read_to_string(config.file_path)3 ?; +fn run(config: Config) -> Result<(), Box> { + let contents = fs::read_to_string(config.file_path)?; println!("With text:\n{contents}"); - 4 Ok(()) + Ok(()) } ``` -Listing 12-12: Changing the `run` function to return `Result` +Listing 12-12: Changing the run function to return Result We’ve made three significant changes here. First, we changed the return type of -the `run` function to `Result<(), Box>` [2]. This function -previously returned the unit type, `()`, and we keep that as the value returned -in the `Ok` case. +the `run` function to `Result<(), Box>`. This function previously +returned the unit type, `()`, and we keep that as the value returned in the +`Ok` case. For the error type, we used the *trait object* `Box` (and we’ve -brought `std::error::Error` into scope with a `use` statement at the top [1]). -We’ll cover trait objects in Chapter 17. For now, just know that `Box` means the function will return a type that implements the `Error` -trait, but we don’t have to specify what particular type the return value will -be. This gives us flexibility to return error values that may be of different -types in different error cases. The `dyn` keyword is short for *dynamic*. +brought `std::error::Error` into scope with a `use` statement at the top). +We’ll cover trait objects in Chapter 17. For now, just +know that `Box` means the function will return a type that +implements the `Error` trait, but we don’t have to specify what particular type +the return value will be. This gives us flexibility to return error values that +may be of different types in different error cases. The `dyn` keyword is short +for *dynamic*. -Second, we’ve removed the call to `expect` in favor of the `?` operator [3], as -we talked about in Chapter 9. Rather than `panic!` on an error, `?` will return -the error value from the current function for the caller to handle. +Second, we’ve removed the call to `expect` in favor of the `?` operator, as we +talked about in Chapter 9. Rather than +`panic!` on an error, `?` will return the error value from the current function +for the caller to handle. -Third, the `run` function now returns an `Ok` value in the success case [4]. +Third, the `run` function now returns an `Ok` value in the success case. We’ve declared the `run` function’s success type as `()` in the signature, which means we need to wrap the unit type value in the `Ok` value. This `Ok(())` syntax might look a bit strange at first, but using `()` like this is @@ -819,6 +845,8 @@ only; it doesn’t return a value we need. When you run this code, it will compile but will display a warning: ``` +$ cargo run -- the poem.txt + Compiling minigrep v0.1.0 (file:///projects/minigrep) warning: unused `Result` that must be used --> src/main.rs:19:5 | @@ -828,6 +856,21 @@ warning: unused `Result` that must be used = note: `#[warn(unused_must_use)]` on by default = note: this `Result` may be an `Err` variant, which should be handled + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.71s + Running `target/debug/minigrep the poem.txt` +Searching for the +In file poem.txt +With text: +I'm nobody! Who are you? +Are you nobody, too? +Then there's a pair of us - don't tell! +They'd banish us, you know. + +How dreary to be somebody! +How public, like a frog +To tell your name the livelong day +To an admiring bog! + ``` Rust tells us that our code ignored the `Result` value and the `Result` value @@ -835,7 +878,7 @@ might indicate that an error occurred. But we’re not checking to see whether o not there was an error, and the compiler reminds us that we probably meant to have some error-handling code here! Let’s rectify that problem now. -#### Handling Errors Returned from run in main +#### Handling Errors Returned from `run` in `main` We’ll check for errors and handle them using a technique similar to one we used with `Config::build` in Listing 12-10, but with a slight difference: @@ -844,7 +887,7 @@ Filename: src/main.rs ``` fn main() { - --snip-- + // --snip-- println!("Searching for {}", config.query); println!("In file {}", config.file_path); @@ -884,6 +927,7 @@ The contents of *src/lib.rs* should have the signatures shown in Listing 12-13 (we’ve omitted the bodies of the functions for brevity). Note that this won’t compile until we modify *src/main.rs* in Listing 12-14. + Filename: src/lib.rs ``` @@ -896,19 +940,17 @@ pub struct Config { } impl Config { - pub fn build( - args: &[String], - ) -> Result { - --snip-- + pub fn build(args: &[String]) -> Result { + // --snip-- } } pub fn run(config: Config) -> Result<(), Box> { - --snip-- + // --snip-- } ``` -Listing 12-13: Moving `Config` and `run` into *src/lib.rs* +Listing 12-13: Moving Config and run into src/lib.rs We’ve made liberal use of the `pub` keyword: on `Config`, on its fields and its `build` method, and on the `run` function. We now have a library crate that has @@ -917,6 +959,7 @@ a public API we can test! Now we need to bring the code we moved to *src/lib.rs* into the scope of the binary crate in *src/main.rs*, as shown in Listing 12-14. + Filename: src/main.rs ``` @@ -926,14 +969,14 @@ use std::process; use minigrep::Config; fn main() { - --snip-- + // --snip-- if let Err(e) = minigrep::run(config) { - --snip-- + // --snip-- } } ``` -Listing 12-14: Using the `minigrep` library crate in *src/main.rs* +Listing 12-14: Using the minigrep library crate in src/main.rs We add a `use minigrep::Config` line to bring the `Config` type from the library crate into the binary crate’s scope, and we prefix the `run` function @@ -960,10 +1003,10 @@ In this section, we’ll add the searching logic to the `minigrep` program using the test-driven development (TDD) process with the following steps: 1. Write a test that fails and run it to make sure it fails for the reason you -expect. + expect. 1. Write or modify just enough code to make the new test pass. 1. Refactor the code you just added or changed and make sure the tests continue -to pass. + to pass. 1. Repeat from step 1! Though it’s just one of many ways to write software, TDD can help drive code @@ -980,10 +1023,11 @@ lines that match the query. We’ll add this functionality in a function called Because we don’t need them anymore, let’s remove the `println!` statements from *src/lib.rs* and *src/main.rs* that we used to check the program’s behavior. Then, in *src/lib.rs*, we’ll add a `tests` module with a test function, as we -did in Chapter 11. The test function specifies the behavior we want the -`search` function to have: it will take a query and the text to search, and it -will return only the lines from the text that contain the query. Listing 12-15 -shows this test, which won’t compile yet. +did in Chapter 11. The test function specifies +the behavior we want the `search` function to have: it will take a query and +the text to search, and it will return only the lines from the text that +contain the query. Listing 12-15 shows this test, which won’t compile yet. + Filename: src/lib.rs @@ -1000,15 +1044,12 @@ Rust: safe, fast, productive. Pick three."; - assert_eq!( - vec!["safe, fast, productive."], - search(query, contents) - ); + assert_eq!(vec!["safe, fast, productive."], search(query, contents)); } } ``` -Listing 12-15: Creating a failing test for the `search` function we wish we had +Listing 12-15: Creating a failing test for the search function we wish we had This test searches for the string `"duct"`. The text we’re searching is three lines, only one of which contains `"duct"` (note that the backslash after the @@ -1021,29 +1062,26 @@ even compile: the `search` function doesn’t exist yet! In accordance with TDD principles, we’ll add just enough code to get the test to compile and run by adding a definition of the `search` function that always returns an empty vector, as shown in Listing 12-16. Then the test should compile and fail -because an empty vector doesn’t match a vector containing the line `"safe, -fast, productive."` +because an empty vector doesn’t match a vector containing the line `"safe, fast, productive."` + Filename: src/lib.rs ``` -pub fn search<'a>( - query: &str, - contents: &'a str, -) -> Vec<&'a str> { +pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { vec![] } ``` -Listing 12-16: Defining just enough of the `search` function so our test will -compile +Listing 12-16: Defining just enough of the search function so our test will compile Notice that we need to define an explicit lifetime `'a` in the signature of `search` and use that lifetime with the `contents` argument and the return -value. Recall in Chapter 10 that the lifetime parameters specify which argument -lifetime is connected to the lifetime of the return value. In this case, we -indicate that the returned vector should contain string slices that reference -slices of the argument `contents` (rather than the argument `query`). +value. Recall in Chapter 10 that the lifetime +parameters specify which argument lifetime is connected to the lifetime of the +return value. In this case, we indicate that the returned vector should contain +string slices that reference slices of the argument `contents` (rather than the +argument `query`). In other words, we tell Rust that the data returned by the `search` function will live as long as the data passed into the `search` function in the @@ -1056,25 +1094,22 @@ If we forget the lifetime annotations and try to compile this function, we’ll get this error: ``` +$ cargo build + Compiling minigrep v0.1.0 (file:///projects/minigrep) error[E0106]: missing lifetime specifier - --> src/lib.rs:31:10 + --> src/lib.rs:28:51 | -29 | query: &str, - | ---- -30 | contents: &str, - | ---- -31 | ) -> Vec<&str> { - | ^ expected named lifetime parameter +28 | pub fn search(query: &str, contents: &str) -> Vec<&str> { + | ---- ---- ^ expected named lifetime parameter | - = help: this function's return type contains a borrowed value, but the -signature does not say whether it is borrowed from `query` or `contents` + = help: this function's return type contains a borrowed value, but the signature does not say whether it is borrowed from `query` or `contents` help: consider introducing a named lifetime parameter | -28 ~ pub fn search<'a>( -29 ~ query: &'a str, -30 ~ contents: &'a str, -31 ~ ) -> Vec<&'a str> { - | +28 | pub fn search<'a>(query: &'a str, contents: &'a str) -> Vec<&'a str> { + | ++++ ++ ++ ++ + +For more information about this error, try `rustc --explain E0106`. +error: could not compile `minigrep` (lib) due to 1 previous error ``` Rust can’t possibly know which of the two arguments we need, so we need to tell @@ -1085,8 +1120,9 @@ syntax. Other programming languages don’t require you to connect arguments to return values in the signature, but this practice will get easier over time. You might -want to compare this example with the examples in “Validating References with -Lifetimes” on page XX. +want to compare this example with the examples in the “Validating References +with Lifetimes” section +in Chapter 10. Now let’s run the test: @@ -1111,8 +1147,7 @@ note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace failures: tests::one_result -test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; -finished in 0.00s +test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s error: test failed, to rerun pass '--lib' ``` @@ -1132,31 +1167,29 @@ that and implement `search`, our program needs to follow these steps: Let’s work through each step, starting with iterating through lines. -#### Iterating Through Lines with the lines Method +#### Iterating Through Lines with the `lines` Method Rust has a helpful method to handle line-by-line iteration of strings, conveniently named `lines`, that works as shown in Listing 12-17. Note that this won’t compile yet. + Filename: src/lib.rs ``` -pub fn search<'a>( - query: &str, - contents: &'a str, -) -> Vec<&'a str> { +pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { for line in contents.lines() { // do something with line } } ``` -Listing 12-17: Iterating through each line in `contents` +Listing 12-17: Iterating through each line in contents The `lines` method returns an iterator. We’ll talk about iterators in depth in -Chapter 13, but recall that you saw this way of using an iterator in Listing -3-5, where we used a `for` loop with an iterator to run some code on each item -in a collection. +Chapter 13, but recall that you saw this way +of using an iterator in Listing 3-5, where we used a +`for` loop with an iterator to run some code on each item in a collection. #### Searching Each Line for the Query @@ -1165,13 +1198,11 @@ Fortunately, strings have a helpful method named `contains` that does this for us! Add a call to the `contains` method in the `search` function, as shown in Listing 12-18. Note that this still won’t compile yet. + Filename: src/lib.rs ``` -pub fn search<'a>( - query: &str, - contents: &'a str, -) -> Vec<&'a str> { +pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { for line in contents.lines() { if line.contains(query) { // do something with line @@ -1180,8 +1211,7 @@ pub fn search<'a>( } ``` -Listing 12-18: Adding functionality to see whether the line contains the string -in `query` +Listing 12-18: Adding functionality to see whether the line contains the string in query At the moment, we’re building up functionality. To get the code to compile, we need to return a value from the body as we indicated we would in the function @@ -1194,13 +1224,11 @@ to return. For that, we can make a mutable vector before the `for` loop and call the `push` method to store a `line` in the vector. After the `for` loop, we return the vector, as shown in Listing 12-19. + Filename: src/lib.rs ``` -pub fn search<'a>( - query: &str, - contents: &'a str, -) -> Vec<&'a str> { +pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> { let mut results = Vec::new(); for line in contents.lines() { @@ -1220,12 +1248,27 @@ and our test should pass. Let’s run the test: ``` $ cargo test ---snip-- + Compiling minigrep v0.1.0 (file:///projects/minigrep) + Finished `test` profile [unoptimized + debuginfo] target(s) in 1.22s + Running unittests src/lib.rs (target/debug/deps/minigrep-9cd200e5fac0fc94) + running 1 test test tests::one_result ... ok -test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Running unittests src/main.rs (target/debug/deps/minigrep-9cd200e5fac0fc94) + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests minigrep + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` Our test passed, so we know it works! @@ -1234,10 +1277,10 @@ At this point, we could consider opportunities for refactoring the implementation of the search function while keeping the tests passing to maintain the same functionality. The code in the search function isn’t too bad, but it doesn’t take advantage of some useful features of iterators. We’ll -return to this example in Chapter 13, where we’ll explore iterators in detail, -and look at how to improve it. +return to this example in Chapter 13, where +we’ll explore iterators in detail, and look at how to improve it. -#### Using the search Function in the run Function +#### Using the `search` Function in the `run` Function Now that the `search` function is working and tested, we need to call `search` from our `run` function. We need to pass the `config.query` value and the @@ -1308,7 +1351,7 @@ users enter it each time they want it to apply, but by instead making it an environment variable, we allow our users to set the environment variable once and have all their searches be case insensitive in that terminal session. -### Writing a Failing Test for the Case-Insensitive search Function +### Writing a Failing Test for the Case-Insensitive `search` Function We first add a new `search_case_insensitive` function that will be called when the environment variable has a value. We’ll continue to follow the TDD process, @@ -1317,6 +1360,7 @@ the new `search_case_insensitive` function and rename our old test from `one_result` to `case_sensitive` to clarify the differences between the two tests, as shown in Listing 12-20. + Filename: src/lib.rs ``` @@ -1333,10 +1377,7 @@ safe, fast, productive. Pick three. Duct tape."; - assert_eq!( - vec!["safe, fast, productive."], - search(query, contents) - ); + assert_eq!(vec!["safe, fast, productive."], search(query, contents)); } #[test] @@ -1356,8 +1397,7 @@ Trust me."; } ``` -Listing 12-20: Adding a new failing test for the case-insensitive function -we’re about to add +Listing 12-20: Adding a new failing test for the case-insensitive function we’re about to add Note that we’ve edited the old test’s `contents` too. We’ve added a new line with the text `"Duct tape."` using a capital *D* that shouldn’t match the query @@ -1375,13 +1415,14 @@ the `search_case_insensitive` function. Feel free to add a skeleton implementation that always returns an empty vector, similar to the way we did for the `search` function in Listing 12-16 to see the test compile and fail. -### Implementing the search_case_insensitive Function +### Implementing the `search_case_insensitive` Function The `search_case_insensitive` function, shown in Listing 12-21, will be almost the same as the `search` function. The only difference is that we’ll lowercase the `query` and each `line` so that whatever the case of the input arguments, they’ll be the same case when we check whether the line contains the query. + Filename: src/lib.rs ``` @@ -1389,11 +1430,11 @@ pub fn search_case_insensitive<'a>( query: &str, contents: &'a str, ) -> Vec<&'a str> { - 1 let query = query.to_lowercase(); + let query = query.to_lowercase(); let mut results = Vec::new(); for line in contents.lines() { - if 2 line.to_lowercase().contains(3 &query) { + if line.to_lowercase().contains(&query) { results.push(line); } } @@ -1402,11 +1443,10 @@ pub fn search_case_insensitive<'a>( } ``` -Listing 12-21: Defining the `search_case_insensitive` function to lowercase the -query and the line before comparing them +Listing 12-21: Defining the search_case_insensitive function to lowercase the query and the line before comparing them First we lowercase the `query` string and store it in a shadowed variable with -the same name [1]. Calling `to_lowercase` on the query is necessary so that no +the same name. Calling `to_lowercase` on the query is necessary so that no matter whether the user’s query is `"rust"`, `"RUST"`, `"Rust"`, or `"rUsT"`, we’ll treat the query as if it were `"rust"` and be insensitive to the case. While `to_lowercase` will handle basic Unicode, it won’t be 100% accurate. If @@ -1419,22 +1459,39 @@ Note that `query` is now a `String` rather than a string slice because calling query is `"rUsT"`, as an example: that string slice doesn’t contain a lowercase `u` or `t` for us to use, so we have to allocate a new `String` containing `"rust"`. When we pass `query` as an argument to the `contains` method now, we -need to add an ampersand [3] because the signature of `contains` is defined to -take a string slice. +need to add an ampersand because the signature of `contains` is defined to take +a string slice. Next, we add a call to `to_lowercase` on each `line` to lowercase all -characters [2]. Now that we’ve converted `line` and `query` to lowercase, we’ll +characters. Now that we’ve converted `line` and `query` to lowercase, we’ll find matches no matter what the case of the query is. Let’s see if this implementation passes the tests: ``` +$ cargo test + Compiling minigrep v0.1.0 (file:///projects/minigrep) + Finished `test` profile [unoptimized + debuginfo] target(s) in 1.33s + Running unittests src/lib.rs (target/debug/deps/minigrep-9cd200e5fac0fc94) + running 2 tests test tests::case_insensitive ... ok test tests::case_sensitive ... ok -test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 -filtered out; finished in 0.00s +test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Running unittests src/main.rs (target/debug/deps/minigrep-9cd200e5fac0fc94) + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + + Doc-tests minigrep + +running 0 tests + +test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s + ``` Great! They passed. Now, let’s call the new `search_case_insensitive` function @@ -1458,6 +1515,7 @@ function to check the `ignore_case` field’s value and use that to decide whether to call the `search` function or the `search_case_insensitive` function, as shown in Listing 12-22. This still won’t compile yet. + Filename: src/lib.rs ``` @@ -1478,8 +1536,7 @@ pub fn run(config: Config) -> Result<(), Box> { } ``` -Listing 12-22: Calling either `search` or `search_case_insensitive` based on -the value in `config.ignore_case` +Listing 12-22: Calling either search or search_case_insensitive based on the value in config.ignore_case Finally, we need to check for the environment variable. The functions for working with environment variables are in the `env` module in the standard @@ -1488,16 +1545,15 @@ we’ll use the `var` function from the `env` module to check to see if any valu has been set for an environment variable named `IGNORE_CASE`, as shown in Listing 12-23. + Filename: src/lib.rs ``` use std::env; ---snip-- +// --snip-- impl Config { - pub fn build( - args: &[String] - ) -> Result { + pub fn build(args: &[String]) -> Result { if args.len() < 3 { return Err("not enough arguments"); } @@ -1516,8 +1572,7 @@ impl Config { } ``` -Listing 12-23: Checking for any value in an environment variable named -`IGNORE_CASE` +Listing 12-23: Checking for any value in an environment variable named IGNORE_CASE Here, we create a new variable, `ignore_case`. To set its value, we call the `env::var` function and pass it the name of the `IGNORE_CASE` environment @@ -1574,6 +1629,12 @@ PS> Remove-Item Env:IGNORE_CASE We should get lines that contain *to* that might have uppercase letters: + + ``` Are you nobody, too? How dreary to be somebody! @@ -1653,6 +1714,7 @@ the `eprintln!` macro that prints to the standard error stream, so let’s chang the two places we were calling `println!` to print errors to use `eprintln!` instead. + Filename: src/main.rs ``` @@ -1671,8 +1733,7 @@ fn main() { } ``` -Listing 12-24: Writing error messages to standard error instead of standard -output using `eprintln!` +Listing 12-24: Writing error messages to standard error instead of standard output using eprintln! Let’s now run the program again in the same way, without any arguments and redirecting standard output with `>`: @@ -1717,4 +1778,3 @@ well tested. Next, we’ll explore some Rust features that were influenced by functional languages: closures and iterators. - From e7d217be2a75ef1753f0988d6ccaba4d7e376259 Mon Sep 17 00:00:00 2001 From: "Carol (Nichols || Goulding)" Date: Tue, 13 Aug 2024 20:40:47 -0400 Subject: [PATCH 14/14] Snapshot changes to ch 12 to consider sending to nostarch --- nostarch/chapter12.md | 87 +++++++++++++++++++++++-------------------- 1 file changed, 47 insertions(+), 40 deletions(-) diff --git a/nostarch/chapter12.md b/nostarch/chapter12.md index f1020eed4..3ce134974 100644 --- a/nostarch/chapter12.md +++ b/nostarch/chapter12.md @@ -137,7 +137,7 @@ $ cargo run Compiling minigrep v0.1.0 (file:///projects/minigrep) Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.61s Running `target/debug/minigrep` -[src/main.rs:5] args = [ +[src/main.rs:5:5] args = [ "target/debug/minigrep", ] ``` @@ -147,7 +147,7 @@ $ cargo run -- needle haystack Compiling minigrep v0.1.0 (file:///projects/minigrep) Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.57s Running `target/debug/minigrep needle haystack` -[src/main.rs:5] args = [ +[src/main.rs:5:5] args = [ "target/debug/minigrep", "needle", "haystack", @@ -181,8 +181,8 @@ fn main() { let query = &args[1]; let file_path = &args[2]; - println!("Searching for {}", query); - println!("In file {}", file_path); + println!("Searching for {query}"); + println!("In file {file_path}"); } ``` @@ -202,7 +202,7 @@ and `sample.txt`: ``` $ cargo run -- test sample.txt Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished dev [unoptimized + debuginfo] target(s) in 0.0s + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep test sample.txt` Searching for test In file sample.txt @@ -252,7 +252,7 @@ use std::fs; fn main() { // --snip-- - println!("In file {}", file_path); + println!("In file {file_path}"); let contents = fs::read_to_string(file_path) .expect("Should have been able to read the file"); @@ -267,7 +267,8 @@ First we bring in a relevant part of the standard library with a `use` statement: we need `std::fs` to handle files. In `main`, the new statement `fs::read_to_string` takes the `file_path`, opens -that file, and returns an `std::io::Result` of the file’s contents [2]. +that file, and returns a value of type `std::io::Result` that contains +the file’s contents. After that, we again add a temporary `println!` statement that prints the value of `contents` after the file is read, so we can check that the program is @@ -280,7 +281,7 @@ second argument: ``` $ cargo run -- the poem.txt Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished dev [unoptimized + debuginfo] target(s) in 0.0s + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep the poem.txt` Searching for the In file poem.txt @@ -331,13 +332,13 @@ example, the file could be missing, or we might not have permission to open it. Right now, regardless of the situation, we’d print the same error message for everything, which wouldn’t give the user any information! -Fourth, we use `expect` repeatedly to handle different errors, and if the user -runs our program without specifying enough arguments, they’ll get an `index out -of bounds` error from Rust that doesn’t clearly explain the problem. It would -be best if all the error-handling code were in one place so future maintainers -had only one place to consult the code if the error-handling logic needed to -change. Having all the error-handling code in one place will also ensure that -we’re printing messages that will be meaningful to our end users. +Fourth, we use `expect` to handle an error, and if the user runs our program +without specifying enough arguments, they’ll get an `index out of bounds` error +from Rust that doesn’t clearly explain the problem. It would be best if all the +error-handling code were in one place so future maintainers had only one place +to consult the code if the error-handling logic needed to change. Having all the +error-handling code in one place will also ensure that we’re printing messages +that will be meaningful to our end users. Let’s address these four problems by refactoring our project. @@ -566,12 +567,11 @@ without any arguments; it will look like this: ``` $ cargo run Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished dev [unoptimized + debuginfo] target(s) in 0.0s + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep` -thread 'main' panicked at 'index out of bounds: the len is 1 but -the index is 1', src/main.rs:27:21 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'main' panicked at src/main.rs:27:21: +index out of bounds: the len is 1 but the index is 1 +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` The line `index out of bounds: the len is 1 but the index is 1` is an error @@ -612,12 +612,11 @@ arguments again to see what the error looks like now: ``` $ cargo run Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished dev [unoptimized + debuginfo] target(s) in 0.0s + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep` -thread 'main' panicked at 'not enough arguments', -src/main.rs:26:13 -note: run with `RUST_BACKTRACE=1` environment variable to display -a backtrace +thread 'main' panicked at src/main.rs:26:13: +not enough arguments +note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` This output is better: we now have a reasonable error message. However, we also @@ -668,7 +667,7 @@ impl Config { Listing 12-9: Returning a Result from Config::build Our `build` function returns a `Result` with a `Config` instance in the success -case and an `&'static str` in the error case. Our error values will always be +case and a string literal in the error case. Our error values will always be string literals that have the `'static` lifetime. We’ve made two changes in the body of the function: instead of calling `panic!` @@ -737,7 +736,7 @@ extra output. Let’s try it: ``` $ cargo run Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished dev [unoptimized + debuginfo] target(s) in 0.48s + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.48s Running `target/debug/minigrep` Problem parsing arguments: not enough arguments ``` @@ -851,11 +850,16 @@ warning: unused `Result` that must be used --> src/main.rs:19:5 | 19 | run(config); - | ^^^^^^^^^^^^ + | ^^^^^^^^^^^ | + = note: this `Result` may be an `Err` variant, which should be handled = note: `#[warn(unused_must_use)]` on by default - = note: this `Result` may be an `Err` variant, which should be -handled +help: use `let _ = ...` to ignore the resulting value + | +19 | let _ = run(config); + | +++++++ + +warning: `minigrep` (bin "minigrep") generated 1 warning Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.71s Running `target/debug/minigrep the poem.txt` Searching for the @@ -1129,7 +1133,7 @@ Now let’s run the test: ``` $ cargo test Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished test [unoptimized + debuginfo] target(s) in 0.97s + Finished `test` profile [unoptimized + debuginfo] target(s) in 0.97s Running unittests src/lib.rs (target/debug/deps/minigrep-9cd200e5fac0fc94) running 1 test @@ -1138,9 +1142,10 @@ test tests::one_result ... FAILED failures: ---- tests::one_result stdout ---- -thread 'tests::one_result' panicked at 'assertion failed: `(left == right)` - left: `["safe, fast, productive."]`, - right: `[]`', src/lib.rs:47:9 +thread 'tests::one_result' panicked at src/lib.rs:44:9: +assertion `left == right` failed + left: ["safe, fast, productive."] + right: [] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace @@ -1149,7 +1154,7 @@ failures: test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s -error: test failed, to rerun pass '--lib' +error: test failed, to rerun pass `--lib` ``` Great, the test fails, exactly as we expected. Let’s get the test to pass! @@ -1309,7 +1314,7 @@ should return exactly one line from the Emily Dickinson poem: *frog*. ``` $ cargo run -- frog poem.txt Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished dev [unoptimized + debuginfo] target(s) in 0.38s + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.38s Running `target/debug/minigrep frog poem.txt` How public, like a frog ``` @@ -1318,7 +1323,8 @@ Cool! Now let’s try a word that will match multiple lines, like *body*: ``` $ cargo run -- body poem.txt - Finished dev [unoptimized + debuginfo] target(s) in 0.0s + Compiling minigrep v0.1.0 (file:///projects/minigrep) + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep body poem.txt` I'm nobody! Who are you? Are you nobody, too? @@ -1330,7 +1336,8 @@ word that isn’t anywhere in the poem, such as *monomorphization*: ``` $ cargo run -- monomorphization poem.txt - Finished dev [unoptimized + debuginfo] target(s) in 0.0s + Compiling minigrep v0.1.0 (file:///projects/minigrep) + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep monomorphization poem.txt` ``` @@ -1600,14 +1607,14 @@ the word *to* in all lowercase: ``` $ cargo run -- to poem.txt Compiling minigrep v0.1.0 (file:///projects/minigrep) - Finished dev [unoptimized + debuginfo] target(s) in 0.0s + Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.0s Running `target/debug/minigrep to poem.txt` Are you nobody, too? How dreary to be somebody! ``` Looks like that still works! Now let’s run the program with `IGNORE_CASE` set -to `1` but with the same query `to`: +to `1` but with the same query *to*: ``` $ IGNORE_CASE=1 cargo run -- to poem.txt