From 9fa01778470c44d2c7fe4db4314b79f283b69230 Mon Sep 17 00:00:00 2001 From: Ximin Luo Date: Sun, 19 May 2019 01:32:59 -0700 Subject: [PATCH] New upstream version 1.34.2+dfsg1 --- CONTRIBUTING.md | 268 +- COPYRIGHT | 6 +- Cargo.lock | 979 ++- README.md | 6 +- RELEASES.md | 171 + config.toml.example | 13 +- git-commit-hash | 2 +- src/README.md | 1 - src/bootstrap/bin/main.rs | 2 - src/bootstrap/bin/rustc.rs | 6 +- src/bootstrap/bin/rustdoc.rs | 33 +- src/bootstrap/bin/sccache-plus-cl.rs | 2 - src/bootstrap/bootstrap.py | 15 +- src/bootstrap/builder.rs | 93 +- src/bootstrap/cache.rs | 10 +- src/bootstrap/cc_detect.rs | 3 +- src/bootstrap/channel.rs | 2 +- src/bootstrap/check.rs | 58 +- src/bootstrap/clean.rs | 2 +- src/bootstrap/compile.rs | 126 +- src/bootstrap/config.rs | 19 +- src/bootstrap/configure.py | 6 +- src/bootstrap/dist.rs | 171 +- src/bootstrap/doc.rs | 164 +- src/bootstrap/install.rs | 36 +- src/bootstrap/lib.rs | 55 +- src/bootstrap/mk/Makefile.in | 1 - src/bootstrap/native.rs | 78 +- src/bootstrap/sanity.rs | 4 +- src/bootstrap/test.rs | 273 +- src/bootstrap/tool.rs | 117 +- src/bootstrap/util.rs | 10 +- src/build_helper/Cargo.toml | 1 + src/build_helper/lib.rs | 27 +- src/ci/docker/README.md | 26 +- src/ci/docker/arm-android/Dockerfile | 2 +- src/ci/docker/armhf-gnu/Dockerfile | 3 +- .../disabled/dist-x86_64-redox/Dockerfile | 4 +- src/ci/docker/dist-arm-linux/Dockerfile | 1 + .../dist-arm-linux/arm-linux-gnueabi.config | 26 +- .../001-arm-libgcc_s_resume-used.patch | 48 + src/ci/docker/dist-armhf-linux/Dockerfile | 1 + .../arm-linux-gnueabihf.config | 26 +- .../001-arm-libgcc_s_resume-used.patch | 48 + src/ci/docker/dist-armv7-linux/Dockerfile | 1 + .../armv7-linux-gnueabihf.config | 34 +- .../001-arm-libgcc_s_resume-used.patch | 48 + .../patches/glibc/2.12.2/002-newer-gcc.patch | 26 + .../powerpc-linux-gnu.config | 17 +- .../patches/glibc/2.12.2/003-newer-gcc.patch | 26 + .../powerpc64-linux-gnu.config | 18 +- .../patches/glibc/2.12.2/002-newer-gcc.patch | 26 + .../dist-s390x-linux/s390x-linux-gnu.config | 17 +- src/ci/docker/dist-various-1/Dockerfile | 2 + .../dist-various-1/install-x86_64-redox.sh | 10 +- src/ci/docker/dist-various-2/Dockerfile | 3 +- .../build-cloudabi-toolchain.sh | 9 +- ...d-x86_64-fortanix-unknown-sgx-toolchain.sh | 35 +- src/ci/docker/dist-various-2/shared.sh | 15 +- .../docker/dist-x86_64-linux/build-clang.sh | 27 +- src/ci/docker/dist-x86_64-linux/build-gcc.sh | 4 +- src/ci/docker/dist-x86_64-linux/build-perl.sh | 3 +- src/ci/docker/run.sh | 8 +- src/ci/docker/scripts/android-sdk.sh | 16 +- src/ci/docker/scripts/freebsd-toolchain.sh | 6 +- .../Dockerfile | 19 +- src/ci/docker/x86_64-gnu-debug/Dockerfile | 27 +- src/ci/docker/x86_64-gnu-tools/checktools.sh | 1 + src/ci/init_repo.sh | 10 +- src/ci/run.sh | 2 +- src/ci/shared.sh | 1 + src/doc/book/.github/ISSUE_TEMPLATE.md | 22 - src/doc/book/.github/PULL_REQUEST_TEMPLATE.md | 24 - src/doc/book/.travis.yml | 2 +- src/doc/book/2018-edition/convert-quotes.sh | 9 - src/doc/book/2018-edition/nostarch.sh | 19 +- .../book/2018-edition/nostarch/chapter07.md | 10 +- .../tools/src/bin/concat_chapters.rs | 10 - .../tools/src/bin/convert_quotes.rs | 11 - .../book/2018-edition/tools/src/bin/lfp.rs | 15 +- .../2018-edition/tools/src/bin/link2print.rs | 31 +- .../tools/src/bin/remove_links.rs | 24 +- .../tools/src/bin/remove_markup.rs | 19 +- src/doc/book/CONTRIBUTING.md | 39 +- src/doc/book/Cargo.toml | 1 + src/doc/book/README.md | 66 +- src/doc/book/ci/build.sh | 12 +- src/doc/book/ci/dictionary.txt | 33 +- src/doc/book/ci/spellcheck.sh | 34 +- src/doc/book/ci/stable-check/src/main.rs | 10 - src/doc/book/convert-quotes.sh | 9 - src/doc/book/nostarch.sh | 19 +- .../book/nostarch/appendix-a-new-section.md | 55 + .../chapter-03-integer-overflow-box.md | 21 + .../nostarch/chapter-03-new-array-text.md | 25 + .../chapter-03-returning-values-from-loops.md | 33 + .../chapter-04-error-message-updates.md | 49 + .../chapter-04-stack-heap-box-edits.md | 28 + .../chapter-08-error-message-updates.md | 15 + .../book/nostarch/chapter-08-listing-8-5.md | 13 + .../chapter-09-error-message-updates.md | 43 + .../nostarch/chapter-09-listing-9-2-update.md | 50 + .../nostarch/chapter-09-listing-9-5-update.md | 21 + .../book/nostarch/chapter-09-match-update.md | 37 + .../chapter-09-read-to-string-update.md | 25 + .../chapter-12-error-message-updates.md | 12 + .../book/nostarch/chapter-15-code-updates.md | 11 + .../chapter-15-error-message-updates.md | 12 + ...-destructuring-nested-structs-and-enums.md | 54 + .../chapter-19-new-function-pointer-text.md | 30 + src/doc/book/nostarch/chapter07.md | 10 +- .../chapter10-traits-as-parameters.md | 171 + .../chapter11-using-result-in-tests.md | 35 + src/doc/book/nostarch/version-note.md | 9 + src/doc/book/redirects/attributes.md | 2 +- src/doc/book/redirects/release-channels.md | 2 +- src/doc/book/second-edition/convert-quotes.sh | 9 - src/doc/book/second-edition/doc-to-md.sh | 31 +- src/doc/book/second-edition/nostarch.sh | 19 +- .../book/second-edition/nostarch/appendix.md | 927 --- .../book/second-edition/nostarch/chapter00.md | 177 - .../book/second-edition/nostarch/chapter01.md | 592 -- .../book/second-edition/nostarch/chapter02.md | 984 --- .../book/second-edition/nostarch/chapter03.md | 1472 ----- .../book/second-edition/nostarch/chapter04.md | 1244 ---- .../book/second-edition/nostarch/chapter05.md | 859 --- .../book/second-edition/nostarch/chapter06.md | 753 --- .../book/second-edition/nostarch/chapter07.md | 1069 ---- .../book/second-edition/nostarch/chapter08.md | 1046 ---- .../book/second-edition/nostarch/chapter09.md | 938 --- .../book/second-edition/nostarch/chapter10.md | 1882 ------ .../book/second-edition/nostarch/chapter11.md | 1442 ----- .../book/second-edition/nostarch/chapter12.md | 1688 ------ .../book/second-edition/nostarch/chapter13.md | 1528 ----- .../book/second-edition/nostarch/chapter14.md | 984 --- .../book/second-edition/nostarch/chapter15.md | 1976 ------ .../book/second-edition/nostarch/chapter16.md | 1306 ---- .../book/second-edition/nostarch/chapter17.md | 1267 ---- .../book/second-edition/nostarch/chapter18.md | 1315 ---- .../book/second-edition/nostarch/chapter19.md | 2078 ------- .../book/second-edition/nostarch/chapter20.md | 2102 ------- .../book/second-edition/nostarch/foreword.md | 41 - .../second-edition/nostarch/introduction.md | 169 - .../tools/src/bin/concat_chapters.rs | 10 - .../tools/src/bin/convert_quotes.rs | 19 +- .../book/second-edition/tools/src/bin/lfp.rs | 10 - .../tools/src/bin/link2print.rs | 27 +- .../tools/src/bin/remove_links.rs | 22 +- .../tools/src/bin/remove_markup.rs | 19 +- src/doc/book/src/SUMMARY.md | 55 +- src/doc/book/src/appendix-01-keywords.md | 48 +- .../book/src/appendix-03-derivable-traits.md | 30 +- .../appendix-04-useful-development-tools.md | 12 +- src/doc/book/src/appendix-06-translation.md | 7 +- src/doc/book/src/appendix-07-nightly-rust.md | 4 +- src/doc/book/src/ch00-00-introduction.md | 14 +- src/doc/book/src/ch01-01-installation.md | 8 +- src/doc/book/src/ch01-02-hello-world.md | 44 +- src/doc/book/src/ch01-03-hello-cargo.md | 17 +- .../src/ch02-00-guessing-game-tutorial.md | 55 +- .../ch03-00-common-programming-concepts.md | 52 +- .../src/ch03-01-variables-and-mutability.md | 24 +- src/doc/book/src/ch03-02-data-types.md | 107 +- .../book/src/ch03-03-how-functions-work.md | 4 +- src/doc/book/src/ch03-04-comments.md | 2 +- src/doc/book/src/ch03-05-control-flow.md | 33 +- src/doc/book/src/ch04-01-what-is-ownership.md | 55 +- .../src/ch04-02-references-and-borrowing.md | 33 +- src/doc/book/src/ch04-03-slices.md | 34 +- src/doc/book/src/ch05-02-example-structs.md | 17 +- src/doc/book/src/ch06-02-match.md | 6 +- .../ch07-00-packages-crates-and-modules.md | 2 +- ...es-and-use-to-control-scope-and-privacy.md | 56 +- src/doc/book/src/ch08-01-vectors.md | 26 +- src/doc/book/src/ch08-03-hash-maps.md | 6 +- ...ch09-01-unrecoverable-errors-with-panic.md | 105 +- .../ch09-02-recoverable-errors-with-result.md | 121 +- .../src/ch09-03-to-panic-or-not-to-panic.md | 13 +- src/doc/book/src/ch10-01-syntax.md | 7 +- src/doc/book/src/ch10-02-traits.md | 133 +- src/doc/book/src/ch10-03-lifetime-syntax.md | 39 +- src/doc/book/src/ch11-01-writing-tests.md | 138 +- src/doc/book/src/ch11-02-running-tests.md | 10 +- src/doc/book/src/ch11-03-test-organization.md | 20 +- ...h12-01-accepting-command-line-arguments.md | 16 +- src/doc/book/src/ch12-02-reading-a-file.md | 15 +- ...improving-error-handling-and-modularity.md | 158 +- ...2-04-testing-the-librarys-functionality.md | 30 +- ...2-05-working-with-environment-variables.md | 22 +- src/doc/book/src/ch13-01-closures.md | 29 +- src/doc/book/src/ch13-02-iterators.md | 6 +- .../src/ch13-03-improving-our-io-project.md | 6 +- .../src/ch14-02-publishing-to-crates-io.md | 24 +- src/doc/book/src/ch14-03-cargo-workspaces.md | 4 +- src/doc/book/src/ch15-01-box.md | 26 +- src/doc/book/src/ch15-02-deref.md | 11 +- src/doc/book/src/ch15-04-rc.md | 11 +- .../book/src/ch15-05-interior-mutability.md | 11 +- src/doc/book/src/ch15-06-reference-cycles.md | 10 +- ...04-extensible-concurrency-sync-and-send.md | 7 +- src/doc/book/src/ch17-01-what-is-oo.md | 24 +- src/doc/book/src/ch17-02-trait-objects.md | 46 +- .../book/src/ch17-03-oo-design-patterns.md | 12 +- .../ch18-01-all-the-places-for-patterns.md | 16 +- src/doc/book/src/ch18-03-pattern-syntax.md | 149 +- src/doc/book/src/ch19-01-unsafe-rust.md | 74 +- .../book/src/ch19-02-advanced-lifetimes.md | 101 +- src/doc/book/src/ch19-03-advanced-traits.md | 55 +- src/doc/book/src/ch19-04-advanced-types.md | 43 +- ...ch19-05-advanced-functions-and-closures.md | 31 +- src/doc/book/src/ch19-06-macros.md | 6 +- src/doc/book/src/ch20-01-single-threaded.md | 4 +- src/doc/book/src/ch20-02-multithreaded.md | 39 +- src/doc/book/src/img/trpl14-01.png | Bin 65437 -> 123988 bytes src/doc/book/src/img/trpl14-02.png | Bin 175642 -> 81694 bytes src/doc/book/src/img/trpl14-03.png | Bin 43085 -> 94569 bytes src/doc/book/src/img/trpl14-04.png | Bin 68900 -> 241098 bytes src/doc/book/src/title-page.md | 20 + src/doc/book/tools/src/bin/concat_chapters.rs | 28 +- src/doc/book/tools/src/bin/convert_quotes.rs | 20 +- src/doc/book/tools/src/bin/lfp.rs | 15 +- src/doc/book/tools/src/bin/link2print.rs | 37 +- src/doc/book/tools/src/bin/remove_links.rs | 28 +- src/doc/book/tools/src/bin/remove_markup.rs | 21 +- src/doc/embedded-book/.github/CODEOWNERS | 1 + src/doc/embedded-book/.github/bors.toml | 4 + src/doc/embedded-book/.travis.yml | 20 + src/doc/embedded-book/CNAME | 1 + src/doc/embedded-book/CODE_OF_CONDUCT.md | 37 + src/doc/embedded-book/LICENSE-APACHE | 201 + src/doc/embedded-book/LICENSE-CC-BY-SA | 428 ++ src/doc/embedded-book/LICENSE-MIT | 23 + src/doc/embedded-book/README.md | 46 + src/doc/embedded-book/book.toml | 5 + src/doc/embedded-book/ci/after-success.sh | 17 + src/doc/embedded-book/ci/install.sh | 18 + src/doc/embedded-book/ci/script.sh | 20 + src/doc/embedded-book/src/SUMMARY.md | 48 + .../embedded-book/src/assets/embedded-hal.svg | 2 + src/doc/embedded-book/src/assets/f3.jpg | Bin 0 -> 259494 bytes .../src/assets/nrf52-memory-map.png | Bin 0 -> 143848 bytes .../assets/nrf52-spi-frequency-register.png | Bin 0 -> 70351 bytes .../embedded-book/src/assets/rust_layers.svg | 1 + src/doc/embedded-book/src/assets/verify.jpeg | Bin 0 -> 155671 bytes src/doc/embedded-book/src/c-tips/index.md | 412 ++ .../embedded-book/src/collections/index.md | 259 + .../embedded-book/src/concurrency/index.md | 566 ++ .../src/interoperability/c-with-rust.md | 131 + .../src/interoperability/index.md | 63 + .../src/interoperability/rust-with-c.md | 105 + src/doc/embedded-book/src/intro/hardware.md | 44 + src/doc/embedded-book/src/intro/index.md | 99 + src/doc/embedded-book/src/intro/install.md | 39 + .../embedded-book/src/intro/install/linux.md | 129 + .../embedded-book/src/intro/install/macos.md | 21 + .../embedded-book/src/intro/install/verify.md | 70 + .../src/intro/install/windows.md | 50 + src/doc/embedded-book/src/intro/no-std.md | 63 + src/doc/embedded-book/src/intro/tooling.md | 85 + .../src/peripherals/a-first-attempt.md | 139 + .../embedded-book/src/peripherals/borrowck.md | 19 + .../embedded-book/src/peripherals/index.md | 44 + .../src/peripherals/singletons.md | 154 + .../embedded-book/src/portability/index.md | 62 + src/doc/embedded-book/src/start/exceptions.md | 256 + src/doc/embedded-book/src/start/hardware.md | 340 ++ src/doc/embedded-book/src/start/index.md | 10 + src/doc/embedded-book/src/start/interrupts.md | 60 + src/doc/embedded-book/src/start/io.md | 3 + src/doc/embedded-book/src/start/panicking.md | 100 + src/doc/embedded-book/src/start/qemu.md | 541 ++ src/doc/embedded-book/src/start/registers.md | 188 + .../embedded-book/src/start/semihosting.md | 132 + .../src/static-guarantees/design-contracts.md | 254 + .../src/static-guarantees/index.md | 23 + .../src/static-guarantees/state-machines.md | 98 + .../typestate-programming.md | 63 + .../zero-cost-abstractions.md | 42 + src/doc/embedded-book/src/unsorted/index.md | 1 + .../src/unsorted/speed-vs-size.md | 178 + src/doc/guide-error-handling.md | 2 +- src/doc/guide-ownership.md | 2 +- src/doc/guide-pointers.md | 2 +- src/doc/guide-testing.md | 2 +- src/doc/index.md | 26 + src/doc/reference/.travis.yml | 6 +- src/doc/reference/src/attributes.md | 21 +- .../reference/src/conditional-compilation.md | 6 +- src/doc/reference/src/const_eval.md | 15 +- .../reference/src/crates-and-source-files.md | 6 +- .../reference/src/expressions/closure-expr.md | 21 +- .../reference/src/expressions/loop-expr.md | 10 +- .../reference/src/expressions/match-expr.md | 19 +- .../reference/src/expressions/struct-expr.md | 9 +- src/doc/reference/src/glossary.md | 6 + src/doc/reference/src/input-format.md | 7 - src/doc/reference/src/introduction.md | 6 +- src/doc/reference/src/items/extern-crates.md | 53 +- src/doc/reference/src/items/functions.md | 12 +- .../reference/src/items/use-declarations.md | 61 +- src/doc/reference/src/macros-by-example.md | 2 + src/doc/reference/src/macros.md | 6 +- src/doc/reference/src/notation.md | 26 +- src/doc/reference/src/patterns.md | 12 +- src/doc/reference/src/types/pointer.md | 2 +- .../reference/src/visibility-and-privacy.md | 8 +- src/doc/reference/stable-check/src/main.rs | 12 +- src/doc/rustc/src/SUMMARY.md | 3 +- src/doc/rustc/src/codegen-options/index.md | 2 +- src/doc/rustc/src/command-line-arguments.md | 4 +- src/doc/rustc/src/contributing.md | 8 +- src/doc/rustc/src/linker-plugin-lto.md | 108 + src/doc/rustc/src/lints/levels.md | 4 +- .../src/lints/listing/deny-by-default.md | 20 + .../src/lints/listing/warn-by-default.md | 20 - src/doc/rustdoc/src/documentation-tests.md | 17 + src/doc/rustdoc/src/unstable-features.md | 17 +- .../crate-visibility-modifier.md | 4 +- .../src/language-features/generators.md | 31 +- .../src/language-features/plugin.md | 3 +- .../src/language-features/repr-align-enum.md | 42 + .../src/library-features/is-sorted.md | 11 + src/etc/gdb_rust_pretty_printing.py | 13 +- src/etc/generate-deriving-span-tests.py | 30 +- src/etc/generate-keyword-tests.py | 4 +- src/liballoc/Cargo.toml | 1 + src/liballoc/alloc.rs | 9 +- src/liballoc/benches/btree/map.rs | 1 + src/liballoc/benches/btree/mod.rs | 1 + src/liballoc/benches/btree/set.rs | 88 + src/liballoc/benches/lib.rs | 3 - src/liballoc/benches/slice.rs | 6 +- src/liballoc/benches/vec_deque.rs | 7 + src/liballoc/benches/vec_deque_append.rs | 1 - src/liballoc/borrow.rs | 53 +- src/liballoc/boxed.rs | 68 +- src/liballoc/collections/binary_heap.rs | 545 +- src/liballoc/collections/btree/map.rs | 144 +- src/liballoc/collections/btree/node.rs | 97 +- src/liballoc/collections/btree/search.rs | 8 +- src/liballoc/collections/btree/set.rs | 83 +- src/liballoc/collections/linked_list.rs | 48 +- src/liballoc/collections/mod.rs | 12 +- src/liballoc/collections/vec_deque.rs | 146 +- src/liballoc/fmt.rs | 10 +- src/liballoc/lib.rs | 27 +- src/liballoc/macros.rs | 11 +- src/liballoc/prelude.rs | 10 +- src/liballoc/raw_vec.rs | 21 +- src/liballoc/rc.rs | 120 +- src/liballoc/slice.rs | 33 +- src/liballoc/str.rs | 58 +- src/liballoc/string.rs | 92 +- src/liballoc/sync.rs | 149 +- src/liballoc/task.rs | 130 - src/liballoc/tests/binary_heap.rs | 5 +- src/liballoc/tests/btree/map.rs | 34 +- src/liballoc/tests/btree/set.rs | 6 +- src/liballoc/tests/heap.rs | 2 +- src/liballoc/tests/lib.rs | 5 - src/liballoc/tests/linked_list.rs | 6 +- src/liballoc/tests/slice.rs | 33 +- src/liballoc/tests/str.rs | 90 +- src/liballoc/tests/string.rs | 15 +- src/liballoc/tests/vec.rs | 18 +- src/liballoc/tests/vec_deque.rs | 122 +- src/liballoc/vec.rs | 96 +- src/libarena/Cargo.toml | 3 +- src/libarena/lib.rs | 22 +- src/libcore/alloc.rs | 6 +- src/libcore/any.rs | 22 +- src/libcore/array.rs | 8 +- src/libcore/benches/fmt.rs | 110 + src/libcore/benches/lib.rs | 1 + src/libcore/cell.rs | 16 +- src/libcore/char/convert.rs | 6 +- src/libcore/char/decode.rs | 2 +- src/libcore/char/methods.rs | 24 +- src/libcore/char/mod.rs | 2 +- src/libcore/cmp.rs | 40 +- src/libcore/convert.rs | 210 +- src/libcore/default.rs | 2 +- src/libcore/ffi.rs | 43 +- src/libcore/fmt/builders.rs | 323 +- src/libcore/fmt/mod.rs | 132 +- src/libcore/fmt/num.rs | 107 +- src/libcore/future/future.rs | 53 +- src/libcore/hash/sip.rs | 8 +- src/libcore/hint.rs | 25 +- src/libcore/internal_macros.rs | 46 +- src/libcore/intrinsics.rs | 516 +- src/libcore/iter/adapters/chain.rs | 260 + src/libcore/iter/adapters/flatten.rs | 330 + src/libcore/iter/adapters/mod.rs | 2045 +++++++ src/libcore/iter/adapters/zip.rs | 282 + src/libcore/iter/mod.rs | 2796 +-------- src/libcore/iter/range.rs | 71 +- src/libcore/iter/sources.rs | 73 +- src/libcore/iter/traits.rs | 1060 ---- src/libcore/iter/traits/accum.rs | 225 + src/libcore/iter/traits/collect.rs | 349 ++ src/libcore/iter/traits/double_ended.rs | 297 + src/libcore/iter/traits/exact_size.rs | 143 + src/libcore/iter/{ => traits}/iterator.rs | 158 +- src/libcore/iter/traits/marker.rs | 44 + src/libcore/iter/traits/mod.rs | 15 + src/libcore/lib.rs | 58 +- src/libcore/macros.rs | 49 +- src/libcore/marker.rs | 5 +- src/libcore/mem.rs | 176 +- src/libcore/num/bignum.rs | 11 - src/libcore/num/dec2flt/algorithm.rs | 2 +- src/libcore/num/dec2flt/mod.rs | 36 +- src/libcore/num/dec2flt/num.rs | 6 +- src/libcore/num/dec2flt/parse.rs | 2 +- src/libcore/num/dec2flt/rawfp.rs | 14 +- src/libcore/num/f32.rs | 10 +- src/libcore/num/f64.rs | 10 +- src/libcore/num/mod.rs | 357 +- src/libcore/ops/arith.rs | 6 +- src/libcore/ops/deref.rs | 4 +- src/libcore/ops/function.rs | 6 +- src/libcore/ops/generator.rs | 37 +- src/libcore/ops/index.rs | 15 + src/libcore/ops/range.rs | 6 +- src/libcore/ops/try.rs | 2 +- src/libcore/option.rs | 14 +- src/libcore/pin.rs | 57 +- src/libcore/ptr.rs | 42 +- src/libcore/result.rs | 2 +- src/libcore/slice/memchr.rs | 29 +- src/libcore/slice/mod.rs | 168 +- src/libcore/slice/rotate.rs | 8 +- src/libcore/slice/sort.rs | 12 +- src/libcore/str/mod.rs | 785 +-- src/libcore/str/pattern.rs | 12 +- src/libcore/sync/atomic.rs | 196 +- src/libcore/task/mod.rs | 2 +- src/libcore/task/poll.rs | 11 +- src/libcore/task/wake.rs | 346 +- src/libcore/tests/cell.rs | 3 + src/libcore/tests/fmt/mod.rs | 2 + src/libcore/tests/hash/mod.rs | 2 + src/libcore/tests/iter.rs | 43 +- src/libcore/tests/lib.rs | 3 +- src/libcore/tests/nonzero.rs | 10 +- src/libcore/tests/num/bignum.rs | 14 + src/libcore/tests/num/dec2flt/mod.rs | 2 + src/libcore/tests/num/flt2dec/mod.rs | 2 + src/libcore/tests/option.rs | 3 + src/libcore/tests/ptr.rs | 14 +- src/libcore/tests/result.rs | 3 + src/libcore/tests/slice.rs | 25 + src/libcore/tests/time.rs | 2 + src/libcore/time.rs | 72 +- src/libfmt_macros/Cargo.toml | 1 + src/libfmt_macros/lib.rs | 26 +- src/libgraphviz/Cargo.toml | 1 + src/libgraphviz/lib.rs | 21 +- src/libpanic_abort/Cargo.toml | 1 + src/libpanic_abort/lib.rs | 13 +- src/libpanic_unwind/Cargo.toml | 1 + src/libpanic_unwind/dummy.rs | 4 +- src/libpanic_unwind/dwarf/eh.rs | 8 +- src/libpanic_unwind/dwarf/mod.rs | 2 +- src/libpanic_unwind/emcc.rs | 8 +- src/libpanic_unwind/gcc.rs | 12 +- src/libpanic_unwind/lib.rs | 13 +- src/libpanic_unwind/seh.rs | 4 +- src/libpanic_unwind/seh64_gnu.rs | 4 +- src/libproc_macro/Cargo.toml | 1 + src/libproc_macro/bridge/buffer.rs | 6 +- src/libproc_macro/bridge/client.rs | 66 +- src/libproc_macro/bridge/mod.rs | 14 +- src/libproc_macro/bridge/rpc.rs | 24 +- src/libproc_macro/bridge/scoped_cell.rs | 4 +- src/libproc_macro/bridge/server.rs | 30 +- src/libproc_macro/diagnostic.rs | 20 +- src/libproc_macro/lib.rs | 52 +- src/libproc_macro/quote.rs | 36 +- src/libprofiler_builtins/Cargo.toml | 1 + src/libprofiler_builtins/build.rs | 2 - src/libprofiler_builtins/lib.rs | 1 + src/librustc/Cargo.toml | 6 +- src/librustc/cfg/construct.rs | 50 +- src/librustc/cfg/graphviz.rs | 6 +- src/librustc/cfg/mod.rs | 6 +- src/librustc/dep_graph/cgu_reuse_tracker.rs | 2 +- src/librustc/dep_graph/debug.rs | 2 +- src/librustc/dep_graph/dep_node.rs | 37 +- src/librustc/dep_graph/dep_tracking_map.rs | 4 +- src/librustc/dep_graph/graph.rs | 398 +- src/librustc/dep_graph/mod.rs | 2 +- src/librustc/dep_graph/prev.rs | 15 +- src/librustc/dep_graph/safe.rs | 6 +- src/librustc/dep_graph/serialized.rs | 4 +- src/librustc/diagnostics.rs | 85 +- src/librustc/hir/check_attr.rs | 64 +- src/librustc/hir/def.rs | 25 +- src/librustc/hir/def_id.rs | 8 +- src/librustc/hir/intravisit.rs | 235 +- src/librustc/hir/lowering.rs | 517 +- src/librustc/hir/map/blocks.rs | 14 +- src/librustc/hir/map/collector.rs | 144 +- src/librustc/hir/map/def_collector.rs | 19 +- src/librustc/hir/map/definitions.rs | 91 +- src/librustc/hir/map/hir_id_validator.rs | 59 +- src/librustc/hir/map/mod.rs | 285 +- src/librustc/hir/mod.rs | 560 +- src/librustc/hir/pat_util.rs | 35 +- src/librustc/hir/print.rs | 113 +- src/librustc/ich/hcx.rs | 18 +- src/librustc/ich/impls_cstore.rs | 18 +- src/librustc/ich/impls_hir.rs | 83 +- src/librustc/ich/impls_mir.rs | 11 +- src/librustc/ich/impls_misc.rs | 2 +- src/librustc/ich/impls_syntax.rs | 15 +- src/librustc/ich/impls_ty.rs | 79 +- src/librustc/infer/at.rs | 26 +- src/librustc/infer/canonical/canonicalizer.rs | 20 +- src/librustc/infer/canonical/mod.rs | 22 +- .../infer/canonical/query_response.rs | 30 +- src/librustc/infer/canonical/substitute.rs | 8 +- src/librustc/infer/combine.rs | 24 +- src/librustc/infer/equate.rs | 10 +- src/librustc/infer/error_reporting/mod.rs | 104 +- .../infer/error_reporting/need_type_info.rs | 16 +- .../nice_region_error/different_lifetimes.rs | 14 +- .../nice_region_error/find_anon_type.rs | 25 +- .../error_reporting/nice_region_error/mod.rs | 32 +- .../nice_region_error/named_anon_conflict.rs | 41 +- .../nice_region_error/outlives_closure.rs | 18 +- .../nice_region_error/placeholder_error.rs | 435 +- .../nice_region_error/static_impl_trait.rs | 20 +- .../error_reporting/nice_region_error/util.rs | 24 +- src/librustc/infer/error_reporting/note.rs | 14 +- src/librustc/infer/freshen.rs | 6 +- src/librustc/infer/fudge.rs | 10 +- src/librustc/infer/glb.rs | 6 +- src/librustc/infer/higher_ranked/README.md | 407 +- src/librustc/infer/higher_ranked/mod.rs | 13 +- src/librustc/infer/lattice.rs | 12 +- .../infer/lexical_region_resolve/README.md | 4 + .../infer/lexical_region_resolve/graphviz.rs | 14 +- .../infer/lexical_region_resolve/mod.rs | 88 +- src/librustc/infer/lub.rs | 6 +- src/librustc/infer/mod.rs | 88 +- src/librustc/infer/nll_relate/mod.rs | 16 +- src/librustc/infer/opaque_types/mod.rs | 51 +- src/librustc/infer/outlives/env.rs | 20 +- .../infer/outlives/free_region_map.rs | 4 +- src/librustc/infer/outlives/obligations.rs | 22 +- src/librustc/infer/outlives/verify.rs | 22 +- .../infer/region_constraints/README.md | 76 +- src/librustc/infer/region_constraints/mod.rs | 93 +- src/librustc/infer/resolve.rs | 4 +- src/librustc/infer/sub.rs | 10 +- src/librustc/infer/type_variable.rs | 18 +- src/librustc/infer/unify_key.rs | 2 +- src/librustc/lib.rs | 43 +- src/librustc/lint/builtin.rs | 78 +- src/librustc/lint/context.rs | 407 +- src/librustc/lint/levels.rs | 43 +- src/librustc/lint/mod.rs | 265 +- src/librustc/macros.rs | 66 +- src/librustc/middle/borrowck.rs | 6 +- src/librustc/middle/cstore.rs | 12 +- src/librustc/middle/dead.rs | 32 +- src/librustc/middle/dependency_format.rs | 12 +- src/librustc/middle/entry.rs | 87 +- src/librustc/middle/exported_symbols.rs | 8 +- src/librustc/middle/expr_use_visitor.rs | 50 +- src/librustc/middle/free_region.rs | 30 +- src/librustc/middle/intrinsicck.rs | 34 +- src/librustc/middle/lang_items.rs | 16 +- src/librustc/middle/lib_features.rs | 10 +- src/librustc/middle/liveness.rs | 270 +- src/librustc/middle/mem_categorization.rs | 58 +- src/librustc/middle/privacy.rs | 21 +- src/librustc/middle/reachable.rs | 39 +- src/librustc/middle/recursion_limit.rs | 15 +- src/librustc/middle/region.rs | 109 +- src/librustc/middle/resolve_lifetime.rs | 225 +- src/librustc/middle/stability.rs | 169 +- src/librustc/middle/weak_lang_items.rs | 16 +- src/librustc/mir/cache.rs | 6 +- src/librustc/mir/interpret/allocation.rs | 24 +- src/librustc/mir/interpret/error.rs | 18 +- src/librustc/mir/interpret/mod.rs | 59 +- src/librustc/mir/interpret/pointer.rs | 6 +- src/librustc/mir/interpret/value.rs | 47 +- src/librustc/mir/mod.rs | 153 +- src/librustc/mir/mono.rs | 10 +- src/librustc/mir/tcx.rs | 27 +- src/librustc/mir/visit.rs | 469 +- src/librustc/session/config.rs | 167 +- src/librustc/session/filesearch.rs | 2 +- src/librustc/session/mod.rs | 94 +- src/librustc/session/search_paths.rs | 4 +- src/librustc/traits/auto_trait.rs | 16 +- src/librustc/traits/chalk_fulfill.rs | 10 +- src/librustc/traits/codegen/mod.rs | 16 +- src/librustc/traits/coherence.rs | 30 +- src/librustc/traits/engine.rs | 8 +- src/librustc/traits/error_reporting.rs | 73 +- src/librustc/traits/fulfill.rs | 14 +- src/librustc/traits/mod.rs | 116 +- src/librustc/traits/object_safety.rs | 52 +- src/librustc/traits/on_unimplemented.rs | 23 +- src/librustc/traits/project.rs | 39 +- src/librustc/traits/query/dropck_outlives.rs | 12 +- .../traits/query/evaluate_obligation.rs | 6 +- src/librustc/traits/query/method_autoderef.rs | 4 +- src/librustc/traits/query/mod.rs | 6 +- src/librustc/traits/query/normalize.rs | 20 +- .../traits/query/normalize_erasing_regions.rs | 6 +- src/librustc/traits/query/outlives_bounds.rs | 20 +- .../traits/query/type_op/ascribe_user_type.rs | 23 +- src/librustc/traits/query/type_op/custom.rs | 10 +- src/librustc/traits/query/type_op/eq.rs | 6 +- .../query/type_op/implied_outlives_bounds.rs | 8 +- src/librustc/traits/query/type_op/mod.rs | 12 +- .../traits/query/type_op/normalize.rs | 10 +- src/librustc/traits/query/type_op/outlives.rs | 10 +- .../traits/query/type_op/prove_predicate.rs | 6 +- src/librustc/traits/query/type_op/subtype.rs | 6 +- src/librustc/traits/select.rs | 191 +- src/librustc/traits/specialize/mod.rs | 22 +- .../traits/specialize/specialization_graph.rs | 20 +- src/librustc/traits/structural_impls.rs | 39 +- src/librustc/traits/util.rs | 20 +- src/librustc/ty/_match.rs | 6 +- src/librustc/ty/adjustment.rs | 30 +- src/librustc/ty/binding.rs | 6 +- src/librustc/ty/cast.rs | 2 +- src/librustc/ty/codec.rs | 14 +- src/librustc/ty/constness.rs | 12 +- src/librustc/ty/context.rs | 244 +- src/librustc/ty/erase_regions.rs | 9 +- src/librustc/ty/error.rs | 8 +- src/librustc/ty/fast_reject.rs | 6 +- src/librustc/ty/flags.rs | 4 +- src/librustc/ty/fold.rs | 77 +- .../ty/inhabitedness/def_id_forest.rs | 14 +- src/librustc/ty/inhabitedness/mod.rs | 10 +- src/librustc/ty/instance.rs | 29 +- src/librustc/ty/item_path.rs | 54 +- src/librustc/ty/layout.rs | 28 +- src/librustc/ty/mod.rs | 269 +- src/librustc/ty/outlives.rs | 2 +- src/librustc/ty/query/README.md | 303 +- src/librustc/ty/query/config.rs | 135 +- src/librustc/ty/query/job.rs | 107 +- src/librustc/ty/query/keys.rs | 14 +- src/librustc/ty/query/mod.rs | 185 +- src/librustc/ty/query/on_disk_cache.rs | 53 +- src/librustc/ty/query/plumbing.rs | 451 +- src/librustc/ty/query/values.rs | 14 +- src/librustc/ty/relate.rs | 32 +- src/librustc/ty/steal.rs | 6 +- src/librustc/ty/structural_impls.rs | 60 +- src/librustc/ty/sty.rs | 136 +- src/librustc/ty/subst.rs | 32 +- src/librustc/ty/trait_def.rs | 22 +- src/librustc/ty/util.rs | 103 +- src/librustc/ty/walk.rs | 2 +- src/librustc/ty/wf.rs | 26 +- src/librustc/util/bug.rs | 2 +- src/librustc/util/common.rs | 14 +- src/librustc/util/nodemap.rs | 6 +- src/librustc/util/ppaux.rs | 70 +- src/librustc/util/profiling.rs | 567 +- src/librustc_allocator/Cargo.toml | 1 + src/librustc_allocator/expand.rs | 39 +- src/librustc_allocator/lib.rs | 10 +- src/librustc_apfloat/Cargo.toml | 1 + src/librustc_apfloat/ieee.rs | 28 +- src/librustc_apfloat/lib.rs | 42 +- src/librustc_apfloat/ppc.rs | 6 +- src/librustc_apfloat/tests/ieee.rs | 4 +- src/librustc_apfloat/tests/ppc.rs | 2 - src/librustc_asan/Cargo.toml | 1 + src/librustc_asan/build.rs | 5 +- src/librustc_asan/lib.rs | 2 + src/librustc_borrowck/Cargo.toml | 9 +- src/librustc_borrowck/borrowck/check_loans.rs | 13 +- .../borrowck/gather_loans/gather_moves.rs | 11 +- .../borrowck/gather_loans/lifetime.rs | 5 +- .../borrowck/gather_loans/mod.rs | 31 +- .../borrowck/gather_loans/move_error.rs | 14 +- .../borrowck/gather_loans/restrictions.rs | 5 +- src/librustc_borrowck/borrowck/mod.rs | 92 +- src/librustc_borrowck/borrowck/move_data.rs | 27 +- src/librustc_borrowck/borrowck/unused.rs | 7 +- src/librustc_borrowck/dataflow.rs | 18 +- src/librustc_borrowck/graphviz.rs | 13 +- src/librustc_borrowck/lib.rs | 16 +- src/librustc_codegen_llvm/Cargo.toml | 3 +- src/librustc_codegen_llvm/abi.rs | 16 +- src/librustc_codegen_llvm/allocator.rs | 8 +- src/librustc_codegen_llvm/asm.rs | 10 +- src/librustc_codegen_llvm/attributes.rs | 72 +- src/librustc_codegen_llvm/back/archive.rs | 13 +- src/librustc_codegen_llvm/back/link.rs | 22 +- src/librustc_codegen_llvm/back/lto.rs | 160 +- src/librustc_codegen_llvm/back/rpath.rs | 16 +- src/librustc_codegen_llvm/back/wasm.rs | 6 +- src/librustc_codegen_llvm/back/write.rs | 82 +- src/librustc_codegen_llvm/base.rs | 40 +- src/librustc_codegen_llvm/builder.rs | 19 +- src/librustc_codegen_llvm/callee.rs | 14 +- src/librustc_codegen_llvm/common.rs | 16 +- src/librustc_codegen_llvm/consts.rs | 26 +- src/librustc_codegen_llvm/context.rs | 116 +- .../debuginfo/create_scope_map.rs | 12 +- src/librustc_codegen_llvm/debuginfo/doc.rs | 4 +- src/librustc_codegen_llvm/debuginfo/gdb.rs | 12 +- .../debuginfo/metadata.rs | 28 +- src/librustc_codegen_llvm/debuginfo/mod.rs | 46 +- .../debuginfo/namespace.rs | 8 +- .../debuginfo/source_loc.rs | 6 +- .../debuginfo/type_names.rs | 6 +- src/librustc_codegen_llvm/debuginfo/utils.rs | 14 +- src/librustc_codegen_llvm/declare.rs | 27 +- src/librustc_codegen_llvm/intrinsic.rs | 179 +- src/librustc_codegen_llvm/lib.rs | 85 +- src/librustc_codegen_llvm/llvm/archive_ro.rs | 2 +- src/librustc_codegen_llvm/llvm/diagnostic.rs | 2 +- src/librustc_codegen_llvm/llvm/ffi.rs | 83 +- src/librustc_codegen_llvm/llvm/mod.rs | 2 +- src/librustc_codegen_llvm/llvm_util.rs | 21 +- src/librustc_codegen_llvm/metadata.rs | 6 +- src/librustc_codegen_llvm/mono_item.rs | 12 +- src/librustc_codegen_llvm/type_.rs | 19 +- src/librustc_codegen_llvm/type_of.rs | 10 +- src/librustc_codegen_llvm/va_arg.rs | 8 +- src/librustc_codegen_llvm/value.rs | 6 +- src/librustc_codegen_ssa/Cargo.toml | 1 + src/librustc_codegen_ssa/back/command.rs | 2 +- src/librustc_codegen_ssa/back/link.rs | 3 +- src/librustc_codegen_ssa/back/linker.rs | 167 +- src/librustc_codegen_ssa/back/lto.rs | 4 +- .../back/symbol_export.rs | 12 +- src/librustc_codegen_ssa/back/write.rs | 138 +- src/librustc_codegen_ssa/base.rs | 99 +- src/librustc_codegen_ssa/callee.rs | 2 +- src/librustc_codegen_ssa/common.rs | 10 +- src/librustc_codegen_ssa/glue.rs | 8 +- src/librustc_codegen_ssa/lib.rs | 34 +- src/librustc_codegen_ssa/meth.rs | 4 +- src/librustc_codegen_ssa/mir/analyze.rs | 2 +- src/librustc_codegen_ssa/mir/block.rs | 12 +- src/librustc_codegen_ssa/mir/constant.rs | 3 +- src/librustc_codegen_ssa/mir/mod.rs | 15 +- src/librustc_codegen_ssa/mir/operand.rs | 26 +- src/librustc_codegen_ssa/mir/place.rs | 41 +- src/librustc_codegen_ssa/mir/rvalue.rs | 10 +- src/librustc_codegen_ssa/mir/statement.rs | 4 +- src/librustc_codegen_ssa/mono_item.rs | 12 +- src/librustc_codegen_ssa/traits/asm.rs | 2 +- src/librustc_codegen_ssa/traits/backend.rs | 14 +- src/librustc_codegen_ssa/traits/builder.rs | 11 +- src/librustc_codegen_ssa/traits/consts.rs | 2 +- src/librustc_codegen_ssa/traits/debuginfo.rs | 6 +- src/librustc_codegen_ssa/traits/declare.rs | 6 +- src/librustc_codegen_ssa/traits/intrinsic.rs | 2 +- src/librustc_codegen_ssa/traits/type_.rs | 8 +- src/librustc_codegen_ssa/traits/write.rs | 13 +- src/librustc_codegen_utils/Cargo.toml | 1 + src/librustc_codegen_utils/codegen_backend.rs | 26 +- src/librustc_codegen_utils/lib.rs | 27 +- src/librustc_codegen_utils/link.rs | 2 +- src/librustc_codegen_utils/symbol_names.rs | 131 +- src/librustc_cratesio_shim/Cargo.toml | 1 + src/librustc_cratesio_shim/src/lib.rs | 2 + src/librustc_data_structures/Cargo.toml | 7 +- src/librustc_data_structures/base_n.rs | 2 +- src/librustc_data_structures/bit_set.rs | 48 +- src/librustc_data_structures/fingerprint.rs | 4 +- src/librustc_data_structures/flock.rs | 13 - .../graph/dominators/mod.rs | 8 +- .../graph/implementation/mod.rs | 30 +- .../graph/implementation/tests.rs | 2 +- src/librustc_data_structures/graph/scc/mod.rs | 10 +- .../graph/scc/test.rs | 2 +- src/librustc_data_structures/graph/test.rs | 2 +- src/librustc_data_structures/indexed_vec.rs | 18 +- src/librustc_data_structures/lib.rs | 23 +- src/librustc_data_structures/macros.rs | 3 +- .../obligation_forest/README.md | 81 - .../obligation_forest/graphviz.rs | 18 +- .../obligation_forest/mod.rs | 107 +- .../owning_ref/mod.rs | 20 +- src/librustc_data_structures/ptr_key.rs | 2 +- src/librustc_data_structures/sip128.rs | 4 +- .../snapshot_map/mod.rs | 2 +- src/librustc_data_structures/sorted_map.rs | 2 +- src/librustc_data_structures/stable_hasher.rs | 10 +- src/librustc_data_structures/svh.rs | 6 +- src/librustc_data_structures/sync.rs | 111 +- src/librustc_data_structures/thin_vec.rs | 9 + src/librustc_data_structures/tiny_list.rs | 2 +- .../transitive_relation.rs | 22 +- .../vec_linked_list.rs | 2 +- src/librustc_data_structures/work_queue.rs | 10 +- src/librustc_driver/driver.rs | 245 +- src/librustc_driver/lib.rs | 42 +- src/librustc_driver/pretty.rs | 61 +- src/librustc_driver/test.rs | 12 +- src/librustc_errors/Cargo.toml | 1 + src/librustc_errors/diagnostic.rs | 169 +- src/librustc_errors/diagnostic_builder.rs | 187 +- src/librustc_errors/emitter.rs | 122 +- src/librustc_errors/lib.rs | 90 +- src/librustc_errors/snippet.rs | 2 +- src/librustc_errors/styled_buffer.rs | 2 +- src/librustc_fs_util/Cargo.toml | 1 + src/librustc_fs_util/lib.rs | 4 +- src/librustc_incremental/Cargo.toml | 1 + src/librustc_incremental/assert_dep_graph.rs | 20 +- src/librustc_incremental/lib.rs | 15 +- .../persist/dirty_clean.rs | 33 +- .../persist/file_format.rs | 6 +- src/librustc_incremental/persist/fs.rs | 4 +- src/librustc_incremental/persist/load.rs | 1 - src/librustc_incremental/persist/mod.rs | 26 +- src/librustc_incremental/persist/save.rs | 4 +- .../persist/work_product.rs | 2 +- src/librustc_lint/Cargo.toml | 2 +- src/librustc_lint/builtin.rs | 379 +- src/librustc_lint/diagnostics.rs | 2 + src/librustc_lint/lib.rs | 134 +- src/librustc_lint/nonstandard_style.rs | 221 +- src/librustc_lint/types.rs | 59 +- src/librustc_lint/unused.rs | 79 +- src/librustc_llvm/Cargo.toml | 1 + src/librustc_llvm/build.rs | 7 +- src/librustc_llvm/lib.rs | 5 +- src/librustc_lsan/Cargo.toml | 1 + src/librustc_lsan/build.rs | 5 +- src/librustc_lsan/lib.rs | 2 + src/librustc_metadata/Cargo.toml | 3 +- src/librustc_metadata/creader.rs | 23 +- src/librustc_metadata/cstore.rs | 10 +- src/librustc_metadata/cstore_impl.rs | 24 +- src/librustc_metadata/decoder.rs | 58 +- src/librustc_metadata/diagnostics.rs | 4 +- src/librustc_metadata/dynamic_lib.rs | 4 +- src/librustc_metadata/encoder.rs | 64 +- src/librustc_metadata/index.rs | 7 +- src/librustc_metadata/index_builder.rs | 36 +- src/librustc_metadata/isolated_encoder.rs | 4 +- src/librustc_metadata/lib.rs | 20 +- src/librustc_metadata/locator.rs | 17 +- src/librustc_metadata/native_libs.rs | 3 +- src/librustc_metadata/schema.rs | 17 +- src/librustc_mir/Cargo.toml | 4 +- src/librustc_mir/borrow_check/borrow_set.rs | 66 +- .../borrow_check/error_reporting.rs | 139 +- src/librustc_mir/borrow_check/flows.rs | 18 +- src/librustc_mir/borrow_check/mod.rs | 95 +- src/librustc_mir/borrow_check/move_errors.rs | 23 +- .../borrow_check/mutability_errors.rs | 23 +- .../borrow_check/nll/constraint_generation.rs | 21 +- .../borrow_check/nll/constraints/graph.rs | 10 +- .../borrow_check/nll/constraints/mod.rs | 8 +- .../nll/explain_borrow/find_use.rs | 11 +- .../borrow_check/nll/explain_borrow/mod.rs | 471 +- src/librustc_mir/borrow_check/nll/facts.rs | 6 +- .../borrow_check/nll/invalidation.rs | 49 +- src/librustc_mir/borrow_check/nll/mod.rs | 44 +- .../borrow_check/nll/region_infer/dump_mir.rs | 2 +- .../nll/region_infer/error_reporting/mod.rs | 27 +- .../error_reporting/region_name.rs | 37 +- .../region_infer/error_reporting/var_name.rs | 11 +- .../borrow_check/nll/region_infer/graphviz.rs | 3 +- .../borrow_check/nll/region_infer/mod.rs | 208 +- .../borrow_check/nll/region_infer/values.rs | 18 +- src/librustc_mir/borrow_check/nll/renumber.rs | 26 +- .../nll/type_check/constraint_conversion.rs | 10 +- .../nll/type_check/free_region_relations.rs | 118 +- .../nll/type_check/input_output.rs | 2 +- .../nll/type_check/liveness/liveness_map.rs | 8 +- .../nll/type_check/liveness/local_use_map.rs | 6 +- .../nll/type_check/liveness/mod.rs | 20 +- .../nll/type_check/liveness/trace.rs | 30 +- .../borrow_check/nll/type_check/mod.rs | 401 +- .../borrow_check/nll/type_check/relate_tys.rs | 6 +- .../borrow_check/nll/universal_regions.rs | 40 +- src/librustc_mir/borrow_check/path_utils.rs | 12 +- src/librustc_mir/borrow_check/place_ext.rs | 4 +- .../borrow_check/places_conflict.rs | 10 +- src/librustc_mir/borrow_check/used_muts.rs | 2 +- src/librustc_mir/build/block.rs | 14 +- src/librustc_mir/build/cfg.rs | 2 +- src/librustc_mir/build/expr/as_constant.rs | 13 +- src/librustc_mir/build/expr/as_operand.rs | 6 +- src/librustc_mir/build/expr/as_place.rs | 22 +- src/librustc_mir/build/expr/as_rvalue.rs | 15 +- src/librustc_mir/build/expr/as_temp.rs | 4 +- src/librustc_mir/build/expr/category.rs | 2 +- src/librustc_mir/build/expr/into.rs | 10 +- src/librustc_mir/build/expr/stmt.rs | 6 +- src/librustc_mir/build/into.rs | 6 +- src/librustc_mir/build/matches/mod.rs | 1098 ++-- src/librustc_mir/build/matches/simplify.rs | 20 +- src/librustc_mir/build/matches/test.rs | 289 +- src/librustc_mir/build/matches/util.rs | 9 +- src/librustc_mir/build/misc.rs | 4 +- src/librustc_mir/build/mod.rs | 118 +- src/librustc_mir/build/scope.rs | 11 +- src/librustc_mir/const_eval.rs | 231 +- src/librustc_mir/dataflow/at_location.rs | 12 +- .../dataflow/drop_flag_effects.rs | 6 +- src/librustc_mir/dataflow/graphviz.rs | 26 +- .../dataflow/impls/borrowed_locals.rs | 6 +- src/librustc_mir/dataflow/impls/borrows.rs | 26 +- src/librustc_mir/dataflow/impls/mod.rs | 31 +- .../dataflow/impls/storage_liveness.rs | 6 +- src/librustc_mir/dataflow/mod.rs | 38 +- .../dataflow/move_paths/abs_domain.rs | 10 +- src/librustc_mir/dataflow/move_paths/mod.rs | 19 +- src/librustc_mir/diagnostics.rs | 119 +- src/librustc_mir/hair/constant.rs | 13 +- src/librustc_mir/hair/cx/block.rs | 96 +- src/librustc_mir/hair/cx/expr.rs | 30 +- src/librustc_mir/hair/cx/mod.rs | 23 +- src/librustc_mir/hair/cx/to_ref.rs | 2 +- src/librustc_mir/hair/mod.rs | 14 +- src/librustc_mir/hair/pattern/_match.rs | 124 +- src/librustc_mir/hair/pattern/check_match.rs | 69 +- src/librustc_mir/hair/pattern/mod.rs | 248 +- src/librustc_mir/hair/util.rs | 8 +- src/librustc_mir/interpret/cast.rs | 10 +- src/librustc_mir/interpret/eval_context.rs | 133 +- src/librustc_mir/interpret/intrinsics.rs | 53 +- src/librustc_mir/interpret/machine.rs | 34 +- src/librustc_mir/interpret/memory.rs | 14 +- src/librustc_mir/interpret/mod.rs | 2 +- src/librustc_mir/interpret/operand.rs | 153 +- src/librustc_mir/interpret/operator.rs | 73 +- src/librustc_mir/interpret/place.rs | 76 +- src/librustc_mir/interpret/snapshot.rs | 50 +- src/librustc_mir/interpret/step.rs | 12 +- src/librustc_mir/interpret/terminator.rs | 28 +- src/librustc_mir/interpret/traits.rs | 8 +- src/librustc_mir/interpret/validity.rs | 40 +- src/librustc_mir/interpret/visitor.rs | 30 +- src/librustc_mir/lib.rs | 34 +- src/librustc_mir/lints.rs | 2 +- src/librustc_mir/monomorphize/collector.rs | 53 +- src/librustc_mir/monomorphize/item.rs | 65 +- src/librustc_mir/monomorphize/partitioning.rs | 28 +- src/librustc_mir/shim.rs | 37 +- src/librustc_mir/transform/add_call_guards.rs | 6 +- .../transform/add_moves_for_packed_drops.rs | 10 +- src/librustc_mir/transform/add_retag.rs | 4 +- src/librustc_mir/transform/check_unsafety.rs | 111 +- .../transform/cleanup_post_borrowck.rs | 101 +- src/librustc_mir/transform/const_prop.rs | 84 +- src/librustc_mir/transform/copy_prop.rs | 8 +- src/librustc_mir/transform/deaggregator.rs | 4 +- src/librustc_mir/transform/dump_mir.rs | 10 +- src/librustc_mir/transform/elaborate_drops.rs | 32 +- src/librustc_mir/transform/erase_regions.rs | 8 +- src/librustc_mir/transform/generator.rs | 79 +- src/librustc_mir/transform/inline.rs | 68 +- src/librustc_mir/transform/instcombine.rs | 4 +- src/librustc_mir/transform/lower_128bit.rs | 7 +- src/librustc_mir/transform/mod.rs | 51 +- src/librustc_mir/transform/no_landing_pads.rs | 4 +- src/librustc_mir/transform/promote_consts.rs | 5 +- src/librustc_mir/transform/qualify_consts.rs | 1437 +++-- .../transform/qualify_min_const_fn.rs | 12 +- .../transform/remove_noop_landing_pads.rs | 12 +- src/librustc_mir/transform/rustc_peek.rs | 26 +- src/librustc_mir/transform/simplify.rs | 10 +- .../transform/simplify_branches.rs | 4 +- .../transform/uniform_array_move_out.rs | 8 +- src/librustc_mir/util/alignment.rs | 2 +- src/librustc_mir/util/borrowck_errors.rs | 6 +- src/librustc_mir/util/def_use.rs | 4 +- src/librustc_mir/util/elaborate_drops.rs | 16 +- src/librustc_mir/util/graphviz.rs | 11 +- src/librustc_mir/util/liveness.rs | 43 +- src/librustc_mir/util/patch.rs | 4 +- src/librustc_mir/util/pretty.rs | 137 +- src/librustc_msan/Cargo.toml | 1 + src/librustc_msan/build.rs | 5 +- src/librustc_msan/lib.rs | 2 + src/librustc_passes/Cargo.toml | 4 +- src/librustc_passes/ast_validation.rs | 539 +- src/librustc_passes/diagnostics.rs | 2 + src/librustc_passes/hir_stats.rs | 15 +- src/librustc_passes/layout_test.rs | 130 + src/librustc_passes/lib.rs | 18 +- src/librustc_passes/loops.rs | 10 +- src/librustc_passes/rvalue_promotion.rs | 63 +- src/librustc_plugin/Cargo.toml | 1 + src/librustc_plugin/build.rs | 2 +- src/librustc_plugin/diagnostics.rs | 2 + src/librustc_plugin/lib.rs | 15 +- src/librustc_plugin/load.rs | 14 +- src/librustc_plugin/registry.rs | 8 +- src/librustc_privacy/Cargo.toml | 4 +- src/librustc_privacy/lib.rs | 206 +- src/librustc_resolve/Cargo.toml | 3 +- src/librustc_resolve/build_reduced_graph.rs | 87 +- src/librustc_resolve/check_unused.rs | 209 +- src/librustc_resolve/diagnostics.rs | 6 +- src/librustc_resolve/error_reporting.rs | 441 +- src/librustc_resolve/lib.rs | 1085 ++-- src/librustc_resolve/macros.rs | 125 +- src/librustc_resolve/resolve_imports.rs | 71 +- src/librustc_save_analysis/Cargo.toml | 1 + src/librustc_save_analysis/dump_visitor.rs | 113 +- src/librustc_save_analysis/json_dumper.rs | 4 +- src/librustc_save_analysis/lib.rs | 56 +- src/librustc_save_analysis/sig.rs | 66 +- src/librustc_save_analysis/span_utils.rs | 2 +- src/librustc_target/Cargo.toml | 1 + src/librustc_target/abi/call/aarch64.rs | 6 +- src/librustc_target/abi/call/amdgpu.rs | 4 +- src/librustc_target/abi/call/arm.rs | 8 +- src/librustc_target/abi/call/asmjs.rs | 8 +- src/librustc_target/abi/call/hexagon.rs | 8 +- src/librustc_target/abi/call/mips.rs | 10 +- src/librustc_target/abi/call/mips64.rs | 6 +- src/librustc_target/abi/call/mod.rs | 103 +- src/librustc_target/abi/call/msp430.rs | 8 +- src/librustc_target/abi/call/nvptx.rs | 8 +- src/librustc_target/abi/call/nvptx64.rs | 8 +- src/librustc_target/abi/call/powerpc.rs | 10 +- src/librustc_target/abi/call/powerpc64.rs | 10 +- src/librustc_target/abi/call/riscv.rs | 8 +- src/librustc_target/abi/call/s390x.rs | 6 +- src/librustc_target/abi/call/sparc.rs | 10 +- src/librustc_target/abi/call/sparc64.rs | 6 +- src/librustc_target/abi/call/wasm32.rs | 8 +- src/librustc_target/abi/call/x86.rs | 8 +- src/librustc_target/abi/call/x86_64.rs | 4 +- src/librustc_target/abi/call/x86_win64.rs | 8 +- src/librustc_target/abi/mod.rs | 32 +- src/librustc_target/lib.rs | 12 +- src/librustc_target/spec/aarch64_apple_ios.rs | 2 +- src/librustc_target/spec/aarch64_fuchsia.rs | 2 +- .../spec/aarch64_linux_android.rs | 2 +- .../spec/aarch64_pc_windows_msvc.rs | 2 +- .../spec/aarch64_unknown_cloudabi.rs | 2 +- .../spec/aarch64_unknown_freebsd.rs | 2 +- .../spec/aarch64_unknown_hermit.rs | 2 +- .../spec/aarch64_unknown_linux_gnu.rs | 2 +- .../spec/aarch64_unknown_linux_musl.rs | 2 +- .../spec/aarch64_unknown_netbsd.rs | 2 +- .../spec/aarch64_unknown_none.rs | 1 + .../spec/aarch64_unknown_openbsd.rs | 2 +- src/librustc_target/spec/abi.rs | 2 +- src/librustc_target/spec/android_base.rs | 2 +- src/librustc_target/spec/apple_base.rs | 2 +- src/librustc_target/spec/apple_ios_base.rs | 4 +- src/librustc_target/spec/arm_base.rs | 2 +- .../spec/arm_linux_androideabi.rs | 2 +- .../spec/arm_unknown_linux_gnueabi.rs | 2 +- .../spec/arm_unknown_linux_gnueabihf.rs | 2 +- .../spec/arm_unknown_linux_musleabi.rs | 2 +- .../spec/arm_unknown_linux_musleabihf.rs | 2 +- .../spec/armebv7r_none_eabi.rs | 2 +- .../spec/armebv7r_none_eabihf.rs | 2 +- .../spec/armv4t_unknown_linux_gnueabi.rs | 2 +- .../spec/armv5te_unknown_linux_gnueabi.rs | 2 +- .../spec/armv5te_unknown_linux_musleabi.rs | 2 +- .../spec/armv6_unknown_netbsd_eabihf.rs | 2 +- src/librustc_target/spec/armv7_apple_ios.rs | 2 +- .../spec/armv7_linux_androideabi.rs | 2 +- .../spec/armv7_unknown_cloudabi_eabihf.rs | 2 +- .../spec/armv7_unknown_linux_gnueabihf.rs | 2 +- .../spec/armv7_unknown_linux_musleabihf.rs | 2 +- .../spec/armv7_unknown_netbsd_eabihf.rs | 2 +- src/librustc_target/spec/armv7r_none_eabi.rs | 2 +- .../spec/armv7r_none_eabihf.rs | 2 +- src/librustc_target/spec/armv7s_apple_ios.rs | 2 +- src/librustc_target/spec/bitrig_base.rs | 2 +- src/librustc_target/spec/cloudabi_base.rs | 2 +- src/librustc_target/spec/dragonfly_base.rs | 2 +- src/librustc_target/spec/freebsd_base.rs | 2 +- src/librustc_target/spec/fuchsia_base.rs | 2 +- src/librustc_target/spec/haiku_base.rs | 2 +- src/librustc_target/spec/hermit_base.rs | 2 +- src/librustc_target/spec/i386_apple_ios.rs | 2 +- .../spec/i586_pc_windows_msvc.rs | 2 +- .../spec/i586_unknown_linux_gnu.rs | 2 +- .../spec/i586_unknown_linux_musl.rs | 2 +- src/librustc_target/spec/i686_apple_darwin.rs | 2 +- .../spec/i686_linux_android.rs | 2 +- .../spec/i686_pc_windows_gnu.rs | 2 +- .../spec/i686_pc_windows_msvc.rs | 2 +- .../spec/i686_unknown_cloudabi.rs | 2 +- .../spec/i686_unknown_dragonfly.rs | 2 +- .../spec/i686_unknown_freebsd.rs | 2 +- .../spec/i686_unknown_haiku.rs | 2 +- .../spec/i686_unknown_linux_gnu.rs | 2 +- .../spec/i686_unknown_linux_musl.rs | 2 +- .../spec/i686_unknown_netbsd.rs | 2 +- .../spec/i686_unknown_openbsd.rs | 2 +- src/librustc_target/spec/l4re_base.rs | 2 +- src/librustc_target/spec/linux_base.rs | 2 +- src/librustc_target/spec/linux_musl_base.rs | 2 +- .../spec/mips64_unknown_linux_gnuabi64.rs | 2 +- .../spec/mips64el_unknown_linux_gnuabi64.rs | 2 +- .../spec/mips_unknown_linux_gnu.rs | 2 +- .../spec/mips_unknown_linux_musl.rs | 2 +- .../spec/mips_unknown_linux_uclibc.rs | 2 +- .../spec/mipsel_unknown_linux_gnu.rs | 2 +- .../spec/mipsel_unknown_linux_musl.rs | 2 +- .../spec/mipsel_unknown_linux_uclibc.rs | 2 +- src/librustc_target/spec/mod.rs | 109 +- src/librustc_target/spec/msp430_none_elf.rs | 2 +- src/librustc_target/spec/netbsd_base.rs | 2 +- .../spec/nvptx64_nvidia_cuda.rs | 73 + src/librustc_target/spec/openbsd_base.rs | 2 +- .../spec/powerpc64_unknown_freebsd.rs | 22 + .../spec/powerpc64_unknown_linux_gnu.rs | 2 +- .../spec/powerpc64_unknown_linux_musl.rs | 2 +- .../spec/powerpc64le_unknown_linux_gnu.rs | 2 +- .../spec/powerpc64le_unknown_linux_musl.rs | 2 +- .../spec/powerpc_unknown_linux_gnu.rs | 2 +- .../spec/powerpc_unknown_linux_gnuspe.rs | 2 +- .../spec/powerpc_unknown_linux_musl.rs | 2 +- .../spec/powerpc_unknown_netbsd.rs | 2 +- src/librustc_target/spec/redox_base.rs | 2 +- .../spec/riscv32imac_unknown_none_elf.rs | 4 +- .../spec/riscv32imc_unknown_none_elf.rs | 2 +- .../spec/riscv64gc_unknown_none_elf.rs | 31 + .../spec/riscv64imac_unknown_none_elf.rs | 31 + src/librustc_target/spec/riscv_base.rs | 2 +- .../spec/s390x_unknown_linux_gnu.rs | 2 +- src/librustc_target/spec/solaris_base.rs | 2 +- .../spec/sparc64_unknown_linux_gnu.rs | 2 +- .../spec/sparc64_unknown_netbsd.rs | 2 +- .../spec/sparc_unknown_linux_gnu.rs | 2 +- .../spec/sparcv9_sun_solaris.rs | 2 +- src/librustc_target/spec/thumb_base.rs | 2 +- .../spec/thumbv6m_none_eabi.rs | 2 +- .../spec/thumbv7a_pc_windows_msvc.rs | 2 +- .../spec/thumbv7em_none_eabi.rs | 2 +- .../spec/thumbv7em_none_eabihf.rs | 2 +- .../spec/thumbv7m_none_eabi.rs | 2 +- .../spec/thumbv7neon_linux_androideabi.rs | 2 +- .../thumbv7neon_unknown_linux_gnueabihf.rs | 2 +- .../spec/thumbv8m_base_none_eabi.rs | 2 +- .../spec/thumbv8m_main_none_eabi.rs | 2 +- .../spec/thumbv8m_main_none_eabihf.rs | 2 +- src/librustc_target/spec/uefi_base.rs | 9 +- src/librustc_target/spec/windows_base.rs | 2 +- src/librustc_target/spec/windows_msvc_base.rs | 2 +- .../spec/x86_64_apple_darwin.rs | 2 +- src/librustc_target/spec/x86_64_apple_ios.rs | 2 +- src/librustc_target/spec/x86_64_fuchsia.rs | 2 +- .../spec/x86_64_linux_android.rs | 2 +- .../spec/x86_64_pc_windows_gnu.rs | 2 +- .../spec/x86_64_pc_windows_msvc.rs | 2 +- .../spec/x86_64_rumprun_netbsd.rs | 2 +- .../spec/x86_64_sun_solaris.rs | 2 +- .../spec/x86_64_unknown_bitrig.rs | 2 +- .../spec/x86_64_unknown_cloudabi.rs | 2 +- .../spec/x86_64_unknown_dragonfly.rs | 2 +- .../spec/x86_64_unknown_freebsd.rs | 2 +- .../spec/x86_64_unknown_haiku.rs | 2 +- .../spec/x86_64_unknown_hermit.rs | 2 +- .../spec/x86_64_unknown_l4re_uclibc.rs | 2 +- .../spec/x86_64_unknown_linux_gnu.rs | 2 +- .../spec/x86_64_unknown_linux_gnux32.rs | 2 +- .../spec/x86_64_unknown_linux_musl.rs | 2 +- .../spec/x86_64_unknown_netbsd.rs | 2 +- .../spec/x86_64_unknown_openbsd.rs | 2 +- .../spec/x86_64_unknown_redox.rs | 2 +- .../spec/x86_64_unknown_uefi.rs | 24 +- src/librustc_traits/Cargo.toml | 1 + src/librustc_traits/chalk_context/mod.rs | 18 +- .../chalk_context/program_clauses.rs | 6 +- src/librustc_traits/dropck_outlives.rs | 6 +- src/librustc_traits/evaluate_obligation.rs | 2 +- .../implied_outlives_bounds.rs | 6 +- src/librustc_traits/lib.rs | 10 +- src/librustc_traits/lowering/mod.rs | 9 +- .../normalize_erasing_regions.rs | 2 +- .../normalize_projection_ty.rs | 6 +- src/librustc_traits/type_op.rs | 49 +- src/librustc_tsan/Cargo.toml | 1 + src/librustc_tsan/build.rs | 5 +- src/librustc_tsan/lib.rs | 2 + src/librustc_typeck/Cargo.toml | 3 +- src/librustc_typeck/astconv.rs | 292 +- src/librustc_typeck/check/_match.rs | 48 +- src/librustc_typeck/check/autoderef.rs | 7 +- src/librustc_typeck/check/callee.rs | 12 +- src/librustc_typeck/check/cast.rs | 22 +- src/librustc_typeck/check/closure.rs | 14 +- src/librustc_typeck/check/coercion.rs | 117 +- src/librustc_typeck/check/compare_method.rs | 49 +- src/librustc_typeck/check/demand.rs | 120 +- src/librustc_typeck/check/dropck.rs | 29 +- .../check/generator_interior.rs | 2 +- src/librustc_typeck/check/intrinsic.rs | 13 +- src/librustc_typeck/check/method/confirm.rs | 10 +- src/librustc_typeck/check/method/mod.rs | 83 +- src/librustc_typeck/check/method/probe.rs | 26 +- src/librustc_typeck/check/method/suggest.rs | 86 +- src/librustc_typeck/check/mod.rs | 312 +- src/librustc_typeck/check/op.rs | 18 +- src/librustc_typeck/check/regionck.rs | 111 +- src/librustc_typeck/check/upvar.rs | 11 +- src/librustc_typeck/check/wfcheck.rs | 62 +- src/librustc_typeck/check/writeback.rs | 40 +- src/librustc_typeck/check_unused.rs | 8 +- src/librustc_typeck/coherence/builtin.rs | 26 +- .../coherence/inherent_impls_overlap.rs | 6 +- src/librustc_typeck/coherence/mod.rs | 33 +- src/librustc_typeck/coherence/orphan.rs | 2 +- src/librustc_typeck/collect.rs | 360 +- .../constrained_type_params.rs | 10 +- src/librustc_typeck/diagnostics.rs | 104 +- src/librustc_typeck/impl_wf_check.rs | 29 +- src/librustc_typeck/lib.rs | 79 +- src/librustc_typeck/outlives/explicit.rs | 2 +- .../outlives/implicit_infer.rs | 5 +- src/librustc_typeck/outlives/mod.rs | 2 +- src/librustc_typeck/structured_errors.rs | 4 +- src/librustc_typeck/variance/constraints.rs | 2 +- src/librustc_typeck/variance/mod.rs | 9 +- src/librustc_typeck/variance/solve.rs | 2 +- src/librustc_typeck/variance/terms.rs | 6 +- src/librustdoc/Cargo.toml | 5 +- src/librustdoc/clean/auto_trait.rs | 16 +- src/librustdoc/clean/blanket_impl.rs | 2 +- src/librustdoc/clean/cfg.rs | 22 +- src/librustdoc/clean/def_ctor.rs | 6 +- src/librustdoc/clean/inline.rs | 68 +- src/librustdoc/clean/mod.rs | 476 +- src/librustdoc/clean/simplify.rs | 18 +- src/librustdoc/config.rs | 46 +- src/librustdoc/core.rs | 46 +- src/librustdoc/doctree.rs | 44 +- src/librustdoc/externalfiles.rs | 5 +- src/librustdoc/fold.rs | 2 +- src/librustdoc/html/escape.rs | 6 +- src/librustdoc/html/format.rs | 142 +- src/librustdoc/html/highlight.rs | 98 +- src/librustdoc/html/item_type.rs | 39 +- src/librustdoc/html/layout.rs | 32 +- src/librustdoc/html/markdown.rs | 145 +- src/librustdoc/html/render.rs | 680 ++- src/librustdoc/html/static/favicon.ico | Bin 0 -> 23229 bytes src/librustdoc/html/static/main.js | 70 +- src/librustdoc/html/static/rust-logo.png | Bin 0 -> 5758 bytes src/librustdoc/html/static/rustdoc.css | 21 +- src/librustdoc/html/static/source-script.js | 4 +- src/librustdoc/html/static/themes/dark.css | 24 +- src/librustdoc/html/static/themes/light.css | 24 +- src/librustdoc/html/static_files.rs | 5 + src/librustdoc/html/toc.rs | 6 +- src/librustdoc/lib.rs | 24 +- src/librustdoc/markdown.rs | 18 +- .../passes/check_code_block_syntax.rs | 109 + src/librustdoc/passes/collapse_docs.rs | 9 +- .../passes/collect_intra_doc_links.rs | 172 +- src/librustdoc/passes/collect_trait_impls.rs | 11 +- src/librustdoc/passes/mod.rs | 128 +- .../passes/private_items_doc_tests.rs | 11 +- src/librustdoc/passes/propagate_doc_cfg.rs | 8 +- src/librustdoc/passes/strip_hidden.rs | 16 +- src/librustdoc/passes/strip_priv_imports.rs | 10 +- src/librustdoc/passes/strip_private.rs | 10 +- src/librustdoc/passes/unindent_comments.rs | 6 +- src/librustdoc/test.rs | 98 +- src/librustdoc/visit_ast.rs | 42 +- src/librustdoc/visit_lib.rs | 6 +- src/libserialize/Cargo.toml | 1 + src/libserialize/collection_impls.rs | 2 +- src/libserialize/hex.rs | 8 +- src/libserialize/json.rs | 1414 +---- src/libserialize/lib.rs | 12 +- src/libserialize/opaque.rs | 291 +- src/libserialize/serialize.rs | 4 +- src/libserialize/tests/json.rs | 1282 ++++ src/libserialize/tests/opaque.rs | 282 + src/libstd/Cargo.toml | 7 +- src/libstd/alloc.rs | 4 +- src/libstd/collections/hash/map.rs | 543 +- src/libstd/collections/hash/set.rs | 282 +- src/libstd/collections/hash/table.rs | 44 +- src/libstd/collections/mod.rs | 4 +- src/libstd/env.rs | 2 +- src/libstd/error.rs | 166 +- src/libstd/f64.rs | 2 +- src/libstd/ffi/c_str.rs | 6 +- src/libstd/ffi/mod.rs | 2 +- src/libstd/ffi/os_str.rs | 8 +- src/libstd/fs.rs | 85 +- src/libstd/future.rs | 24 +- src/libstd/io/buffered.rs | 43 +- src/libstd/io/cursor.rs | 219 +- src/libstd/io/impls.rs | 73 +- src/libstd/io/mod.rs | 142 +- src/libstd/io/stdio.rs | 59 +- src/libstd/io/util.rs | 18 +- src/libstd/keyword_docs.rs | 6 +- src/libstd/lib.rs | 99 +- src/libstd/macros.rs | 48 +- src/libstd/memchr.rs | 3 +- src/libstd/net/addr.rs | 8 +- src/libstd/net/ip.rs | 97 +- src/libstd/net/tcp.rs | 89 +- src/libstd/net/udp.rs | 12 +- src/libstd/num.rs | 2 + src/libstd/os/fortanix_sgx/mod.rs | 21 +- src/libstd/panic.rs | 12 +- src/libstd/path.rs | 137 +- src/libstd/prelude/mod.rs | 13 +- src/libstd/primitive_docs.rs | 4 +- src/libstd/process.rs | 14 +- src/libstd/sync/barrier.rs | 2 +- src/libstd/sync/condvar.rs | 10 +- src/libstd/sync/mpsc/blocking.rs | 6 +- src/libstd/sync/mpsc/mod.rs | 5 +- src/libstd/sync/mpsc/select.rs | 428 +- src/libstd/sync/mpsc/select_tests.rs | 413 ++ src/libstd/sync/mpsc/shared.rs | 2 +- src/libstd/sync/mutex.rs | 20 +- src/libstd/sync/once.rs | 8 +- src/libstd/sync/rwlock.rs | 30 +- src/libstd/sys/cloudabi/abi/cloudabi.rs | 18 +- src/libstd/sys/cloudabi/io.rs | 32 + src/libstd/sys/cloudabi/mod.rs | 36 +- src/libstd/sys/cloudabi/shims/net.rs | 10 +- src/libstd/sys/cloudabi/stdio.rs | 29 +- src/libstd/sys/mod.rs | 4 +- src/libstd/sys/redox/ext/fs.rs | 6 +- src/libstd/sys/redox/ext/net.rs | 6 +- src/libstd/sys/redox/ext/process.rs | 32 +- src/libstd/sys/redox/io.rs | 32 + src/libstd/sys/redox/memchr.rs | 3 +- src/libstd/sys/redox/mod.rs | 11 +- src/libstd/sys/redox/mutex.rs | 2 +- src/libstd/sys/redox/net/tcp.rs | 16 +- src/libstd/sys/redox/process.rs | 8 +- src/libstd/sys/redox/stdio.rs | 35 +- src/libstd/sys/redox/syscall/call.rs | 104 +- src/libstd/sys/redox/syscall/flag.rs | 16 +- src/libstd/sys/redox/thread_local.rs | 4 +- src/libstd/sys/sgx/abi/entry.S | 65 +- src/libstd/sys/sgx/abi/mod.rs | 2 +- src/libstd/sys/sgx/abi/panic.rs | 30 +- src/libstd/sys/sgx/abi/thread.rs | 2 +- src/libstd/sys/sgx/abi/tls.rs | 43 +- src/libstd/sys/sgx/abi/usercalls/alloc.rs | 58 +- src/libstd/sys/sgx/abi/usercalls/mod.rs | 3 +- src/libstd/sys/sgx/abi/usercalls/raw.rs | 92 +- src/libstd/sys/sgx/ext/arch.rs | 4 +- src/libstd/sys/sgx/ext/ffi.rs | 109 + src/libstd/sys/sgx/ext/mod.rs | 1 + src/libstd/sys/sgx/io.rs | 32 + src/libstd/sys/sgx/mod.rs | 54 +- src/libstd/sys/sgx/net.rs | 18 +- src/libstd/sys/sgx/rwlock.rs | 19 +- src/libstd/sys/sgx/stdio.rs | 31 +- src/libstd/sys/sgx/waitqueue.rs | 4 +- src/libstd/sys/unix/ext/fs.rs | 12 +- src/libstd/sys/unix/ext/mod.rs | 2 +- src/libstd/sys/unix/ext/net.rs | 45 +- src/libstd/sys/unix/ext/process.rs | 32 +- src/libstd/sys/unix/fast_thread_local.rs | 61 +- src/libstd/sys/unix/fd.rs | 20 +- src/libstd/sys/unix/io.rs | 61 + src/libstd/sys/unix/l4re.rs | 18 +- src/libstd/sys/unix/memchr.rs | 3 +- src/libstd/sys/unix/mod.rs | 9 +- src/libstd/sys/unix/net.rs | 10 +- src/libstd/sys/unix/pipe.rs | 4 +- src/libstd/sys/unix/process/process_common.rs | 6 +- src/libstd/sys/unix/process/process_unix.rs | 26 +- src/libstd/sys/unix/stdio.rs | 41 +- src/libstd/sys/unix/weak.rs | 15 +- src/libstd/sys/wasm/io.rs | 32 + src/libstd/sys/wasm/mod.rs | 12 +- src/libstd/sys/wasm/net.rs | 10 +- src/libstd/sys/wasm/stdio.rs | 33 +- src/libstd/sys/windows/c.rs | 25 + src/libstd/sys/windows/ext/ffi.rs | 16 +- src/libstd/sys/windows/ext/fs.rs | 4 +- src/libstd/sys/windows/ext/io.rs | 6 +- src/libstd/sys/windows/io.rs | 63 + src/libstd/sys/windows/memchr.rs | 5 +- src/libstd/sys/windows/mod.rs | 27 +- src/libstd/sys/windows/net.rs | 43 +- src/libstd/sys/windows/os.rs | 2 +- src/libstd/sys/windows/pipe.rs | 6 +- src/libstd/sys/windows/process.rs | 4 +- src/libstd/sys/windows/stdio.rs | 345 +- src/libstd/sys/windows/time.rs | 118 +- src/libstd/sys_common/backtrace.rs | 4 +- src/libstd/sys_common/bytestring.rs | 2 +- src/libstd/sys_common/mutex.rs | 2 +- src/libstd/sys_common/net.rs | 10 +- src/libstd/sys_common/remutex.rs | 8 +- src/libstd/sys_common/wtf8.rs | 10 +- src/libstd/tests/run-time-detect.rs | 100 + src/libstd/thread/local.rs | 16 +- src/libstd/thread/mod.rs | 4 +- src/libstd/time.rs | 90 +- src/libsyntax/Cargo.toml | 3 +- src/libsyntax/ast.rs | 180 +- src/libsyntax/attr/builtin.rs | 245 +- src/libsyntax/attr/mod.rs | 271 +- src/libsyntax/config.rs | 216 +- src/libsyntax/diagnostic_list.rs | 4 +- src/libsyntax/diagnostics/metadata.rs | 13 +- src/libsyntax/diagnostics/plugin.rs | 27 +- src/libsyntax/early_buffered_lints.rs | 5 +- src/libsyntax/entry.rs | 4 +- src/libsyntax/ext/base.rs | 201 +- src/libsyntax/ext/build.rs | 43 +- src/libsyntax/ext/derive.rs | 34 +- src/libsyntax/ext/expand.rs | 395 +- src/libsyntax/ext/placeholders.rs | 111 +- src/libsyntax/ext/quote.rs | 892 --- src/libsyntax/ext/source_util.rs | 43 +- src/libsyntax/ext/tt/macro_parser.rs | 78 +- src/libsyntax/ext/tt/macro_rules.rs | 171 +- src/libsyntax/ext/tt/quoted.rs | 37 +- src/libsyntax/ext/tt/transcribe.rs | 29 +- src/libsyntax/feature_gate.rs | 541 +- src/libsyntax/fold.rs | 1495 ----- src/libsyntax/json.rs | 13 +- src/libsyntax/lib.rs | 36 +- src/libsyntax/mut_visit.rs | 1334 ++++ src/libsyntax/parse/attr.rs | 40 +- src/libsyntax/parse/classify.rs | 2 +- src/libsyntax/parse/lexer/comments.rs | 35 +- src/libsyntax/parse/lexer/mod.rs | 105 +- src/libsyntax/parse/lexer/tokentrees.rs | 36 +- src/libsyntax/parse/lexer/unicode_chars.rs | 31 +- src/libsyntax/parse/mod.rs | 208 +- src/libsyntax/parse/parser.rs | 1670 +++-- src/libsyntax/parse/token.rs | 334 +- src/libsyntax/print/pp.rs | 7 +- src/libsyntax/print/pprust.rs | 118 +- src/libsyntax/ptr.rs | 46 +- src/libsyntax/show_span.rs | 7 +- src/libsyntax/source_map.rs | 24 +- src/libsyntax/std_inject.rs | 21 +- src/libsyntax/test.rs | 133 +- src/libsyntax/test_snippet.rs | 6 +- src/libsyntax/tokenstream.rs | 241 +- src/libsyntax/util/lev_distance.rs | 8 +- .../util/{move_map.rs => map_in_place.rs} | 29 +- src/libsyntax/util/node_count.rs | 6 +- src/libsyntax/util/parser.rs | 24 +- src/libsyntax/util/parser_testing.rs | 26 +- src/libsyntax/visit.rs | 17 +- src/libsyntax_ext/Cargo.toml | 3 +- src/libsyntax_ext/asm.rs | 9 +- src/libsyntax_ext/assert.rs | 3 +- src/libsyntax_ext/cfg.rs | 6 +- src/libsyntax_ext/compile_error.rs | 5 +- src/libsyntax_ext/concat.rs | 4 +- src/libsyntax_ext/concat_idents.rs | 5 +- src/libsyntax_ext/deriving/bounds.rs | 11 +- src/libsyntax_ext/deriving/clone.rs | 25 +- src/libsyntax_ext/deriving/cmp/eq.rs | 19 +- src/libsyntax_ext/deriving/cmp/ord.rs | 12 +- src/libsyntax_ext/deriving/cmp/partial_eq.rs | 18 +- src/libsyntax_ext/deriving/cmp/partial_ord.rs | 22 +- src/libsyntax_ext/deriving/custom.rs | 24 +- src/libsyntax_ext/deriving/debug.rs | 12 +- src/libsyntax_ext/deriving/decodable.rs | 24 +- src/libsyntax_ext/deriving/default.rs | 14 +- src/libsyntax_ext/deriving/encodable.rs | 22 +- src/libsyntax_ext/deriving/generic/mod.rs | 149 +- src/libsyntax_ext/deriving/generic/ty.rs | 41 +- src/libsyntax_ext/deriving/hash.rs | 10 +- src/libsyntax_ext/deriving/mod.rs | 13 +- src/libsyntax_ext/diagnostics.rs | 2 + src/libsyntax_ext/env.rs | 7 +- src/libsyntax_ext/format.rs | 48 +- src/libsyntax_ext/format_foreign.rs | 32 +- src/libsyntax_ext/global_asm.rs | 7 +- src/libsyntax_ext/lib.rs | 50 +- src/libsyntax_ext/log_syntax.rs | 2 +- src/libsyntax_ext/proc_macro_decls.rs | 104 +- src/libsyntax_ext/proc_macro_impl.rs | 26 +- src/libsyntax_ext/proc_macro_server.rs | 15 +- src/libsyntax_ext/test.rs | 35 +- src/libsyntax_ext/test_case.rs | 7 +- src/libsyntax_ext/trace_macros.rs | 5 +- src/libsyntax_pos/Cargo.toml | 1 + src/libsyntax_pos/analyze_source_file.rs | 6 +- src/libsyntax_pos/edition.rs | 2 +- src/libsyntax_pos/hygiene.rs | 21 +- src/libsyntax_pos/lib.rs | 104 +- src/libsyntax_pos/span_encoding.rs | 6 +- src/libsyntax_pos/symbol.rs | 65 +- src/libterm/Cargo.toml | 1 + src/libterm/lib.rs | 22 +- src/libterm/terminfo/mod.rs | 30 +- src/libterm/terminfo/parm.rs | 34 +- src/libterm/terminfo/parser/compiled.rs | 28 +- src/libterm/terminfo/searcher.rs | 4 +- src/libterm/win.rs | 11 +- src/libtest/Cargo.toml | 1 + src/libtest/formatters/json.rs | 2 +- src/libtest/lib.rs | 168 +- src/libtest/stats.rs | 6 +- src/libunwind/Cargo.toml | 1 + src/libunwind/lib.rs | 4 +- src/libunwind/libunwind.rs | 10 +- src/rustllvm/PassWrapper.cpp | 15 +- src/rustllvm/RustWrapper.cpp | 122 +- src/rustllvm/llvm-rebuild-trigger | 2 +- src/rustllvm/rustllvm.h | 2 + src/stage0.txt | 6 +- src/stdsimd/.travis.yml | 22 +- src/stdsimd/Cargo.toml | 4 +- src/stdsimd/README.md | 86 +- src/stdsimd/ci/android-install-sdk.sh | 12 +- src/stdsimd/ci/cross/nvptx64-nvidia-cuda.json | 15 - .../Dockerfile | 0 src/stdsimd/ci/dox.sh | 24 +- src/stdsimd/ci/run-docker.sh | 17 +- src/stdsimd/ci/run.sh | 82 +- src/stdsimd/coresimd/x86/adx.rs | 46 - src/stdsimd/coresimd/x86_64/adx.rs | 46 - .../crates/assert-instr-macro/src/lib.rs | 5 +- .../crates/{coresimd => core_arch}/Cargo.toml | 16 +- .../stdsimd/crates/core_arch}/LICENSE-APACHE | 0 .../stdsimd/crates/core_arch}/LICENSE-MIT | 2 +- src/stdsimd/crates/core_arch/README.md | 72 + src/stdsimd/crates/core_arch/build.rs | 3 + src/stdsimd/crates/core_arch/foo.wasm | Bin 0 -> 252 bytes .../core_arch/src}/aarch64/crc.rs | 4 +- .../core_arch/src}/aarch64/crypto.rs | 8 +- .../core_arch/src}/aarch64/mod.rs | 0 .../core_arch/src}/aarch64/neon.rs | 20 +- .../core_arch/src}/aarch64/v8.rs | 2 +- .../core_arch/src}/arm/armclang.rs | 0 .../core_arch/src}/arm/cmsis.rs | 0 .../core_arch/src}/arm/dsp.rs | 4 +- .../core_arch/src}/arm/mod.rs | 0 .../core_arch/src}/arm/neon.rs | 6 +- .../core_arch/src}/arm/table_lookup_tests.rs | 6 +- .../core_arch/src}/arm/v6.rs | 2 +- .../core_arch/src}/arm/v7.rs | 2 +- .../crates/core_arch/src/core_arch_docs.md | 345 ++ .../crates/{coresimd => core_arch}/src/lib.rs | 71 +- .../core_arch/src}/macros.rs | 0 .../core_arch/src}/mips/mod.rs | 0 .../core_arch/src}/mips/msa.rs | 2 +- .../{coresimd => crates/core_arch/src}/mod.rs | 64 +- .../core_arch/src}/nvptx/mod.rs | 0 .../core_arch/src}/powerpc/altivec.rs | 10 +- .../core_arch/src}/powerpc/mod.rs | 0 .../core_arch/src}/powerpc/vsx.rs | 10 +- .../core_arch/src}/powerpc64/mod.rs | 2 +- .../core_arch/src}/simd.rs | 10 +- .../core_arch/src}/simd_llvm.rs | 0 .../{coresimd => crates/core_arch/src}/v64.rs | 2 +- .../core_arch/src}/wasm32/atomic.rs | 0 .../core_arch/src}/wasm32/memory.rs | 0 .../core_arch/src}/wasm32/mod.rs | 0 .../core_arch/src}/wasm32/simd128.rs | 6 +- .../core_arch/src}/x86/abm.rs | 2 +- src/stdsimd/crates/core_arch/src/x86/adx.rs | 150 + .../core_arch/src}/x86/aes.rs | 4 +- .../core_arch/src}/x86/avx.rs | 18 +- .../core_arch/src}/x86/avx2.rs | 62 +- .../core_arch/src}/x86/avx512f.rs | 21 +- .../crates/core_arch/src/x86/avx512ifma.rs | 196 + .../core_arch/src}/x86/bmi1.rs | 2 +- .../core_arch/src}/x86/bmi2.rs | 4 +- .../core_arch/src}/x86/bswap.rs | 0 .../core_arch/src}/x86/cpuid.rs | 10 +- .../core_arch/src}/x86/eflags.rs | 2 +- .../core_arch/src}/x86/fma.rs | 4 +- .../core_arch/src}/x86/fxsr.rs | 2 +- .../core_arch/src}/x86/macros.rs | 0 .../core_arch/src}/x86/mmx.rs | 68 +- .../core_arch/src}/x86/mod.rs | 85 +- .../core_arch/src}/x86/pclmulqdq.rs | 4 +- .../core_arch/src}/x86/rdrand.rs | 4 +- .../core_arch/src}/x86/rdtsc.rs | 2 +- .../core_arch/src}/x86/sha.rs | 8 +- .../core_arch/src}/x86/sse.rs | 77 +- .../core_arch/src}/x86/sse2.rs | 14 +- .../core_arch/src}/x86/sse3.rs | 8 +- .../core_arch/src}/x86/sse41.rs | 37 +- .../core_arch/src}/x86/sse42.rs | 50 +- .../core_arch/src}/x86/sse4a.rs | 6 +- .../core_arch/src}/x86/ssse3.rs | 8 +- .../core_arch/src}/x86/tbm.rs | 2 +- .../core_arch/src}/x86/test.rs | 6 +- .../core_arch/src}/x86/xsave.rs | 4 +- .../core_arch/src}/x86_64/abm.rs | 2 +- .../crates/core_arch/src/x86_64/adx.rs | 149 + .../core_arch/src}/x86_64/avx.rs | 6 +- .../core_arch/src}/x86_64/avx2.rs | 6 +- .../core_arch/src}/x86_64/bmi.rs | 4 +- .../core_arch/src}/x86_64/bmi2.rs | 4 +- .../core_arch/src}/x86_64/bswap.rs | 2 +- .../core_arch/src}/x86_64/cmpxchg16b.rs | 4 +- .../core_arch/src}/x86_64/fxsr.rs | 2 +- .../core_arch/src}/x86_64/mod.rs | 0 .../core_arch/src}/x86_64/rdrand.rs | 3 +- .../core_arch/src}/x86_64/sse.rs | 4 +- .../core_arch/src}/x86_64/sse2.rs | 6 +- .../core_arch/src}/x86_64/sse41.rs | 6 +- .../core_arch/src}/x86_64/sse42.rs | 2 +- .../core_arch/src}/x86_64/xsave.rs | 4 +- .../tests/cpu-detection.rs | 2 +- src/stdsimd/crates/coresimd/build.rs | 6 - src/stdsimd/crates/simd-test-macro/src/lib.rs | 15 +- .../crates/{stdsimd => std_detect}/Cargo.toml | 26 +- .../stdsimd/crates/std_detect}/LICENSE-APACHE | 0 .../stdsimd/crates/std_detect}/LICENSE-MIT | 2 +- src/stdsimd/crates/std_detect/README.md | 85 + .../std_detect/src}/detect/arch/aarch64.rs | 29 +- .../std_detect/src}/detect/arch/arm.rs | 9 +- .../std_detect/src}/detect/arch/mips.rs | 7 +- .../std_detect/src}/detect/arch/mips64.rs | 7 +- .../std_detect/src}/detect/arch/powerpc.rs | 11 +- .../std_detect/src}/detect/arch/powerpc64.rs | 11 +- .../std_detect/src}/detect/arch/x86.rs | 169 +- .../std_detect/src}/detect/bit.rs | 0 .../std_detect/src}/detect/cache.rs | 12 +- .../std_detect/src}/detect/error_macros.rs | 0 .../std_detect/src}/detect/mod.rs | 2 +- .../std_detect/src}/detect/os/aarch64.rs | 3 +- .../src}/detect/os/freebsd/aarch64.rs | 3 +- .../std_detect/src}/detect/os/freebsd/mod.rs | 0 .../src}/detect/os/linux/aarch64.rs | 7 +- .../std_detect/src}/detect/os/linux/arm.rs | 7 +- .../std_detect/src}/detect/os/linux/auxvec.rs | 87 +- .../src}/detect/os/linux/cpuinfo.rs | 5 +- .../std_detect/src}/detect/os/linux/mips.rs | 4 +- .../std_detect/src}/detect/os/linux/mod.rs | 4 +- .../src}/detect/os/linux/powerpc.rs | 6 +- .../std_detect/src}/detect/os/other.rs | 2 +- .../std_detect/src}/detect/os/x86.rs | 12 +- .../src}/detect/test_data/linux-rpi3.auxv | Bin .../detect/test_data/linux-x64-i7-6850k.auxv | Bin .../macos-virtualbox-linux-x86-4850HQ.auxv | Bin src/stdsimd/crates/std_detect/src/lib.rs | 52 + src/stdsimd/crates/std_detect/src/mod.rs | 5 + .../tests/cpu-detection.rs | 2 +- .../std_detect/tests/macro_trailing_commas.rs | 55 + src/stdsimd/crates/stdsimd-test/src/lib.rs | 8 +- src/stdsimd/crates/stdsimd-test/src/wasm.rs | 4 +- src/stdsimd/crates/stdsimd-verify/Cargo.toml | 2 +- src/stdsimd/crates/stdsimd-verify/build.rs | 10 +- src/stdsimd/crates/stdsimd-verify/src/lib.rs | 4 +- .../crates/stdsimd-verify/tests/x86-intel.rs | 18 +- src/stdsimd/crates/stdsimd/src/lib.rs | 41 - src/stdsimd/examples/Cargo.toml | 27 + src/stdsimd/examples/hex.rs | 19 +- src/stdsimd/examples/wasm.rs | 4 +- src/stdsimd/stdsimd/mod.rs | 521 -- src/stdsimd/vendor.yml | 2 + src/test/codegen/align-enum.rs | 36 + src/test/codegen/box-maybe-uninit.rs | 3 + src/test/codegen/enum-debug-clike.rs | 5 +- src/test/codegen/ffi-returns-twice.rs | 12 + .../codegen/inline-always-works-always.rs | 21 + src/test/codegen/match.rs | 4 +- .../codegen/no-dllimport-w-cross-lang-lto.rs | 2 +- src/test/codegen/optimize-attr-1.rs | 50 + .../simd-intrinsic-float-abs.rs | 0 .../simd-intrinsic-float-ceil.rs | 0 .../simd-intrinsic-float-cos.rs | 0 .../simd-intrinsic-float-exp.rs | 0 .../simd-intrinsic-float-exp2.rs | 0 .../simd-intrinsic-float-floor.rs | 0 .../simd-intrinsic-float-fma.rs | 0 .../simd-intrinsic-float-fsqrt.rs | 0 .../simd-intrinsic-float-log.rs | 0 .../simd-intrinsic-float-log10.rs | 0 .../simd-intrinsic-float-log2.rs | 0 .../simd-intrinsic-float-minmax.rs | 0 .../simd-intrinsic-float-pow.rs | 0 .../simd-intrinsic-float-powi.rs | 0 .../simd-intrinsic-float-sin.rs | 0 ...intrinsic-generic-arithmetic-saturating.rs | 685 +++ .../simd-intrinsic-generic-bitmask.rs | 57 + .../simd-intrinsic-generic-gather.rs | 0 .../simd-intrinsic-generic-scatter.rs | 0 .../simd-intrinsic-generic-select.rs | 0 src/test/codegen/target-cpu-on-functions.rs | 2 +- .../auxiliary/lint_group_plugin_test.rs | 14 +- .../compile-fail/must_use-in-stdlib-traits.rs | 4 +- src/test/debuginfo/generators.rs | 36 + .../change_add_field/struct_point.rs | 18 +- .../incremental/hashes/call_expressions.rs | 16 +- .../incremental/hashes/closure_expressions.rs | 8 +- .../incremental/hashes/enum_constructors.rs | 28 +- .../incremental/hashes/exported_vs_not.rs | 6 +- src/test/incremental/hashes/for_loops.rs | 16 +- .../incremental/hashes/function_interfaces.rs | 14 +- src/test/incremental/hashes/if_expressions.rs | 12 +- src/test/incremental/hashes/inherent_impls.rs | 20 +- src/test/incremental/hashes/inline_asm.rs | 12 +- .../incremental/hashes/let_expressions.rs | 24 +- .../incremental/hashes/loop_expressions.rs | 10 +- .../incremental/hashes/match_expressions.rs | 26 +- src/test/incremental/hashes/panic_exprs.rs | 18 +- .../incremental/hashes/struct_constructors.rs | 16 +- .../hashes/unary_and_binary_exprs.rs | 56 +- .../incremental/hashes/while_let_loops.rs | 12 +- src/test/incremental/hashes/while_loops.rs | 12 +- src/test/incremental/issue-54242.rs | 17 + src/test/incremental/lto.rs | 40 + src/test/mir-opt/basic_assignment.rs | 2 +- src/test/mir-opt/inline-any-operand.rs | 10 +- src/test/mir-opt/inline-retag.rs | 10 +- src/test/mir-opt/inline-trait-method_2.rs | 8 +- src/test/mir-opt/issue-49232.rs | 46 +- src/test/mir-opt/match_false_edges.rs | 316 +- src/test/mir-opt/match_test.rs | 57 +- src/test/mir-opt/remove_fake_borrows.rs | 104 +- src/test/mir-opt/retag.rs | 14 +- src/test/mir-opt/unusual-item-types.rs | 66 + src/test/pretty/dollar-crate.pp | 18 + src/test/pretty/dollar-crate.rs | 7 + src/test/run-fail-fulldeps/qquote.rs | 35 - .../alloc-extern-crates/Makefile | 2 +- .../c-dynamic-dylib/Makefile | 8 +- .../run-make-fulldeps/c-dynamic-rlib/Makefile | 10 +- .../c-link-to-rust-staticlib/Makefile | 10 +- .../cdylib-fewer-symbols/Makefile | 7 +- .../compiler-rt-works-on-mingw/Makefile | 12 +- .../cross-lang-lto-clang/Makefile | 25 + .../cross-lang-lto-clang/clib.c | 9 + .../cross-lang-lto-clang/cmain.c | 12 + .../cross-lang-lto-clang/main.rs | 11 + .../cross-lang-lto-clang/rustlib.rs | 12 + .../cross-lang-lto-upstream-rlibs/Makefile | 25 +- .../run-make-fulldeps/cross-lang-lto/Makefile | 35 +- .../dep-info-spaces/Makefile | 17 +- src/test/run-make-fulldeps/dep-info/Makefile | 17 +- .../emit-stack-sizes/Makefile | 28 +- src/test/run-make-fulldeps/fpic/Makefile | 9 +- .../include_bytes_deps/Makefile | 17 +- .../intrinsic-unreachable/Makefile | 12 +- .../run-make-fulldeps/issue-24445/Makefile | 6 +- .../run-make-fulldeps/issue-26006/Makefile | 6 +- .../run-make-fulldeps/issue-36710/Makefile | 13 +- .../run-make-fulldeps/issue-37839/Makefile | 6 +- .../run-make-fulldeps/issue-37893/Makefile | 6 +- .../run-make-fulldeps/issue-51671/Makefile | 8 +- .../libs-search-path/Makefile | 8 +- .../libs-through-symlinks/Makefile | 5 +- .../linker-output-non-utf8/Makefile | 17 +- .../min-global-align/Makefile | 4 +- .../no-integrated-as/Makefile | 5 +- .../run-make-fulldeps/pgo-gen-lto/Makefile | 4 +- src/test/run-make-fulldeps/pgo-gen/Makefile | 4 +- .../prune-link-args/Makefile | 8 +- .../run-make-fulldeps/relro-levels/Makefile | 4 +- .../rustdoc-io-error/Makefile | 11 +- .../run-make-fulldeps/sanitizer-leak/Makefile | 12 +- .../sanitizer-memory/Makefile | 6 +- .../static-extern-type/Makefile | 5 + .../static-extern-type/define-foo.c | 11 + .../static-extern-type/use-foo.rs | 14 + .../symbol-visibility/Makefile | 8 +- .../symlinked-extern/Makefile | 9 +- .../symlinked-libraries/Makefile | 9 +- .../run-make-fulldeps/symlinked-rlib/Makefile | 9 +- .../target-cpu-native/Makefile | 8 +- .../use-extern-for-plugins/Makefile | 11 +- src/test/run-make-fulldeps/used/Makefile | 8 +- .../run-make-fulldeps/windows-spawn/Makefile | 8 +- src/test/run-make/nvptx-binary-crate/Makefile | 12 + src/test/run-make/nvptx-binary-crate/main.rs | 28 + src/test/run-make/nvptx-dylib-crate/Makefile | 10 + src/test/run-make/nvptx-dylib-crate/dep.rs | 14 + src/test/run-make/nvptx-dylib-crate/kernel.rs | 59 + src/test/run-make/nvptx-emit-asm/Makefile | 9 + src/test/run-make/nvptx-emit-asm/kernel.rs | 41 + .../run-make/thumb-none-cortex-m/Makefile | 11 +- src/test/run-make/thumb-none-qemu/Makefile | 8 +- .../run-make/wasm-custom-section/Makefile | 6 +- .../wasm-custom-sections-opt/Makefile | 6 +- .../run-make/wasm-export-all-symbols/Makefile | 7 +- src/test/run-make/wasm-import-module/Makefile | 6 +- src/test/run-make/wasm-panic-small/Makefile | 7 +- .../wasm-stringify-ints-small/Makefile | 10 + .../run-make/wasm-stringify-ints-small/foo.rs | 33 + .../wasm-symbols-not-exported/Makefile | 7 +- .../wasm-symbols-not-imported/Makefile | 7 +- .../auxiliary/issue-16723.rs | 29 - .../auxiliary/issue-40001-plugin.rs | 10 +- .../auxiliary/lint_for_crate.rs | 4 + .../auxiliary/macro_crate_test.rs | 227 +- .../auxiliary/plugin_args.rs | 2 +- .../auxiliary/plugin_with_plugin_lib.rs | 13 - .../auxiliary/procedural_mbe_matching.rs | 82 - .../syntax_extension_with_dll_deps_2.rs | 27 - src/test/run-pass-fulldeps/issue-16723.rs | 19 - src/test/run-pass-fulldeps/issue-16992.rs | 15 - .../issue-18763-quote-token-tree.rs | 22 - .../macro-crate-does-hygiene-work.rs | 16 - .../macro-crate-multi-decorator-literals.rs | 50 - .../macro-crate-multi-decorator.rs | 4 +- src/test/run-pass-fulldeps/macro-crate.rs | 46 - .../mbe_matching_test_macro.rs | 11 - .../plugin-lib-ok-in-plugin.rs | 16 - .../plugin-plus-extern-crate.rs | 17 - .../pprust-expr-roundtrip.rs | 56 +- src/test/run-pass-fulldeps/qquote.rs | 92 - src/test/run-pass-fulldeps/quote-tokens.rs | 45 - .../quote-unused-sp-no-warning.rs | 15 - .../syntax-extension-with-dll-deps.rs | 10 - .../allocator/auxiliary/custom-as-global.rs | 4 +- src/test/run-pass/allocator/custom.rs | 4 +- src/test/run-pass/allocator/xcrate-use.rs | 4 +- src/test/run-pass/allocator/xcrate-use2.rs | 5 +- src/test/run-pass/async-await.rs | 19 +- src/test/run-pass/atomic-access-bool.rs | 4 +- src/test/run-pass/atomic-compare_exchange.rs | 4 +- src/test/run-pass/auxiliary/arc_wake.rs | 56 + src/test/run-pass/auxiliary/svh-b.rs | 6 +- src/test/run-pass/command-before-exec.rs | 83 - src/test/run-pass/command-pre-exec.rs | 115 + src/test/run-pass/const-int-overflowing.rs | 6 + .../run-pass/const-int-saturating-arith.rs | 34 + src/test/run-pass/const-int-wrapping.rs | 6 + .../run-pass/deriving/deriving-copyclone.rs | 5 +- src/test/run-pass/drop/dynamic-drop.rs | 3 +- src/test/run-pass/futures-api.rs | 56 +- .../run-pass/generator/auxiliary/xcrate.rs | 3 +- .../run-pass/generator/conditional-drop.rs | 13 +- src/test/run-pass/generator/control-flow.rs | 6 +- src/test/run-pass/generator/drop-env.rs | 9 +- src/test/run-pass/generator/issue-44197.rs | 7 +- src/test/run-pass/generator/iterator-count.rs | 8 +- .../generator/live-upvar-across-yield.rs | 3 +- .../run-pass/generator/nested_generators.rs | 9 +- .../run-pass/generator/non-static-is-unpin.rs | 18 + src/test/run-pass/generator/panic-drops.rs | 9 +- src/test/run-pass/generator/panic-safe.rs | 5 +- .../run-pass/generator/pin-box-generator.rs | 13 + .../run-pass/generator/resume-after-return.rs | 5 +- src/test/run-pass/generator/smoke.rs | 29 +- .../run-pass/generator/static-generators.rs | 10 +- .../run-pass/generator/xcrate-reachable.rs | 3 +- src/test/run-pass/generator/xcrate.rs | 7 +- src/test/run-pass/issues/issue-27949.rs | 41 + src/test/run-pass/issues/issue-34053.rs | 4 +- src/test/run-pass/issues/issue-7012.rs | 2 +- src/test/run-pass/item-attributes.rs | 2 +- src/test/run-pass/macros/macro-follow.rs | 16 +- src/test/run-pass/mir/mir_fat_ptr_drop.rs | 2 +- .../run-pass/monomorphize-abi-alignment.rs | 2 +- .../numbers-arithmetic/num-wrapping.rs | 2 +- .../run-pass/panic-uninitialized-zeroed.rs | 6 +- .../panics/panic-recover-propagate.rs | 4 +- src/test/run-pass/proc-macro/derive-b.rs | 2 - ...intrinsic-generic-arithmetic-saturating.rs | 92 + .../simd/simd-intrinsic-generic-bitmask.rs | 61 + .../simd/simd-intrinsic-generic-reduction.rs | 1 + src/test/run-pass/structs-enums/align-enum.rs | 55 + .../sync-send-iterators-in-libcore.rs | 3 - .../threads-sendsync/tls-init-on-init.rs | 4 +- .../run-pass/try-from-int-error-partial-eq.rs | 1 - src/test/run-pass/try_from.rs | 37 + src/test/run-pass/weird-exprs.rs | 2 +- .../{rustdoc-js => rustdoc-js-std}/alias-1.js | 0 .../{rustdoc-js => rustdoc-js-std}/alias-2.js | 0 .../{rustdoc-js => rustdoc-js-std}/alias-3.js | 0 .../{rustdoc-js => rustdoc-js-std}/alias.js | 0 src/test/rustdoc-js-std/basic.js | 15 + .../deduplication.js | 0 .../enum-option.js | 0 .../filter-crate.js | 0 .../fn-forget.js | 0 .../{rustdoc-js => rustdoc-js-std}/from_u.js | 0 .../{rustdoc-js => rustdoc-js-std}/keyword.js | 0 .../macro-check.js | 0 .../macro-print.js | 0 .../multi-query.js | 0 .../{rustdoc-js => rustdoc-js-std}/never.js | 0 .../{rustdoc-js => rustdoc-js-std}/quoted.js | 0 .../should-fail.js | 0 .../string-from_ut.js | 0 .../struct-vec.js | 0 .../{rustdoc-js => rustdoc-js-std}/vec-new.js | 0 src/test/rustdoc-js/basic.js | 12 +- src/test/rustdoc-js/basic.rs | 2 + src/test/rustdoc-js/substring.js | 10 - .../rustdoc-ui/deny-missing-docs-crate.rs | 10 - .../rustdoc-ui/deny-missing-docs-crate.stderr | 6 +- .../rustdoc-ui/deny-missing-docs-macro.rs | 10 - .../rustdoc-ui/deny-missing-docs-macro.stderr | 4 +- .../rustdoc-ui/failed-doctest-output.stdout | 4 +- src/test/rustdoc-ui/invalid-syntax.rs | 61 +- src/test/rustdoc-ui/invalid-syntax.stderr | 105 +- src/test/rustdoc/async-fn.rs | 35 +- src/test/rustdoc/auxiliary/enum_primitive.rs | 5 +- src/test/rustdoc/bad-codeblock-syntax.rs | 27 + src/test/rustdoc/deprecated-future.rs | 4 +- src/test/rustdoc/deprecated.rs | 11 +- src/test/rustdoc/inline_cross/macros.rs | 3 +- src/test/rustdoc/internal.rs | 6 +- src/test/rustdoc/intra-link-prim-methods.rs | 3 + src/test/rustdoc/issue-19190.rs | 2 + src/test/rustdoc/issue-21092.rs | 1 - src/test/rustdoc/issue-27862.rs | 2 +- src/test/rustdoc/issue-32374.rs | 7 +- src/test/rustdoc/issue-35169-2.rs | 1 - src/test/rustdoc/issue-35169.rs | 1 - src/test/rustdoc/issue-56701.rs | 34 + src/test/rustdoc/keyword.rs | 2 +- src/test/rustdoc/macros.rs | 2 - src/test/rustdoc/no-crate-filter.rs | 10 - src/test/rustdoc/proc-macro.rs | 5 + src/test/rustdoc/process-termination.rs | 24 + src/test/rustdoc/rustc_deprecated-future.rs | 11 + src/test/rustdoc/src-links.rs | 2 - src/test/rustdoc/stability.rs | 12 + src/test/rustdoc/structfields.rs | 2 + src/test/rustdoc/trait_alias.rs | 21 + src/test/rustdoc/use-attr.rs | 8 + src/test/rustdoc/without-redirect.rs | 13 + src/test/rustdoc/wrapping.rs | 5 + .../ui-fulldeps/auxiliary/lint_for_crate.rs | 4 + .../auxiliary/lint_group_plugin_test.rs | 4 + .../ui-fulldeps/auxiliary/lint_plugin_test.rs | 4 + .../ui-fulldeps/auxiliary/lint_tool_test.rs | 4 + .../ui-fulldeps/auxiliary/macro_crate_test.rs | 149 - src/test/ui-fulldeps/gated-plugin.rs | 4 +- src/test/ui-fulldeps/gated-plugin.stderr | 2 +- src/test/ui-fulldeps/gated-quote.rs | 57 - src/test/ui-fulldeps/gated-quote.stderr | 80 - src/test/ui-fulldeps/issue-48941.rs | 16 - src/test/ui-fulldeps/issue-48941.stderr | 14 - .../ui-fulldeps/macro-crate-doesnt-resolve.rs | 8 - .../macro-crate-doesnt-resolve.stderr | 9 - .../macro-crate-unexported-macro.rs | 9 - .../macro-crate-unexported-macro.stderr | 8 - .../ui-fulldeps/plugin-as-extern-crate.rs | 6 +- .../ui-fulldeps/plugin-as-extern-crate.stderr | 2 +- .../ui-fulldeps/plugin-plus-extern-crate.rs | 17 - .../plugin-plus-extern-crate.stderr | 14 - src/test/ui-fulldeps/qquote.rs | 27 - src/test/ui-fulldeps/qquote.stderr | 9 - .../associated-types-coherence-failure.rs | 2 +- src/test/ui/attr-eq-token-tree.rs | 6 +- src/test/ui/attr-eq-token-tree.stderr | 8 + src/test/ui/attr-usage-repr.rs | 3 +- src/test/ui/attr-usage-repr.stderr | 18 +- ...bute-with-no-generics-in-parameter-list.rs | 3 + ...-with-no-generics-in-parameter-list.stderr | 8 + .../attrs-with-no-formal-in-generics-1.rs | 2 +- .../attrs-with-no-formal-in-generics-1.stderr | 2 +- .../attrs-with-no-formal-in-generics-2.rs | 2 +- .../attrs-with-no-formal-in-generics-2.stderr | 2 +- .../attrs-with-no-formal-in-generics-3.rs | 2 +- .../attrs-with-no-formal-in-generics-3.stderr | 2 +- src/test/ui/augmented-assignments.nll.stderr | 2 +- src/test/ui/auto-ref-slice-plus-ref.stderr | 3 +- src/test/ui/bad/bad-type-env-capture.rs | 2 +- src/test/ui/bad/bad-type-env-capture.stderr | 8 +- .../ui/binop/binop-consume-args.nll.stderr | 253 + .../ui/binop/binop-move-semantics.nll.stderr | 12 +- src/test/ui/block-result/issue-3563.stderr | 4 +- .../ui/borrowck/borrowck-asm.ast.nll.stderr | 10 +- src/test/ui/borrowck/borrowck-asm.mir.stderr | 10 +- .../borrowck-consume-unsize-vec.nll.stderr | 13 + .../borrowck-consume-upcast-box.nll.stderr | 4 +- .../borrowck/borrowck-drop-from-guard.stderr | 5 +- .../borrowck-for-loop-head-linkage.nll.stderr | 4 +- .../ui/borrowck/borrowck-issue-48962.stderr | 8 +- .../borrowck-lend-flow-loop.nll.stderr | 4 +- .../borrowck-loan-in-overloaded-op.nll.stderr | 4 +- ...ve-moved-value-into-closure.ast.nll.stderr | 5 +- ...k-move-moved-value-into-closure.mir.stderr | 5 +- .../borrowck-multiple-captures.nll.stderr | 12 +- ...ck-mut-borrow-linear-errors.ast.nll.stderr | 4 +- ...rrowck-mut-borrow-linear-errors.mir.stderr | 4 +- .../borrowck-overloaded-call.nll.stderr | 5 +- ...wck-overloaded-index-move-index.nll.stderr | 5 +- .../borrowck-partial-reinit-1.nll.stderr | 10 +- .../borrowck-partial-reinit-2.nll.stderr | 4 +- src/test/ui/borrowck/borrowck-reinit.stderr | 5 +- .../borrowck-unboxed-closures.nll.stderr | 6 +- ...orrowck-uninit-field-access.ast.nll.stderr | 2 +- .../borrowck-uninit-field-access.mir.stderr | 2 +- .../borrowck-union-move-assign.nll.stderr | 4 +- .../borrowck/borrowck-union-move.nll.stderr | 24 +- .../issue-47215-ice-from-drop-elab.rs | 2 +- ...-mutation-of-moved-out-with-mut.nll.stderr | 12 +- ...499-field-mutation-of-moved-out.nll.stderr | 12 +- ...e-58776-borrowck-scans-children.ast.stderr | 15 + ...776-borrowck-scans-children.migrate.stderr | 32 + ...e-58776-borrowck-scans-children.nll.stderr | 32 + .../issue-58776-borrowck-scans-children.rs | 21 + .../mut-borrow-outside-loop.nll.stderr | 2 +- .../two-phase-nonrecv-autoref.ast.nll.stderr | 2 + .../two-phase-nonrecv-autoref.nll.stderr | 2 + src/test/ui/cast/cast-ptr-to-int-const.rs | 8 +- src/test/ui/cast/cast-ptr-to-int-const.stderr | 12 +- src/test/ui/codemap_tests/tab_3.nll.stderr | 4 +- .../cfg-attr-syntax-validation.rs | 3 +- .../cfg-attr-syntax-validation.stderr | 8 +- .../const-expression-parameter.rs | 23 + .../const-expression-parameter.stderr | 26 + .../const-fn-with-const-param.rs | 12 + .../const-fn-with-const-param.stderr | 24 + .../const-param-before-other-params.rs | 14 + .../const-param-before-other-params.stderr | 32 + .../const-param-from-outer-fn.rs | 11 + .../const-param-from-outer-fn.stderr | 26 + .../const-parameter-uppercase-lint.rs | 8 + .../const-parameter-uppercase-lint.stderr | 19 + .../const-eval/const-eval-overflow-3.rs | 9 +- .../const-eval/const-eval-overflow-3b.rs | 10 +- .../ui/consts/const-eval/const_raw_ptr_ops.rs | 8 +- .../const-eval/const_raw_ptr_ops.stderr | 16 +- src/test/ui/consts/const-eval/ub-nonnull.rs | 7 + .../ui/consts/const-eval/ub-nonnull.stderr | 14 +- src/test/ui/consts/const-eval/ub-ref.rs | 2 + src/test/ui/consts/const-eval/ub-ref.stderr | 12 +- src/test/ui/consts/const-size_of-cycle.stderr | 4 +- src/test/ui/consts/const_arg_local.rs | 13 + src/test/ui/consts/const_arg_local.stderr | 8 + src/test/ui/consts/const_arg_promotable.rs | 12 + .../ui/consts/const_arg_promotable.stderr | 8 + src/test/ui/consts/const_arg_wrapper.rs | 12 + src/test/ui/consts/const_arg_wrapper.stderr | 8 + src/test/ui/consts/drop_none.rs | 13 + src/test/ui/consts/invalid_promotion.rs | 18 + src/test/ui/consts/match_ice.rs | 10 + src/test/ui/consts/match_ice.stderr | 9 + .../min_const_fn/bad_const_fn_body_ice.stderr | 4 +- .../ui/consts/min_const_fn/cast_errors.stderr | 21 +- .../ui/consts/min_const_fn/cmp_fn_pointers.rs | 2 +- .../min_const_fn/cmp_fn_pointers.stderr | 5 +- .../ui/consts/min_const_fn/loop_ice.stderr | 5 +- .../min_const_fn/min_const_fn.nll.stderr | 182 +- .../ui/consts/min_const_fn/min_const_fn.rs | 8 +- .../consts/min_const_fn/min_const_fn.stderr | 181 +- .../min_const_fn/min_const_fn_dyn.nll.stderr | 11 +- .../min_const_fn/min_const_fn_dyn.stderr | 9 +- .../min_const_fn/min_const_fn_fn_ptr.stderr | 9 +- .../min_const_fn_libstd_stability.stderr | 17 +- ...in_const_unsafe_fn_libstd_stability.stderr | 17 +- ...n_const_unsafe_fn_libstd_stability2.stderr | 13 +- .../consts/min_const_fn/mutable_borrow.stderr | 9 +- .../ui/consts/miri_unleashed/assoc_const.rs | 30 + .../consts/miri_unleashed/assoc_const.stderr | 15 + .../ui/consts/miri_unleashed/assoc_const_2.rs | 28 + .../miri_unleashed/assoc_const_2.stderr | 9 + ...ure-gate-unleash_the_miri_inside_of_you.rs | 27 + ...gate-unleash_the_miri_inside_of_you.stderr | 17 + .../promote_evaluation_unused_result.rs | 8 + .../ui/consts/single_variant_match_ice.stderr | 7 +- .../ui/deprecation/atomic_initializers.fixed | 11 + .../ui/deprecation/atomic_initializers.rs | 11 + .../ui/deprecation/atomic_initializers.stderr | 12 + .../ui/deprecation/deprecation-in-future.rs | 4 +- .../deprecation/deprecation-in-future.stderr | 14 +- src/test/ui/deprecation/deprecation-lint.rs | 5 +- .../ui/deprecation/deprecation-lint.stderr | 100 +- src/test/ui/deprecation/deprecation-sanity.rs | 6 + .../ui/deprecation/deprecation-sanity.stderr | 20 +- .../ui/deprecation/derive_on_deprecated.rs | 9 + .../derive_on_deprecated_forbidden.rs | 9 + src/test/ui/deprecation/invalid-literal.rs | 4 + .../ui/deprecation/invalid-literal.stderr | 8 + .../rustc_deprecation-in-future.rs | 15 + .../rustc_deprecation-in-future.stderr | 14 + .../derives/deriving-meta-empty-trait-list.rs | 7 +- .../deriving-meta-empty-trait-list.stderr | 8 +- ...e-21659-show-relevant-trait-impls-2.stderr | 2 +- .../issue-39802-show-5-trait-impls.stderr | 4 +- ...92-tuple-destructure-missing-parens.stderr | 60 +- .../ui/did_you_mean/recursion_limit.stderr | 3 +- src/test/ui/double-type-import.stderr | 9 +- .../duplicate/duplicate-type-parameter.stderr | 14 +- src/test/ui/e0119/conflict-with-std.rs | 1 - src/test/ui/e0119/conflict-with-std.stderr | 8 +- .../ui/empty/empty-struct-braces-expr.stderr | 10 +- src/test/ui/error-codes/E0017.nll.stderr | 8 +- src/test/ui/error-codes/E0017.stderr | 8 +- src/test/ui/error-codes/E0055.rs | 4 +- src/test/ui/error-codes/E0055.stderr | 2 +- src/test/ui/error-codes/E0214.stderr | 7 +- src/test/ui/error-codes/E0232.rs | 8 - src/test/ui/error-codes/E0232.stderr | 11 - src/test/ui/error-codes/E0275.stderr | 3 +- src/test/ui/error-codes/E0296.rs | 3 - src/test/ui/error-codes/E0296.stderr | 9 - src/test/ui/error-codes/E0388.nll.stderr | 8 +- src/test/ui/error-codes/E0388.stderr | 8 +- src/test/ui/error-codes/E0395.rs | 2 +- src/test/ui/error-codes/E0395.stderr | 6 +- src/test/ui/error-codes/E0401.stderr | 16 +- src/test/ui/error-codes/E0403.stderr | 2 +- src/test/ui/error-codes/E0423.stderr | 12 +- src/test/ui/error-codes/E0430.stderr | 10 +- src/test/ui/error-codes/E0446.rs | 2 +- src/test/ui/error-codes/E0446.stderr | 4 +- src/test/ui/error-codes/E0451.rs | 8 +- src/test/ui/error-codes/E0451.stderr | 12 +- src/test/ui/error-codes/E0492.rs | 4 +- src/test/ui/error-codes/E0558.rs | 6 - src/test/ui/error-codes/E0558.stderr | 9 - .../auxiliary/cross_crate_ice.rs | 12 + .../auxiliary/cross_crate_ice2.rs | 21 + .../ui/existential_types/bound_reduction2.rs | 3 +- .../existential_types/bound_reduction2.stderr | 16 +- .../ui/existential_types/cross_crate_ice.rs | 16 + .../ui/existential_types/cross_crate_ice2.rs | 11 + .../different_defining_uses.rs | 2 +- .../different_defining_uses.stderr | 6 +- .../different_defining_uses_never_type.rs | 4 +- .../different_defining_uses_never_type.stderr | 12 +- .../generic_different_defining_uses.rs | 2 +- .../generic_different_defining_uses.stderr | 6 +- .../generic_duplicate_param_use.rs | 9 +- .../generic_duplicate_param_use.stderr | 20 +- .../generic_duplicate_param_use10.rs | 12 + .../generic_duplicate_param_use2.rs | 17 + .../generic_duplicate_param_use2.stderr | 11 + .../generic_duplicate_param_use3.rs | 22 + .../generic_duplicate_param_use3.stderr | 28 + .../generic_duplicate_param_use4.rs | 17 + .../generic_duplicate_param_use4.stderr | 11 + .../generic_duplicate_param_use5.rs | 17 + .../generic_duplicate_param_use5.stderr | 19 + .../generic_duplicate_param_use6.rs | 17 + .../generic_duplicate_param_use6.stderr | 19 + .../generic_duplicate_param_use7.rs | 25 + .../generic_duplicate_param_use8.rs | 16 + .../generic_duplicate_param_use8.stderr | 19 + .../generic_duplicate_param_use9.rs | 20 + .../generic_duplicate_param_use9.stderr | 18 + .../generic_nondefining_use.rs | 3 +- .../generic_nondefining_use.stderr | 16 +- .../existential_types/not_a_defining_use.rs | 40 + .../not_a_defining_use.stderr | 27 + .../existential_types/unused_generic_param.rs | 7 +- .../unused_generic_param.stderr | 15 - .../ui/feature-gate-optimize_attribute.rs | 18 + .../ui/feature-gate-optimize_attribute.stderr | 50 + .../feature-gate-static-nobundle-2.rs | 6 + .../feature-gate-static-nobundle-2.stderr | 7 + .../issue-43106-gating-of-builtin-attrs.rs | 331 +- ...issue-43106-gating-of-builtin-attrs.stderr | 879 ++- .../issue-43106-gating-of-deprecated.rs | 12 +- .../issue-43106-gating-of-inline.rs | 14 +- .../issue-43106-gating-of-inline.stderr | 38 +- .../issue-43106-gating-of-macro_use.rs | 16 +- .../issue-43106-gating-of-macro_use.stderr | 24 +- ...issue-43106-gating-of-proc_macro_derive.rs | 14 +- ...e-43106-gating-of-proc_macro_derive.stderr | 24 +- .../issue-43106-gating-of-rustc_deprecated.rs | 14 +- ...ue-43106-gating-of-rustc_deprecated.stderr | 28 +- .../issue-43106-gating-of-stable.rs | 14 +- .../issue-43106-gating-of-stable.stderr | 28 +- .../issue-43106-gating-of-unstable.rs | 14 +- .../issue-43106-gating-of-unstable.stderr | 28 +- .../ui/feature-gates/auxiliary/pub_dep.rs | 1 + ...te-allow-internal-unstable-nested-macro.rs | 2 +- ...llow-internal-unstable-nested-macro.stderr | 4 +- ...ure-gate-allow-internal-unstable-struct.rs | 2 +- ...gate-allow-internal-unstable-struct.stderr | 4 +- .../feature-gate-allow-internal-unstable.rs | 2 +- ...eature-gate-allow-internal-unstable.stderr | 4 +- .../feature-gate-const_generics.rs | 7 + .../feature-gate-const_generics.stderr | 31 + .../feature-gate-extern_crate_self.rs | 3 - .../feature-gate-extern_crate_self.stderr | 11 - .../feature-gate-ffi_returns_twice.rs | 7 + .../feature-gate-ffi_returns_twice.stderr | 11 + .../feature-gates/feature-gate-is_sorted.rs | 13 + .../feature-gate-is_sorted.stderr | 35 + ...eature-gate-public_private_dependencies.rs | 20 + .../feature-gate-repr_align_enum.rs | 10 + .../feature-gate-repr_align_enum.stderr | 11 + .../feature-gate-rustc-attrs-1.rs | 2 +- .../feature-gate-rustc-attrs-1.stderr | 11 +- .../feature-gate-type_alias_enum_variants.rs | 10 - ...ature-gate-type_alias_enum_variants.stderr | 8 +- ...ture-gate-unrestricted-attribute-tokens.rs | 7 - ...-gate-unrestricted-attribute-tokens.stderr | 20 - .../feature-gate-unwind-attributes.rs | 2 +- .../feature-gate-unwind-attributes.stderr | 4 +- src/test/ui/ffi_returns_twice.rs | 6 + src/test/ui/ffi_returns_twice.stderr | 9 + .../fully-qualified-type-name2.stderr | 2 + .../fully-qualified-type-name4.stderr | 2 + ...nctional-struct-update-respects-privacy.rs | 4 +- src/test/ui/gated-bad-feature.rs | 4 +- src/test/ui/gated-bad-feature.stderr | 24 +- .../ui/generator/auto-trait-regions.stderr | 8 +- src/test/ui/generator/borrowing.nll.stderr | 16 +- src/test/ui/generator/borrowing.rs | 3 +- src/test/ui/generator/borrowing.stderr | 12 +- src/test/ui/generator/dropck.nll.stderr | 4 +- src/test/ui/generator/dropck.rs | 3 +- src/test/ui/generator/dropck.stderr | 4 +- .../generator-region-requirements.ast.stderr | 2 +- .../generator-region-requirements.nll.stderr | 2 +- .../generator-region-requirements.rs | 3 +- .../ref-escapes-but-not-over-yield.nll.stderr | 2 +- .../ref-escapes-but-not-over-yield.rs | 5 +- .../ref-escapes-but-not-over-yield.stderr | 2 +- src/test/ui/generator/sized-yield.rs | 3 +- src/test/ui/generator/sized-yield.stderr | 8 +- src/test/ui/generator/static-not-unpin.rs | 15 + src/test/ui/generator/static-not-unpin.stderr | 15 + .../yield-while-iterating.nll.stderr | 8 +- .../ui/generator/yield-while-iterating.rs | 13 +- .../ui/generator/yield-while-iterating.stderr | 6 +- .../generator/yield-while-local-borrowed.rs | 13 +- .../yield-while-local-borrowed.stderr | 8 +- .../yield-while-ref-reborrowed.nll.stderr | 6 +- .../generator/yield-while-ref-reborrowed.rs | 13 +- .../yield-while-ref-reborrowed.stderr | 4 +- src/test/ui/generic/generic-no-mangle.rs | 4 +- src/test/ui/generic/generic-no-mangle.stderr | 8 +- .../ui/hrtb/hrtb-cache-issue-54302.stderr | 4 +- src/test/ui/hrtb/hrtb-perfect-forwarding.rs | 2 +- .../ui/hrtb/hrtb-perfect-forwarding.stderr | 2 +- src/test/ui/huge-array-simple.rs | 13 +- src/test/ui/huge-array-simple.stderr | 4 + src/test/ui/huge-enum.rs | 6 +- src/test/ui/huge-enum.stderr | 2 +- src/test/ui/if/if-let-arm-types.rs | 9 +- src/test/ui/if/if-let-arm-types.stderr | 22 +- src/test/ui/impl-trait/auto-trait-leak.stderr | 6 +- src/test/ui/impl-trait/bindings.rs | 8 +- src/test/ui/impl-trait/bindings.stderr | 26 +- src/test/ui/impl-trait/equality.stderr | 5 +- ...-deeply-nested-impl-trait-in-assoc-proj.rs | 42 + ...ply-nested-impl-trait-in-assoc-proj.stderr | 30 + .../issue-57979-impl-trait-in-path.rs | 37 + .../issue-57979-impl-trait-in-path.stderr | 30 + ...e-57979-nested-impl-trait-in-assoc-proj.rs | 37 + ...979-nested-impl-trait-in-assoc-proj.stderr | 36 + src/test/ui/imports/duplicate.stderr | 9 +- .../extern-crate-self-fail.rs | 2 - .../extern-crate-self-fail.stderr | 4 +- .../extern-crate-self-macro-alias.rs | 16 + .../extern-crate-self-macro-item.rs | 12 + .../extern-crate-self-macro-self.rs | 16 + .../extern-crate-self-pass.rs | 2 - src/test/ui/imports/issue-57539.rs | 8 + src/test/ui/imports/issue-57539.stderr | 18 + src/test/ui/index-help.stderr | 2 +- src/test/ui/indexing-requires-a-uint.rs | 2 +- src/test/ui/indexing-requires-a-uint.stderr | 4 +- src/test/ui/inner-static-type-parameter.rs | 2 +- .../ui/inner-static-type-parameter.stderr | 6 +- src/test/ui/integral-indexing.rs | 16 +- src/test/ui/integral-indexing.stderr | 32 +- .../internal/auxiliary/internal_unstable.rs | 10 +- src/test/ui/internal/internal-unstable.rs | 2 +- src/test/ui/invalid_crate_type_syntax.rs | 2 +- src/test/ui/invalid_crate_type_syntax.stderr | 6 +- src/test/ui/issue-42944.rs | 19 + src/test/ui/issue-42944.stderr | 20 + .../ui/issue-53787-inline-assembler-macro.rs | 23 + .../issue-53787-inline-assembler-macro.stderr | 9 + src/test/ui/issue-54943.rs | 6 +- src/test/ui/issue-54943.stderr | 11 + src/test/ui/issues/auxiliary/issue-52891.rs | 33 + src/test/ui/issues/auxiliary/issue-56943.rs | 3 + src/test/ui/issues/issue-11319.rs | 10 +- src/test/ui/issues/issue-11319.stderr | 18 +- src/test/ui/issues/issue-12796.rs | 2 +- src/test/ui/issues/issue-12796.stderr | 4 +- src/test/ui/issues/issue-17385.nll.stderr | 8 +- src/test/ui/issues/issue-17458.rs | 2 +- src/test/ui/issues/issue-17458.stderr | 6 +- .../issue-17718-const-bad-values.stderr | 8 +- src/test/ui/issues/issue-17728.rs | 3 +- src/test/ui/issues/issue-17728.stderr | 10 +- src/test/ui/issues/issue-17999.stderr | 4 +- src/test/ui/issues/issue-18294.rs | 2 +- src/test/ui/issues/issue-18294.stderr | 6 +- src/test/ui/issues/issue-20413.stderr | 3 +- src/test/ui/issues/issue-20616-3.rs | 5 +- src/test/ui/issues/issue-20616-3.stderr | 8 +- src/test/ui/issues/issue-20616-4.rs | 4 +- src/test/ui/issues/issue-20616-4.stderr | 6 +- src/test/ui/issues/issue-20616-5.rs | 4 +- src/test/ui/issues/issue-20616-5.stderr | 6 +- src/test/ui/issues/issue-20616-6.rs | 4 +- src/test/ui/issues/issue-20616-6.stderr | 6 +- src/test/ui/issues/issue-20616-7.rs | 5 +- src/test/ui/issues/issue-20616-7.stderr | 8 +- src/test/ui/issues/issue-20616-8.rs | 5 +- src/test/ui/issues/issue-20616-8.stderr | 8 +- src/test/ui/issues/issue-20616-9.rs | 5 +- src/test/ui/issues/issue-20616-9.stderr | 8 +- src/test/ui/issues/issue-20797.rs | 6 +- src/test/ui/issues/issue-22599.stderr | 2 +- src/test/ui/issues/issue-23217.stderr | 5 +- src/test/ui/issues/issue-23589.rs | 3 +- src/test/ui/issues/issue-23589.stderr | 21 +- src/test/ui/issues/issue-24036.rs | 2 +- src/test/ui/issues/issue-24036.stderr | 14 +- src/test/ui/issues/issue-24357.nll.stderr | 4 +- src/test/ui/issues/issue-25700.nll.stderr | 13 + src/test/ui/issues/issue-25826.rs | 2 +- src/test/ui/issues/issue-25826.stderr | 6 +- src/test/ui/issues/issue-26548.stderr | 2 +- src/test/ui/issues/issue-26886.stderr | 18 +- ...e-27282-move-match-input-into-guard.stderr | 5 +- src/test/ui/issues/issue-27433.rs | 2 +- src/test/ui/issues/issue-27433.stderr | 8 +- src/test/ui/issues/issue-28344.stderr | 6 +- src/test/ui/issues/issue-28971.stderr | 7 +- src/test/ui/issues/issue-29723.stderr | 5 +- src/test/ui/issues/issue-3021-c.rs | 4 +- src/test/ui/issues/issue-3021-c.stderr | 16 +- src/test/ui/issues/issue-3214.rs | 2 +- src/test/ui/issues/issue-3214.stderr | 8 +- src/test/ui/issues/issue-32995-2.rs | 6 +- src/test/ui/issues/issue-32995-2.stderr | 6 +- src/test/ui/issues/issue-32995.rs | 14 +- src/test/ui/issues/issue-32995.stderr | 22 +- src/test/ui/issues/issue-34721.rs | 34 + src/test/ui/issues/issue-34721.stderr | 20 + src/test/ui/issues/issue-3521-2.rs | 2 +- src/test/ui/issues/issue-3521-2.stderr | 8 +- src/test/ui/issues/issue-35677.rs | 7 +- src/test/ui/issues/issue-35677.stderr | 14 +- src/test/ui/issues/issue-3668-2.rs | 2 +- src/test/ui/issues/issue-3668-2.stderr | 8 +- src/test/ui/issues/issue-3668.rs | 2 +- src/test/ui/issues/issue-3668.stderr | 8 +- src/test/ui/issues/issue-37550.stderr | 5 +- src/test/ui/issues/issue-42796.nll.stderr | 4 +- src/test/ui/issues/issue-43988.rs | 5 +- src/test/ui/issues/issue-43988.stderr | 23 +- src/test/ui/issues/issue-44415.stderr | 4 +- .../ui/issues/issue-45829/import-twice.stderr | 10 +- src/test/ui/issues/issue-48636.fixed | 3 +- src/test/ui/issues/issue-48636.rs | 3 +- src/test/ui/issues/issue-48636.stderr | 2 +- src/test/ui/issues/issue-49074.stderr | 2 +- src/test/ui/issues/issue-49934.rs | 4 +- .../result-deref-err.stderr | 3 +- src/test/ui/issues/issue-5067.rs | 37 +- src/test/ui/issues/issue-5067.stderr | 72 +- ...ssue-52126-assign-op-invariance.nll.stderr | 2 +- .../issue-52126-assign-op-invariance.rs | 2 +- src/test/ui/issues/issue-52496.rs | 12 + src/test/ui/issues/issue-52496.stderr | 37 + src/test/ui/issues/issue-52891.fixed | 37 + src/test/ui/issues/issue-52891.rs | 38 + src/test/ui/issues/issue-52891.stderr | 145 + src/test/ui/issues/issue-54302-cases.stderr | 16 +- src/test/ui/issues/issue-54302.stderr | 4 +- src/test/ui/issues/issue-54521-1.rs | 16 + src/test/ui/issues/issue-54521-2.fixed | 22 + src/test/ui/issues/issue-54521-2.rs | 22 + src/test/ui/issues/issue-54521-2.stderr | 26 + src/test/ui/issues/issue-54521.fixed | 22 + src/test/ui/issues/issue-54521.rs | 22 + src/test/ui/issues/issue-54521.stderr | 26 + src/test/ui/issues/issue-54582.rs | 16 + src/test/ui/issues/issue-56488.rs | 13 + src/test/ui/issues/issue-56685.rs | 44 + src/test/ui/issues/issue-56685.stderr | 60 + src/test/ui/issues/issue-56943.rs | 8 + src/test/ui/issues/issue-56943.stderr | 12 + src/test/ui/issues/issue-57362-1.rs | 23 + src/test/ui/issues/issue-57362-1.stderr | 14 + src/test/ui/issues/issue-57362-2.rs | 25 + src/test/ui/issues/issue-57362-2.stderr | 15 + src/test/ui/issues/issue-57410-1.rs | 18 + src/test/ui/issues/issue-57410.rs | 17 + src/test/ui/issues/issue-57597.rs | 80 + src/test/ui/issues/issue-57597.stderr | 74 + src/test/ui/issues/issue-57684.fixed | 37 + src/test/ui/issues/issue-57684.rs | 37 + src/test/ui/issues/issue-57684.stderr | 18 + src/test/ui/issues/issue-57741-1.rs | 18 + src/test/ui/issues/issue-57741-1.stderr | 25 + src/test/ui/issues/issue-57741.fixed | 31 + src/test/ui/issues/issue-57741.rs | 31 + src/test/ui/issues/issue-57741.stderr | 59 + src/test/ui/issues/issue-57819.fixed | 47 + src/test/ui/issues/issue-57819.rs | 47 + src/test/ui/issues/issue-57819.stderr | 44 + src/test/ui/issues/issue-57866.rs | 26 + src/test/ui/issues/issue-58856-1.rs | 6 + src/test/ui/issues/issue-58856-1.stderr | 11 + src/test/ui/issues/issue-58856-2.rs | 14 + src/test/ui/issues/issue-58856-2.stderr | 30 + src/test/ui/issues/issue-58857.rs | 7 + src/test/ui/issues/issue-58857.stderr | 8 + src/test/ui/issues/issue-5997-enum.rs | 2 +- src/test/ui/issues/issue-5997-enum.stderr | 6 +- src/test/ui/issues/issue-5997-struct.rs | 2 +- src/test/ui/issues/issue-5997-struct.stderr | 8 +- .../homogeneous-aggr-zero-sized-c-struct.rs | 36 + ...omogeneous-aggr-zero-sized-c-struct.stderr | 14 + .../homogeneous-aggr-zero-sized-repr-rust.rs | 73 + ...mogeneous-aggr-zero-sized-repr-rust.stderr | 32 + src/test/ui/layout/zero-sized-array-union.rs | 95 + .../ui/layout/zero-sized-array-union.stderr | 26 + src/test/ui/lifetime-before-type-params.rs | 9 + .../ui/lifetime-before-type-params.stderr | 31 + .../deny-overflowing-literals.rs} | 2 - .../deny-overflowing-literals.stderr} | 2 +- ...0-unused-variable-in-struct-pattern.stderr | 8 +- .../ui/lint/lint-group-nonstandard-style.rs | 2 +- .../lint/lint-group-nonstandard-style.stderr | 6 +- .../lint-incoherent-auto-trait-objects.rs | 21 + .../lint-incoherent-auto-trait-objects.stderr | 39 + src/test/ui/lint/lint-malformed.rs | 2 +- src/test/ui/lint/lint-malformed.stderr | 12 +- src/test/ui/lint/lint-non-camel-case-types.rs | 24 +- .../ui/lint/lint-non-camel-case-types.stderr | 66 +- src/test/ui/lint/lint-removed-allow.stderr | 2 +- src/test/ui/lint/lint-removed-cmdline.stderr | 2 +- src/test/ui/lint/lint-removed.stderr | 2 +- src/test/ui/lint/lint-renamed-allow.stderr | 2 +- src/test/ui/lint/lint-renamed-cmdline.stderr | 2 +- src/test/ui/lint/lint-renamed.stderr | 2 +- src/test/ui/lint/lint-type-limits2.rs | 1 + src/test/ui/lint/lint-type-limits2.stderr | 10 +- src/test/ui/lint/lint-type-limits3.rs | 1 + src/test/ui/lint/lint-type-limits3.stderr | 10 +- src/test/ui/lint/lint-unused-imports.rs | 2 +- src/test/ui/lint/lint-unused-imports.stderr | 6 +- .../ui/lint/lint-uppercase-variables.stderr | 2 +- src/test/ui/lint/suggestions.rs | 6 +- src/test/ui/lint/suggestions.stderr | 6 +- src/test/ui/lint/type-overflow.rs | 1 + src/test/ui/lint/type-overflow.stderr | 20 +- src/test/ui/liveness/liveness-dead.rs | 9 + .../ui/liveness/liveness-forgot-ret.stderr | 2 +- .../liveness-move-call-arg.nll.stderr | 5 +- .../liveness/liveness-move-in-loop.nll.stderr | 5 +- .../liveness-move-in-while.nll.stderr | 5 +- src/test/ui/liveness/liveness-unused.stderr | 16 +- .../liveness-use-after-move.nll.stderr | 4 +- .../liveness-use-after-send.nll.stderr | 4 +- src/test/ui/lub-glb/old-lub-glb-hr.rs | 4 +- src/test/ui/lub-glb/old-lub-glb-hr.stderr | 13 +- src/test/ui/lub-glb/old-lub-glb-object.rs | 4 +- src/test/ui/lub-glb/old-lub-glb-object.stderr | 13 +- src/test/ui/macros/macro-attribute.rs | 4 +- src/test/ui/macros/macro-attribute.stderr | 8 +- src/test/ui/macros/macro-follow.rs | 16 +- src/test/ui/macros/macro-follow.stderr | 32 +- .../macros/macro-multiple-matcher-bindings.rs | 25 + .../macro-multiple-matcher-bindings.stderr | 37 + .../ui/macros/macro-reexport-removed.stderr | 2 +- src/test/ui/macros/meta-item-absolute-path.rs | 4 + .../ui/macros/meta-item-absolute-path.stderr | 9 + .../ui/malformed/malformed-derive-entry.rs | 2 +- .../malformed/malformed-derive-entry.stderr | 4 +- .../ui/malformed/malformed-interpolated.rs | 18 + .../malformed/malformed-interpolated.stderr | 31 + src/test/ui/malformed/malformed-plugin-1.rs | 2 +- .../ui/malformed/malformed-plugin-1.stderr | 5 +- src/test/ui/malformed/malformed-plugin-2.rs | 2 +- .../ui/malformed/malformed-plugin-2.stderr | 5 +- .../ui/malformed/malformed-regressions.rs | 8 + .../ui/malformed/malformed-regressions.stderr | 48 + .../ui/malformed/malformed-special-attrs.rs | 13 + .../malformed/malformed-special-attrs.stderr | 25 + .../marker-attribute-with-values.rs | 9 +- .../marker-attribute-with-values.stderr | 16 +- src/test/ui/match/match-ref-mut-stability.rs | 39 + src/test/ui/match/match-type-err-first-arm.rs | 45 + .../ui/match/match-type-err-first-arm.stderr | 53 + src/test/ui/missing/missing-stability.rs | 4 +- src/test/ui/missing/missing-stability.stderr | 6 +- .../moves/move-guard-same-consts.nll.stderr | 14 + src/test/ui/moves/move-in-guard-1.nll.stderr | 14 + src/test/ui/moves/move-in-guard-2.nll.stderr | 5 +- .../moves/move-into-dead-array-2.nll.stderr | 4 +- ...s-based-on-type-access-to-field.nll.stderr | 4 +- ...ased-on-type-capture-clause-bad.nll.stderr | 4 +- ...on-type-cyclic-types-issue-4821.nll.stderr | 2 +- ...type-distribute-copy-over-paren.nll.stderr | 8 +- .../moves-based-on-type-exprs.nll.stderr | 49 +- ...es-based-on-type-match-bindings.nll.stderr | 2 +- ...type-no-recursive-stack-closure.nll.stderr | 6 +- .../ui/moves/moves-based-on-type-tuple.stderr | 4 +- src/test/ui/nested-ty-params.rs | 2 +- src/test/ui/nested-ty-params.stderr | 12 +- src/test/ui/never-assign-dead-code.stderr | 2 +- src/test/ui/nll/closure-access-spans.stderr | 16 +- src/test/ui/nll/closure-move-spans.stderr | 12 +- .../escape-argument-callee.stderr | 2 +- .../issue-58127-mutliple-requirements.rs | 40 + ...pagate-approximated-fail-no-postdom.stderr | 2 +- .../propagate-approximated-ref.rs | 3 +- .../propagate-approximated-ref.stderr | 11 +- .../propagate-approximated-val.rs | 3 +- .../propagate-approximated-val.stderr | 11 +- ...ail-to-approximate-longer-no-bounds.stderr | 2 +- ...-to-approximate-longer-wrong-bounds.stderr | 2 +- ...n-lbr-named-does-not-outlive-static.stderr | 2 +- .../region-lbr1-does-not-outlive-ebr2.rs | 4 +- .../region-lbr1-does-not-outlive-ebr2.stderr | 2 +- .../return-wrong-bound-region.stderr | 2 +- src/test/ui/nll/closures-in-loops.stderr | 5 +- ...1232-partial-init-and-erroneous-use.stderr | 8 +- .../issue-21232-partial-init-and-use.stderr | 34 +- src/test/ui/nll/issue-48238.stderr | 2 +- src/test/ui/nll/issue-48697.rs | 4 +- src/test/ui/nll/issue-48697.stderr | 11 + src/test/ui/nll/issue-50716.stderr | 2 +- src/test/ui/nll/issue-51512.stderr | 4 +- src/test/ui/nll/issue-52113.rs | 9 +- src/test/ui/nll/issue-52113.stderr | 6 +- src/test/ui/nll/issue-52669.stderr | 5 +- src/test/ui/nll/issue-52742.rs | 6 +- src/test/ui/nll/issue-52742.stderr | 2 +- src/test/ui/nll/issue-53773.rs | 49 + src/test/ui/nll/issue-53773.stderr | 16 + src/test/ui/nll/issue-55394.rs | 2 +- src/test/ui/nll/issue-55394.stderr | 4 +- src/test/ui/nll/issue-55401.stderr | 2 +- src/test/ui/nll/issue-55850.rs | 12 +- src/test/ui/nll/issue-58053.rs | 14 + src/test/ui/nll/issue-58053.stderr | 20 + src/test/ui/nll/issue-58299.rs | 30 + src/test/ui/nll/issue-58299.stderr | 20 + src/test/ui/nll/match-cfg-fake-edges.rs | 58 + src/test/ui/nll/match-cfg-fake-edges.stderr | 34 + .../ui/nll/match-guards-partially-borrow.rs | 61 +- .../nll/match-guards-partially-borrow.stderr | 83 +- src/test/ui/nll/mir_check_cast_closure.rs | 2 +- src/test/ui/nll/mir_check_cast_closure.stderr | 2 +- src/test/ui/nll/mir_check_cast_reify.rs | 2 +- src/test/ui/nll/mir_check_cast_reify.stderr | 2 +- src/test/ui/nll/mir_check_cast_unsafe_fn.rs | 2 +- .../ui/nll/mir_check_cast_unsafe_fn.stderr | 2 +- src/test/ui/nll/mir_check_cast_unsize.rs | 2 +- src/test/ui/nll/mir_check_cast_unsize.stderr | 2 +- .../ui/nll/move-subpaths-moves-root.stderr | 2 +- src/test/ui/nll/promoted-bounds.rs | 27 + src/test/ui/nll/promoted-bounds.stderr | 15 + src/test/ui/nll/promoted-closure-pair.rs | 12 + src/test/ui/nll/promoted-closure-pair.stderr | 12 + .../projection-one-region-closure.stderr | 4 +- ...tion-one-region-trait-bound-closure.stderr | 4 +- ...ojection-two-region-trait-bound-closure.rs | 2 +- ...tion-two-region-trait-bound-closure.stderr | 4 +- ...ection-where-clause-env-wrong-bound.stderr | 2 +- .../projection-where-clause-none.stderr | 2 +- src/test/ui/nll/ty-outlives/wf-unreachable.rs | 54 + .../ui/nll/ty-outlives/wf-unreachable.stderr | 73 + .../ui/nll/type-alias-free-regions.stderr | 4 +- .../ui/nll/user-annotations/closure-substs.rs | 8 +- .../user-annotations/closure-substs.stderr | 12 +- .../constant-in-expr-inherent-1.stderr | 2 +- .../constant-in-expr-inherent-2.rs | 29 + .../constant-in-expr-inherent-2.stderr | 50 + .../constant-in-expr-normalize.stderr | 2 +- .../constant-in-expr-trait-item-1.stderr | 2 +- .../constant-in-expr-trait-item-2.stderr | 2 +- .../constant-in-expr-trait-item-3.stderr | 2 +- .../ui/nll/user-annotations/downcast-infer.rs | 11 + .../user-annotations/dump-adt-brace-struct.rs | 4 +- .../dump-adt-brace-struct.stderr | 8 +- .../ui/nll/user-annotations/dump-fn-method.rs | 19 +- .../user-annotations/dump-fn-method.stderr | 20 +- .../inherent-associated-constants.rs | 17 + .../inherent-associated-constants.stderr | 10 + .../ui/nll/user-annotations/issue-54124.rs | 4 +- .../nll/user-annotations/issue-54124.stderr | 8 +- .../ui/nll/user-annotations/issue-55241.rs | 2 +- .../issue-57731-ascibed-coupled-types.rs | 40 + .../issue-57731-ascibed-coupled-types.stderr | 38 + .../ui/nll/user-annotations/normalization.rs | 1 - .../nll/user-annotations/normalization.stderr | 2 +- .../ui/nll/user-annotations/patterns.stderr | 8 +- .../user-annotations/promoted-annotation.rs | 12 + .../promoted-annotation.stderr | 17 + .../ui/nll/user-annotations/wf-self-type.rs | 2 +- .../nll/user-annotations/wf-self-type.stderr | 4 +- src/test/ui/nll/where_clauses_in_functions.rs | 2 +- .../ui/nll/where_clauses_in_functions.stderr | 2 +- src/test/ui/nll/where_clauses_in_structs.rs | 2 +- .../ui/nll/where_clauses_in_structs.stderr | 2 +- src/test/ui/no-capture-arc.nll.stderr | 5 +- src/test/ui/no-reuse-move-arc.nll.stderr | 5 +- src/test/ui/no_crate_type.rs | 2 +- src/test/ui/no_crate_type.stderr | 6 +- .../ui/on-unimplemented/bad-annotation.rs | 5 +- .../ui/on-unimplemented/bad-annotation.stderr | 26 +- .../expected-comma-found-token.rs | 2 +- .../expected-comma-found-token.stderr | 14 +- src/test/ui/on-unimplemented/on-trait.rs | 2 +- .../ui/on-unimplemented/slice-index.stderr | 4 +- .../once-cant-call-twice-on-heap.nll.stderr | 15 + ...n.rs => parenthesized-deref-suggestion.rs} | 0 ... => parenthesized-deref-suggestion.stderr} | 4 +- src/test/ui/parser-recovery-2.stderr | 12 +- src/test/ui/parser/attr-bad-meta-2.stderr | 4 +- src/test/ui/parser/attr-bad-meta.rs | 2 - src/test/ui/parser/attr-bad-meta.stderr | 2 +- src/test/ui/parser/attr.rs | 3 +- src/test/ui/parser/attr.stderr | 11 +- src/test/ui/parser/bounds-lifetime.rs | 2 +- src/test/ui/parser/bounds-lifetime.stderr | 6 +- src/test/ui/parser/doc-before-eof.stderr | 2 +- .../ui/parser/doc-before-extern-rbrace.stderr | 2 +- .../ui/parser/doc-before-mod-rbrace.stderr | 2 +- src/test/ui/parser/issue-10636-2.rs | 2 +- src/test/ui/parser/issue-10636-2.stderr | 20 +- src/test/ui/parser/issue-14303-enum.stderr | 6 +- src/test/ui/parser/issue-14303-fn-def.stderr | 6 +- src/test/ui/parser/issue-14303-fncall.rs | 2 +- src/test/ui/parser/issue-14303-fncall.stderr | 8 +- src/test/ui/parser/issue-14303-impl.stderr | 6 +- src/test/ui/parser/issue-14303-path.rs | 2 +- src/test/ui/parser/issue-14303-path.stderr | 10 +- src/test/ui/parser/issue-14303-struct.stderr | 6 +- src/test/ui/parser/issue-14303-trait.stderr | 6 +- src/test/ui/parser/issue-17718-const-mut.rs | 2 +- .../ui/parser/issue-17718-const-mut.stderr | 6 +- src/test/ui/parser/issue-32214.rs | 2 +- src/test/ui/parser/issue-32214.stderr | 8 +- src/test/ui/parser/issue-33418.fixed | 14 + src/test/ui/parser/issue-33418.rs | 16 + src/test/ui/parser/issue-33418.stderr | 42 + src/test/ui/parser/lex-bad-char-literals-2.rs | 2 +- .../ui/parser/lex-bad-char-literals-2.stderr | 11 +- src/test/ui/parser/lex-bad-char-literals-3.rs | 12 +- .../ui/parser/lex-bad-char-literals-3.stderr | 24 +- src/test/ui/parser/lex-bad-char-literals-4.rs | 2 +- .../ui/parser/lex-bad-char-literals-4.stderr | 2 +- src/test/ui/parser/lex-bad-char-literals-5.rs | 13 +- .../ui/parser/lex-bad-char-literals-5.stderr | 24 +- src/test/ui/parser/lex-bad-char-literals-6.rs | 17 + .../ui/parser/lex-bad-char-literals-6.stderr | 47 + .../macro-mismatched-delim-paren-brace.stderr | 12 +- src/test/ui/parser/recover-enum2.rs | 3 - src/test/ui/parser/recover-enum2.stderr | 14 +- .../ui/parser/regions-out-of-scope-slice.rs | 4 +- .../parser/regions-out-of-scope-slice.stderr | 2 +- .../ui/parser/removed-syntax-uniq-mut-ty.rs | 2 +- .../parser/removed-syntax-uniq-mut-ty.stderr | 6 +- src/test/ui/parser/removed-syntax-with-1.rs | 3 +- .../ui/parser/removed-syntax-with-1.stderr | 15 +- src/test/ui/parser/removed-syntax-with-2.rs | 3 +- .../ui/parser/removed-syntax-with-2.stderr | 23 +- .../parser/struct-field-numeric-shorthand.rs | 7 +- .../struct-field-numeric-shorthand.stderr | 22 +- .../trait-object-lifetime-parens.stderr | 8 +- .../type-parameters-in-field-exprs.stderr | 12 +- .../ui/parser/unclosed-delimiter-in-dep.rs | 6 + .../parser/unclosed-delimiter-in-dep.stderr | 23 + src/test/ui/parser/unclosed_delim_mod.rs | 6 + src/test/ui/parser/unclosed_delim_mod.stderr | 18 + src/test/ui/parser/unicode-quote-chars.rs | 7 + src/test/ui/parser/unicode-quote-chars.stderr | 12 + ...o-type-err-cause-on-impl-trait-return-2.rs | 17 + ...pe-err-cause-on-impl-trait-return-2.stderr | 12 + ...-to-type-err-cause-on-impl-trait-return.rs | 36 + ...type-err-cause-on-impl-trait-return.stderr | 66 + .../ui/privacy/private-in-public-assoc-ty.rs | 9 +- .../privacy/private-in-public-assoc-ty.stderr | 20 +- .../privacy/private-in-public-existential.rs | 10 + src/test/ui/privacy/private-in-public-warn.rs | 2 + .../ui/privacy/private-in-public-warn.stderr | 65 +- src/test/ui/privacy/private-inferred-type.rs | 2 +- .../pub-priv-dep/auxiliary/priv_dep.rs | 2 + .../privacy/pub-priv-dep/auxiliary/pub_dep.rs | 1 + src/test/ui/privacy/pub-priv-dep/pub-priv1.rs | 46 + .../ui/privacy/pub-priv-dep/pub-priv1.stderr | 28 + src/test/ui/privacy/pub-priv-dep/std-pub.rs | 12 + src/test/ui/proc-macro/attribute.rs | 100 +- src/test/ui/proc-macro/attribute.stderr | 116 +- .../ui/proc-macro/attributes-included.stderr | 2 +- .../ui/proc-macro/derive-still-gated.stderr | 2 +- src/test/ui/proc-macro/invalid-attributes.rs | 12 +- .../ui/proc-macro/invalid-attributes.stderr | 24 +- .../ui/proc-macro/proc-macro-attributes.rs | 1 - .../proc-macro/proc-macro-attributes.stderr | 16 +- src/test/ui/proc-macro/proc-macro-gates.rs | 2 +- .../ui/proc-macro/proc-macro-gates.stderr | 4 +- src/test/ui/proc-macro/shadow-builtin.rs | 14 - src/test/ui/proc-macro/shadow-builtin.stderr | 8 - src/test/ui/proc-macro/shadow.stderr | 17 +- .../ui/proc-macro/span-preservation.stderr | 3 + src/test/ui/quote-with-interpolated.rs | 14 - src/test/ui/quote-with-interpolated.stderr | 40 - src/test/ui/ref-suggestion.nll.stderr | 10 +- ...n-supertrait-outlives-container.ast.stderr | 20 + ...n-supertrait-outlives-container.mir.stderr | 13 + ...c-type-in-supertrait-outlives-container.rs | 6 +- ...ons-free-region-ordering-caller.ast.stderr | 32 + ...ons-free-region-ordering-caller.mir.stderr | 33 + .../regions-free-region-ordering-caller.rs | 12 +- ...ns-free-region-ordering-caller1.nll.stderr | 19 +- ...lives-projection-container-hrtb.ast.stderr | 37 + ...lives-projection-container-hrtb.mir.stderr | 24 + ...ions-outlives-projection-container-hrtb.rs | 9 +- ...utlives-projection-container-wc.ast.stderr | 20 + ...utlives-projection-container-wc.mir.stderr | 13 + ...egions-outlives-projection-container-wc.rs | 6 +- .../regions/regions-static-bound.nll.stderr | 2 +- src/test/ui/regions/regions-static-bound.rs | 2 +- src/test/ui/repr.rs | 8 +- src/test/ui/repr.stderr | 27 +- src/test/ui/repr/repr-align.rs | 4 + src/test/ui/repr/repr-align.stderr | 14 +- .../ui/resolve/privacy-struct-ctor.stderr | 15 +- .../resolve-conflict-import-vs-import.stderr | 9 +- src/test/ui/resolve/resolve-hint-macro.stderr | 2 +- .../resolve-type-param-in-item-in-trait.rs | 8 +- ...resolve-type-param-in-item-in-trait.stderr | 24 +- ...uggest-path-instead-of-mod-dot-item.stderr | 36 +- src/test/ui/resolve/token-error-correct-3.rs | 18 +- .../ui/resolve/token-error-correct-3.stderr | 36 +- src/test/ui/resolve/token-error-correct.rs | 4 +- .../ui/resolve/token-error-correct.stderr | 9 +- .../ui/return/return-from-diverging.stderr | 2 + .../borrowck-issue-49631.nll.stderr | 2 +- .../invalid-attribute.rs | 2 +- .../invalid-attribute.stderr | 8 +- .../dbg-macro-move-semantics.nll.stderr | 3 +- .../empty_generics.rs | 2 +- .../empty_generics.stderr | 4 +- .../uniform-paths/auxiliary/cross-crate.rs | 5 + .../ui/rust-2018/uniform-paths/cross-crate.rs | 11 + .../uniform-paths/cross-crate.stderr | 26 + ...intrinsic-generic-arithmetic-saturating.rs | 38 + ...insic-generic-arithmetic-saturating.stderr | 15 + .../simd-intrinsic-generic-bitmask.rs | 90 + .../simd-intrinsic-generic-bitmask.stderr | 33 + src/test/ui/span/issue-24690.stderr | 2 +- src/test/ui/span/macro-ty-params.stderr | 8 +- ...egions-escape-loop-via-variable.nll.stderr | 2 +- .../regions-escape-loop-via-vec.nll.stderr | 8 +- src/test/ui/specialization/issue-39448.rs | 50 + src/test/ui/specialization/issue-39448.stderr | 12 + .../missing-stability-attr-at-top-level.rs | 4 + ...missing-stability-attr-at-top-level.stderr | 11 + .../stability-attribute-issue-43027.rs | 2 +- .../stability-attribute-issue-43027.stderr | 4 +- ...ity-attribute-non-staged-force-unstable.rs | 6 +- ...attribute-non-staged-force-unstable.stderr | 12 +- .../stability-attribute-non-staged.rs | 6 +- .../stability-attribute-non-staged.stderr | 12 +- .../stability-attribute-sanity-3.rs | 2 +- .../stability-attribute-sanity-3.stderr | 4 +- .../stability-attribute-sanity-4.rs | 29 + .../stability-attribute-sanity-4.stderr | 38 + .../stability-attribute-sanity.rs | 22 - .../stability-attribute-sanity.stderr | 64 +- src/test/ui/stability-in-private-module.rs | 4 + .../ui/stability-in-private-module.stderr | 9 + .../ui/static/static-drop-scope.nll.stderr | 14 +- src/test/ui/static/static-drop-scope.rs | 8 + src/test/ui/static/static-drop-scope.stderr | 14 +- src/test/ui/str/str-as-char.fixed | 4 +- src/test/ui/str/str-as-char.rs | 4 +- src/test/ui/str/str-as-char.stderr | 16 +- src/test/ui/str/str-idx.rs | 5 +- src/test/ui/str/str-idx.stderr | 40 +- src/test/ui/str/str-mut-idx.rs | 8 +- src/test/ui/str/str-mut-idx.stderr | 38 +- src/test/ui/suffixed-literal-meta.rs | 26 +- src/test/ui/suffixed-literal-meta.stderr | 72 +- src/test/ui/suggestions/as-ref.stderr | 16 +- src/test/ui/suggestions/attribute-typos.rs | 13 + .../ui/suggestions/attribute-typos.stderr | 27 + .../ui/suggestions/recover-invalid-float.rs | 11 + .../suggestions/recover-invalid-float.stderr | 42 + .../ui/suggestions/suggest-methods.stderr | 12 +- .../suggestions/suggest-move-lifetimes.stderr | 24 +- src/test/ui/suggestions/suggest-move-types.rs | 89 + .../ui/suggestions/suggest-move-types.stderr | 102 + .../type-mismatch-struct-field-shorthand-2.rs | 9 + ...e-mismatch-struct-field-shorthand-2.stderr | 30 + ...type-mismatch-struct-field-shorthand.fixed | 12 + .../type-mismatch-struct-field-shorthand.rs | 12 + ...ype-mismatch-struct-field-shorthand.stderr | 33 + src/test/ui/svh/auxiliary/svh-b.rs | 6 +- src/test/ui/tail-typeck.stderr | 4 +- src/test/ui/target-feature-gate.rs | 1 + src/test/ui/target-feature-gate.stderr | 2 +- src/test/ui/target-feature-wrong.stderr | 2 +- src/test/ui/test-should-panic-attr.rs | 3 +- src/test/ui/test-should-panic-attr.stderr | 16 +- src/test/ui/thread-local-mutation.nll.stderr | 9 + src/test/ui/thread-local-mutation.rs | 18 + src/test/ui/thread-local-mutation.stderr | 9 + src/test/ui/traits/auxiliary/trait_alias.rs | 3 + src/test/ui/traits/trait-alias-cross-crate.rs | 17 + .../ui/traits/trait-alias-cross-crate.stderr | 29 + src/test/ui/traits/trait-alias-syntax.rs | 7 + src/test/ui/traits/trait-alias-syntax.stderr | 14 + .../ui/traits/trait-object-vs-lifetime.rs | 2 +- .../ui/traits/trait-object-vs-lifetime.stderr | 8 +- src/test/ui/traits/trait-privacy.rs | 3 +- .../try-block/try-block-bad-lifetime.stderr | 5 +- .../ui/try-block/try-block-bad-type.stderr | 4 +- .../try-block/try-block-in-edition2015.stderr | 4 +- .../try-block-maybe-bad-lifetime.stderr | 5 +- .../ui/type-alias-enum-variants-priority-2.rs | 13 + ...type-alias-enum-variants-priority-2.stderr | 12 + .../ui/type-alias-enum-variants-priority-3.rs | 10 + ...type-alias-enum-variants-priority-3.stderr | 8 + .../ui/type-alias-enum-variants-priority.rs | 20 + .../type-alias-enum-variants-priority.stderr | 26 + src/test/ui/type/type-arg-out-of-scope.rs | 2 +- src/test/ui/type/type-arg-out-of-scope.stderr | 12 +- .../ui/type/type-dependent-def-issue-49241.rs | 2 +- .../type-dependent-def-issue-49241.stderr | 10 +- .../unboxed-closure-sugar-used-on-struct-1.rs | 3 +- ...oxed-closure-sugar-used-on-struct-1.stderr | 15 +- .../unboxed-closure-sugar-used-on-struct-3.rs | 2 +- ...oxed-closure-sugar-used-on-struct-3.stderr | 9 +- .../unboxed-closure-sugar-used-on-struct.rs | 4 +- ...nboxed-closure-sugar-used-on-struct.stderr | 12 +- ...nion-borrow-move-parent-sibling.nll.stderr | 12 +- src/test/ui/unop-move-semantics.nll.stderr | 6 +- .../unresolved-extern-mod-suggestion.stderr | 9 +- src/test/ui/unrestricted-attribute-tokens.rs | 4 +- src/test/ui/unsafe/ranged_ints2_const.stderr | 11 +- .../borrow-after-move.nll.stderr | 14 +- .../ui/unsized-locals/double-move.nll.stderr | 14 +- src/test/ui/use-self-in-inner-fn.rs | 4 +- src/test/ui/use-self-in-inner-fn.stderr | 4 +- .../use-after-move-based-on-type.nll.stderr | 4 +- ...r-move-implicity-coerced-object.nll.stderr | 5 +- ...e-after-move-self-based-on-type.nll.stderr | 4 +- .../ui/use/use-after-move-self.nll.stderr | 4 +- src/test/ui/use/use-mod.stderr | 9 +- .../use/use-nested-groups-unused-imports.rs | 2 +- .../use-nested-groups-unused-imports.stderr | 6 +- src/test/ui/use/use-paths-as-items.stderr | 9 +- src/test/ui/utf8_idents.rs | 4 +- src/test/ui/utf8_idents.stderr | 14 +- .../ui/vec/vec-mut-iter-borrow.nll.stderr | 2 +- .../ui/walk-struct-literal-with.nll.stderr | 4 +- src/test/ui/wrong-ret-type.stderr | 4 +- src/tools/build-manifest/Cargo.toml | 3 +- src/tools/build-manifest/src/main.rs | 12 +- src/tools/cargotest/Cargo.toml | 1 + src/tools/cargotest/main.rs | 2 + src/tools/compiletest/Cargo.toml | 1 + src/tools/compiletest/src/common.rs | 33 +- src/tools/compiletest/src/errors.rs | 2 +- src/tools/compiletest/src/header.rs | 21 +- src/tools/compiletest/src/json.rs | 4 +- src/tools/compiletest/src/main.rs | 85 +- src/tools/compiletest/src/read2.rs | 11 +- src/tools/compiletest/src/runtest.rs | 168 +- src/tools/compiletest/src/util.rs | 11 +- src/tools/error_index_generator/Cargo.toml | 1 + src/tools/error_index_generator/main.rs | 25 +- src/tools/linkchecker/Cargo.toml | 1 + src/tools/linkchecker/main.rs | 14 +- src/tools/publish_toolstate.py | 90 +- src/tools/rust-installer/Cargo.toml | 1 + src/tools/rust-installer/src/combiner.rs | 10 +- src/tools/rust-installer/src/generator.rs | 6 +- src/tools/rust-installer/src/lib.rs | 15 +- src/tools/rust-installer/src/main.rs | 12 +- .../rust-installer/src/remove_dir_all.rs | 44 +- src/tools/rust-installer/src/scripter.rs | 6 +- src/tools/rust-installer/src/tarballer.rs | 4 +- src/tools/rust-installer/src/util.rs | 4 +- src/tools/rustbook/Cargo.toml | 10 +- src/tools/rustbook/src/main.rs | 72 +- src/tools/rustc-std-workspace-core/Cargo.toml | 1 + src/tools/rustc-std-workspace-core/lib.rs | 3 +- src/tools/rustc-workspace-hack/Cargo.toml | 6 +- src/tools/rustdoc-js-std/tester.js | 344 ++ src/tools/rustdoc-js/tester.js | 50 +- src/tools/rustdoc-themes/Cargo.toml | 1 + src/tools/rustdoc-themes/main.rs | 2 + src/tools/rustdoc/Cargo.toml | 1 + src/tools/rustdoc/main.rs | 4 +- src/tools/tidy/src/bins.rs | 6 +- src/tools/tidy/src/cargo.rs | 26 +- src/tools/tidy/src/deps.rs | 55 +- src/tools/tidy/src/errors.rs | 4 +- src/tools/tidy/src/extdeps.rs | 19 +- src/tools/tidy/src/features.rs | 25 +- src/tools/tidy/src/lib.rs | 3 +- src/tools/tidy/src/main.rs | 3 +- src/tools/tidy/src/pal.rs | 41 +- src/tools/tidy/src/style.rs | 40 +- src/tools/tidy/src/ui_tests.rs | 6 +- src/tools/tidy/src/unstable_book.rs | 33 +- src/tools/unstable-book-gen/Cargo.toml | 1 + src/tools/unstable-book-gen/src/main.rs | 3 +- vendor/arrayref/.cargo-checksum.json | 1 + vendor/arrayref/Cargo.toml | 22 + vendor/arrayref/LICENSE | 26 + vendor/arrayref/README.md | 109 + vendor/arrayref/examples/array_refs.rs | 13 + .../examples/array_refs_with_const.rs | 18 + vendor/arrayref/examples/simple-case.rs | 15 + vendor/arrayref/src/lib.rs | 472 ++ vendor/block-buffer/.cargo-checksum.json | 1 + vendor/block-buffer/Cargo.toml | 27 + .../LICENSE-APACHE | 2 +- .../LICENSE-MIT | 2 +- vendor/block-buffer/src/lib.rs | 144 + vendor/block-buffer/src/paddings.rs | 129 + vendor/byte-tools/.cargo-checksum.json | 1 + .../Cargo.toml | 16 +- vendor/byte-tools/LICENSE-APACHE | 201 + .../LICENSE-MIT | 4 +- vendor/byte-tools/src/lib.rs | 37 + vendor/byte-tools/src/read_single.rs | 38 + vendor/byte-tools/src/read_slice.rs | 44 + vendor/byte-tools/src/write_single.rs | 39 + vendor/byte-tools/src/write_slice.rs | 46 + vendor/compiler_builtins/.cargo-checksum.json | 2 +- vendor/compiler_builtins/Cargo.toml | 2 +- vendor/compiler_builtins/build.rs | 4 +- vendor/compiler_builtins/src/int/mod.rs | 65 + .../.cargo-checksum.json | 0 .../CHANGELOG.md | 0 .../Cargo.toml | 0 .../LICENSE-APACHE | 0 .../LICENSE-MIT | 0 .../README.md | 0 .../src/lib.rs | 0 vendor/digest/.cargo-checksum.json | 1 + vendor/digest/Cargo.toml | 32 + vendor/digest/LICENSE-APACHE | 201 + vendor/{syn-0.11.11 => digest}/LICENSE-MIT | 2 +- vendor/digest/src/dev.rs | 171 + vendor/digest/src/digest.rs | 86 + vendor/digest/src/errors.rs | 37 + vendor/digest/src/lib.rs | 98 + vendor/dlmalloc/.cargo-checksum.json | 2 +- vendor/dlmalloc/Cargo.toml | 2 +- vendor/dlmalloc/src/lib.rs | 1 - vendor/dlmalloc/src/wasm.rs | 11 +- .../error-chain-0.11.0/.cargo-checksum.json | 1 - vendor/error-chain-0.11.0/CHANGELOG.md | 120 - vendor/error-chain-0.11.0/README.md | 36 - vendor/error-chain-0.11.0/examples/all.rs | 36 - .../error-chain-0.11.0/examples/chain_err.rs | 69 - vendor/error-chain-0.11.0/examples/doc.rs | 28 - .../error-chain-0.11.0/examples/quickstart.rs | 80 - vendor/error-chain-0.11.0/examples/size.rs | 38 - .../src/bin/has_backtrace.rs | 18 - vendor/error-chain-0.11.0/src/error_chain.rs | 458 -- .../src/example_generated.rs | 38 - .../src/impl_error_chain_kind.rs | 541 -- vendor/error-chain-0.11.0/src/lib.rs | 865 --- vendor/error-chain-0.11.0/src/quick_main.rs | 77 - vendor/error-chain-0.11.0/tests/quick_main.rs | 28 - vendor/error-chain-0.11.0/tests/tests.rs | 628 -- vendor/failure/.cargo-checksum.json | 2 +- vendor/failure/Cargo.lock.ci | 136 + vendor/failure/Cargo.toml | 6 +- vendor/failure/RELEASES.md | 13 + vendor/failure/book/src/error-errorkind.md | 6 +- vendor/failure/book/src/error-msg.md | 4 +- vendor/failure/book/src/fail.md | 2 +- vendor/failure/book/src/intro.md | 2 +- .../failure/book/src/string-custom-error.md | 8 + vendor/failure/examples/simple.rs | 4 +- vendor/failure/src/backtrace/mod.rs | 4 +- vendor/failure/src/compat.rs | 6 + vendor/failure/src/context.rs | 4 + vendor/failure/src/error/mod.rs | 5 + vendor/failure/src/error_message.rs | 6 +- vendor/failure/src/lib.rs | 25 +- vendor/failure/src/macros.rs | 8 +- vendor/failure/tests/basic_fail.rs | 21 + vendor/failure/tests/fail_compat.rs | 35 + vendor/failure/tests/macro_trailing_comma.rs | 54 + vendor/failure_derive/.cargo-checksum.json | 2 +- vendor/failure_derive/Cargo.toml | 6 +- vendor/failure_derive/src/lib.rs | 133 +- vendor/failure_derive/tests/wraps.rs | 45 +- vendor/fake-simd/.cargo-checksum.json | 1 + vendor/fake-simd/Cargo.toml | 9 + vendor/fake-simd/LICENSE-APACHE | 201 + vendor/fake-simd/LICENSE-MIT | 26 + vendor/fake-simd/src/lib.rs | 108 + vendor/generic-array/.cargo-checksum.json | 1 + vendor/generic-array/Cargo.toml | 32 + vendor/generic-array/LICENSE | 21 + vendor/generic-array/README.md | 34 + vendor/generic-array/rustfmt.toml | 3 + vendor/generic-array/src/arr.rs | 57 + vendor/generic-array/src/hex.rs | 101 + vendor/generic-array/src/impl_serde.rs | 68 + vendor/generic-array/src/impls.rs | 171 + vendor/generic-array/src/iter.rs | 117 + vendor/generic-array/src/lib.rs | 464 ++ vendor/generic-array/tests/hex.rs | 44 + vendor/generic-array/tests/import_name.rs | 10 + vendor/generic-array/tests/mod.rs | 169 + vendor/handlebars/.cargo-checksum.json | 2 +- vendor/handlebars/CHANGELOG.md | 36 + vendor/handlebars/Cargo.toml | 41 +- vendor/handlebars/README.md | 64 +- vendor/handlebars/benches/bench.rs | 8 +- vendor/handlebars/examples/decorator.rs | 116 +- vendor/handlebars/examples/error.rs | 127 +- vendor/handlebars/examples/partials.rs | 37 +- vendor/handlebars/examples/quick.rs | 13 +- vendor/handlebars/examples/render-cli.rs | 15 +- vendor/handlebars/examples/render.rs | 86 +- vendor/handlebars/examples/render_file.rs | 91 +- vendor/handlebars/release.toml | 6 +- vendor/handlebars/src/context.rs | 124 +- vendor/handlebars/src/directives/inline.rs | 45 +- vendor/handlebars/src/directives/mod.rs | 143 +- vendor/handlebars/src/error.rs | 26 +- vendor/handlebars/src/grammar.pest | 26 +- vendor/handlebars/src/grammar.rs | 2 + .../handlebars/src/helpers/helper_boolean.rs | 59 + vendor/handlebars/src/helpers/helper_each.rs | 53 +- vendor/handlebars/src/helpers/helper_if.rs | 68 +- vendor/handlebars/src/helpers/helper_log.rs | 57 +- .../handlebars/src/helpers/helper_lookup.rs | 31 +- vendor/handlebars/src/helpers/helper_raw.rs | 13 +- vendor/handlebars/src/helpers/helper_with.rs | 30 +- vendor/handlebars/src/helpers/mod.rs | 154 +- vendor/handlebars/src/lib.rs | 146 +- vendor/handlebars/src/macros.rs | 133 + vendor/handlebars/src/output.rs | 45 + vendor/handlebars/src/partial.rs | 76 +- vendor/handlebars/src/registry.rs | 403 +- vendor/handlebars/src/render.rs | 961 +-- vendor/handlebars/src/support.rs | 16 +- vendor/handlebars/src/template.rs | 425 +- vendor/handlebars/src/value.rs | 167 + vendor/handlebars/tests/helper_macro.rs | 31 + vendor/handlebars/tests/subexpression.rs | 57 +- .../.cargo-checksum.json | 0 .../{itertools => itertools-0.7.8}/Cargo.toml | 0 .../LICENSE-APACHE | 0 .../LICENSE-MIT | 0 .../{itertools => itertools-0.7.8}/Makefile | 0 .../{itertools => itertools-0.7.8}/README.rst | 0 .../benches/bench1.rs | 0 .../benches/extra/mod.rs | 0 .../benches/extra/zipslices.rs | 0 .../benches/tree_fold1.rs | 0 .../benches/tuple_combinations.rs | 0 .../benches/tuples.rs | 0 .../{itertools => itertools-0.7.8}/bors.toml | 0 .../{itertools => itertools-0.7.8}/custom.css | 0 .../examples/iris.data | 0 .../examples/iris.rs | 0 .../src/adaptors/mod.rs | 0 .../src/adaptors/multi_product.rs | 0 .../src/combinations.rs | 0 .../src/concat_impl.rs | 0 .../src/cons_tuples_impl.rs | 0 .../src/diff.rs | 0 .../src/either_or_both.rs | 0 .../src/format.rs | 0 .../src/free.rs | 0 .../src/group_map.rs | 0 .../src/groupbylazy.rs | 0 .../src/impl_macros.rs | 0 .../src/intersperse.rs | 0 .../src/kmerge_impl.rs | 0 .../{itertools => itertools-0.7.8}/src/lib.rs | 0 .../src/merge_join.rs | 0 .../src/minmax.rs | 0 .../src/multipeek_impl.rs | 0 .../src/pad_tail.rs | 0 .../src/peeking_take_while.rs | 0 .../src/process_results_impl.rs | 0 .../src/put_back_n_impl.rs | 0 .../src/rciter_impl.rs | 0 .../src/repeatn.rs | 0 .../src/size_hint.rs | 0 .../src/sources.rs | 0 .../{itertools => itertools-0.7.8}/src/tee.rs | 0 .../src/tuple_impl.rs | 0 .../src/unique_impl.rs | 0 .../src/with_position.rs | 0 .../src/zip_eq_impl.rs | 0 .../src/zip_longest.rs | 0 .../src/ziptuple.rs | 0 .../tests/merge_join.rs | 0 .../tests/peeking_take_while.rs | 0 .../tests/quick.rs | 0 .../tests/test_core.rs | 0 .../tests/test_std.rs | 0 .../tests/tuples.rs | 0 .../tests/zip.rs | 0 vendor/mdbook/.cargo-checksum.json | 2 +- vendor/mdbook/CONTRIBUTING.md | 54 +- vendor/mdbook/Cargo.toml | 39 +- vendor/mdbook/README.md | 55 +- vendor/mdbook/appveyor.yml | 13 +- vendor/mdbook/build.rs | 98 - vendor/mdbook/ci/before_deploy.sh | 5 +- vendor/mdbook/ci/github_pages.sh | 50 - vendor/mdbook/ci/install.sh | 47 - vendor/mdbook/examples/de-emphasize.rs | 112 +- vendor/mdbook/examples/nop-preprocessor.rs | 108 + vendor/mdbook/release.toml | 3 + vendor/mdbook/rustfmt.toml | 7 - vendor/mdbook/src/bin/serve.rs | 117 - vendor/mdbook/src/bin/test.rs | 26 - vendor/mdbook/src/book/book.rs | 59 +- vendor/mdbook/src/book/init.rs | 27 +- vendor/mdbook/src/book/mod.rs | 236 +- vendor/mdbook/src/book/summary.rs | 116 +- vendor/mdbook/src/{bin => cmd}/build.rs | 21 +- vendor/mdbook/src/{bin => cmd}/clean.rs | 20 +- vendor/mdbook/src/{bin => cmd}/init.rs | 21 +- vendor/mdbook/src/cmd/mod.rs | 10 + vendor/mdbook/src/cmd/serve.rs | 150 + vendor/mdbook/src/cmd/test.rs | 46 + vendor/mdbook/src/{bin => cmd}/watch.rs | 24 +- vendor/mdbook/src/config.rs | 83 +- vendor/mdbook/src/lib.rs | 12 +- vendor/mdbook/src/{bin/mdbook.rs => main.rs} | 66 +- vendor/mdbook/src/preprocess/cmd.rs | 197 + vendor/mdbook/src/preprocess/index.rs | 99 + vendor/mdbook/src/preprocess/links.rs | 283 +- vendor/mdbook/src/preprocess/mod.rs | 37 +- .../renderer/html_handlebars/hbs_renderer.rs | 474 +- .../renderer/html_handlebars/helpers/mod.rs | 3 +- .../html_handlebars/helpers/navigation.rs | 68 +- .../renderer/html_handlebars/helpers/theme.rs | 30 + .../renderer/html_handlebars/helpers/toc.rs | 73 +- .../src/renderer/html_handlebars/search.rs | 74 +- vendor/mdbook/src/renderer/mod.rs | 50 +- vendor/mdbook/src/theme/book.css | 1459 ----- vendor/mdbook/src/theme/book.js | 85 +- vendor/mdbook/src/theme/css/chrome.css | 420 ++ vendor/mdbook/src/theme/css/general.css | 144 + vendor/mdbook/src/theme/css/print.css | 54 + vendor/mdbook/src/theme/css/variables.css | 210 + vendor/mdbook/src/theme/index.hbs | 114 +- vendor/mdbook/src/theme/mod.rs | 92 +- vendor/mdbook/src/theme/searcher/searcher.js | 46 +- vendor/mdbook/src/utils/fs.rs | 10 +- vendor/mdbook/src/utils/mod.rs | 211 +- vendor/mdbook/src/utils/string.rs | 4 +- vendor/mdbook/tests/alternate_backends.rs | 28 +- vendor/mdbook/tests/build_process.rs | 80 + vendor/mdbook/tests/custom_preprocessors.rs | 58 + vendor/mdbook/tests/dummy_book/mod.rs | 58 +- vendor/mdbook/tests/dummy_book/src/README.md | 5 + vendor/mdbook/tests/dummy_book/src/SUMMARY.md | 3 + .../tests/dummy_book/src/first/recursive.md | 2 + .../tests/dummy_book/src/second/nested.md | 4 + vendor/mdbook/tests/dummy_book/src2/README.md | 1 + .../mdbook/tests/dummy_book/src2/SUMMARY.md | 7 + .../tests/dummy_book/src2/first/README.md | 1 + .../tests/dummy_book/src2/second/README.md | 1 + .../tests/dummy_book/src2/second/index.md | 1 + vendor/mdbook/tests/init.rs | 7 +- .../tests/parse_existing_summary_files.rs | 2 +- vendor/mdbook/tests/rendered_output.rs | 163 +- vendor/mdbook/tests/searchindex_fixture.json | 1185 +++- vendor/mdbook/tests/testing.rs | 36 +- vendor/minifier/.cargo-checksum.json | 2 +- vendor/minifier/Cargo.toml | 2 +- vendor/minifier/src/js/js.rs | 590 +- vendor/minifier/src/js/mod.rs | 26 +- vendor/minifier/src/js/token.rs | 219 +- vendor/minifier/src/js/utils.rs | 478 ++ vendor/minifier/src/json/read/byte_to_char.rs | 2 +- vendor/parking_lot/.cargo-checksum.json | 2 +- vendor/parking_lot/CHANGELOG.md | 11 + vendor/parking_lot/Cargo.toml | 6 +- vendor/parking_lot/README.md | 5 + vendor/parking_lot/appveyor.yml | 2 +- vendor/parking_lot/src/condvar.rs | 190 +- vendor/parking_lot/src/elision.rs | 12 +- vendor/parking_lot/src/lib.rs | 1 + vendor/parking_lot/src/mutex.rs | 3 +- vendor/parking_lot/src/once.rs | 8 +- vendor/parking_lot/src/raw_mutex.rs | 5 +- vendor/parking_lot/src/raw_rwlock.rs | 37 +- vendor/parking_lot/src/remutex.rs | 8 +- vendor/parking_lot/src/rwlock.rs | 18 +- vendor/parking_lot/src/util.rs | 12 + vendor/parking_lot_core/.cargo-checksum.json | 2 +- vendor/parking_lot_core/Cargo.toml | 6 +- .../LICENSE-APACHE | 0 .../LICENSE-MIT | 0 vendor/parking_lot_core/build.rs | 8 + vendor/parking_lot_core/src/lib.rs | 5 +- vendor/parking_lot_core/src/parking_lot.rs | 83 +- .../src/thread_parker/unix.rs | 12 +- .../src/thread_parker/windows/waitaddress.rs | 3 +- vendor/parking_lot_core/src/word_lock.rs | 19 +- vendor/pest/.cargo-checksum.json | 2 +- vendor/pest/Cargo.toml | 5 +- vendor/pest/_README.md | 155 +- vendor/pest/examples/parens.rs | 59 +- vendor/pest/src/error.rs | 772 ++- vendor/pest/src/iterators/flat_pairs.rs | 87 +- vendor/pest/src/iterators/mod.rs | 2 +- vendor/pest/src/iterators/pair.rs | 128 +- vendor/pest/src/iterators/pairs.rs | 198 +- vendor/pest/src/iterators/queueable_token.rs | 11 +- vendor/pest/src/iterators/tokens.rs | 120 +- vendor/pest/src/lib.rs | 87 +- vendor/pest/src/macros.rs | 102 +- vendor/pest/src/parser.rs | 6 +- vendor/pest/src/parser_state.rs | 1050 +++- vendor/pest/src/position.rs | 769 +-- vendor/pest/src/prec_climber.rs | 43 +- vendor/pest/src/span.rs | 220 +- vendor/pest/src/stack.rs | 214 + vendor/pest/src/token.rs | 8 +- vendor/pest/src/unicode/binary.rs | 4933 +++++++++++++++ vendor/pest/src/unicode/category.rs | 3549 +++++++++++ vendor/pest/src/unicode/mod.rs | 66 + vendor/pest/tests/calculator.rs | 139 +- vendor/pest/tests/json.rs | 405 +- vendor/pest_derive/.cargo-checksum.json | 2 +- vendor/pest_derive/Cargo.toml | 12 +- vendor/pest_derive/_README.md | 155 +- vendor/pest_derive/src/generator.rs | 1034 ---- vendor/pest_derive/src/lib.rs | 330 +- vendor/pest_derive/src/optimizer.rs | 356 -- vendor/pest_derive/src/parser.rs | 1748 ------ vendor/pest_derive/src/validator.rs | 603 -- vendor/pest_derive/tests/grammar.pest | 52 +- vendor/pest_derive/tests/grammar.rs | 242 + vendor/pest_derive/tests/grammar_inline.rs | 26 + vendor/pest_derive/tests/lists.pest | 18 + vendor/pest_derive/tests/lists.rs | 121 + vendor/pest_derive/tests/reporting.pest | 2 +- vendor/pest_generator/.cargo-checksum.json | 1 + vendor/pest_generator/Cargo.toml | 46 + .../LICENSE-APACHE | 0 vendor/pest_generator/LICENSE-MIT | 23 + vendor/pest_generator/_README.md | 167 + vendor/pest_generator/src/generator.rs | 991 +++ vendor/pest_generator/src/lib.rs | 208 + vendor/pest_generator/src/macros.rs | 44 + vendor/pest_meta/.cargo-checksum.json | 1 + vendor/pest_meta/Cargo.toml | 41 + .../{syn-0.11.11 => pest_meta}/LICENSE-APACHE | 0 vendor/pest_meta/LICENSE-MIT | 23 + vendor/pest_meta/_README.md | 167 + vendor/{pest_derive => pest_meta}/src/ast.rs | 152 +- vendor/pest_meta/src/grammar.pest | 98 + vendor/pest_meta/src/grammar.rs | 2 + vendor/pest_meta/src/lib.rs | 134 + .../pest_meta/src/optimizer/concatenator.rs | 34 + vendor/pest_meta/src/optimizer/factorizer.rs | 38 + vendor/pest_meta/src/optimizer/mod.rs | 510 ++ vendor/pest_meta/src/optimizer/restorer.rs | 157 + vendor/pest_meta/src/optimizer/rotater.rs | 45 + vendor/pest_meta/src/optimizer/skipper.rs | 57 + vendor/pest_meta/src/optimizer/unroller.rs | 67 + vendor/pest_meta/src/parser.rs | 1488 +++++ vendor/pest_meta/src/validator.rs | 851 +++ vendor/quote-0.3.15/.cargo-checksum.json | 1 - vendor/quote-0.3.15/Cargo.toml | 10 - vendor/quote-0.3.15/README.md | 104 - vendor/quote-0.3.15/src/ident.rs | 57 - vendor/quote-0.3.15/src/lib.rs | 252 - vendor/quote-0.3.15/src/to_tokens.rs | 357 -- vendor/quote-0.3.15/src/tokens.rs | 156 - vendor/quote-0.3.15/tests/test.rs | 360 -- vendor/regex-0.2.11/.cargo-checksum.json | 1 - vendor/regex-0.2.11/CHANGELOG.md | 445 -- vendor/regex-0.2.11/Cargo.toml | 100 - vendor/regex-0.2.11/HACKING.md | 330 - vendor/regex-0.2.11/PERFORMANCE.md | 279 - vendor/regex-0.2.11/README.md | 222 - vendor/regex-0.2.11/UNICODE.md | 250 - vendor/regex-0.2.11/appveyor.yml | 19 - vendor/regex-0.2.11/build.rs | 27 - vendor/regex-0.2.11/ci/after_success.sh | 25 - vendor/regex-0.2.11/ci/run-kcov | 44 - vendor/regex-0.2.11/ci/run-shootout-test | 18 - vendor/regex-0.2.11/ci/script.sh | 46 - .../regex-0.2.11/examples/regexdna-input.txt | 1671 ----- .../regex-0.2.11/examples/regexdna-output.txt | 13 - .../examples/shootout-regex-dna-bytes.rs | 66 - .../examples/shootout-regex-dna-cheat.rs | 88 - .../examples/shootout-regex-dna-replace.rs | 19 - .../shootout-regex-dna-single-cheat.rs | 73 - .../examples/shootout-regex-dna-single.rs | 55 - .../examples/shootout-regex-dna.rs | 66 - vendor/regex-0.2.11/scripts/frequencies.py | 82 - .../regex-0.2.11/scripts/regex-match-tests.py | 107 - vendor/regex-0.2.11/src/backtrack.rs | 302 - vendor/regex-0.2.11/src/compile.rs | 1151 ---- vendor/regex-0.2.11/src/dfa.rs | 1894 ------ vendor/regex-0.2.11/src/error.rs | 92 - vendor/regex-0.2.11/src/exec.rs | 1352 ----- vendor/regex-0.2.11/src/expand.rs | 215 - vendor/regex-0.2.11/src/freqs.rs | 271 - vendor/regex-0.2.11/src/input.rs | 420 -- vendor/regex-0.2.11/src/lib.rs | 672 --- vendor/regex-0.2.11/src/literal/mod.rs | 1141 ---- .../src/literal/teddy_avx2/fallback.rs | 20 - .../src/literal/teddy_avx2/imp.rs | 468 -- .../src/literal/teddy_avx2/mod.rs | 16 - .../src/literal/teddy_ssse3/fallback.rs | 20 - .../src/literal/teddy_ssse3/imp.rs | 776 --- .../src/literal/teddy_ssse3/mod.rs | 16 - vendor/regex-0.2.11/src/pattern.rs | 62 - vendor/regex-0.2.11/src/pikevm.rs | 377 -- vendor/regex-0.2.11/src/prog.rs | 425 -- vendor/regex-0.2.11/src/re_builder.rs | 346 -- vendor/regex-0.2.11/src/re_bytes.rs | 1072 ---- vendor/regex-0.2.11/src/re_set.rs | 423 -- vendor/regex-0.2.11/src/re_trait.rs | 268 - vendor/regex-0.2.11/src/re_unicode.rs | 1116 ---- vendor/regex-0.2.11/src/sparse.rs | 78 - vendor/regex-0.2.11/src/testdata/LICENSE | 19 - vendor/regex-0.2.11/src/testdata/README | 17 - vendor/regex-0.2.11/src/testdata/basic.dat | 221 - .../regex-0.2.11/src/testdata/nullsubexpr.dat | 79 - .../regex-0.2.11/src/testdata/repetition.dat | 163 - vendor/regex-0.2.11/src/utf8.rs | 290 - vendor/regex-0.2.11/src/vector/avx2.rs | 195 - vendor/regex-0.2.11/src/vector/mod.rs | 4 - vendor/regex-0.2.11/src/vector/ssse3.rs | 200 - vendor/regex-0.2.11/tests/api.rs | 182 - vendor/regex-0.2.11/tests/api_str.rs | 31 - vendor/regex-0.2.11/tests/bytes.rs | 62 - vendor/regex-0.2.11/tests/crazy.rs | 401 -- vendor/regex-0.2.11/tests/flags.rs | 11 - vendor/regex-0.2.11/tests/fowler.rs | 371 -- vendor/regex-0.2.11/tests/macros.rs | 149 - vendor/regex-0.2.11/tests/macros_bytes.rs | 38 - vendor/regex-0.2.11/tests/macros_str.rs | 35 - vendor/regex-0.2.11/tests/misc.rs | 14 - vendor/regex-0.2.11/tests/multiline.rs | 49 - vendor/regex-0.2.11/tests/noparse.rs | 50 - vendor/regex-0.2.11/tests/regression.rs | 99 - vendor/regex-0.2.11/tests/replace.rs | 44 - vendor/regex-0.2.11/tests/searcher.rs | 66 - vendor/regex-0.2.11/tests/set.rs | 32 - vendor/regex-0.2.11/tests/shortest_match.rs | 14 - vendor/regex-0.2.11/tests/suffix_reverse.rs | 16 - vendor/regex-0.2.11/tests/test_backtrack.rs | 64 - .../tests/test_backtrack_bytes.rs | 65 - .../tests/test_backtrack_utf8bytes.rs | 65 - vendor/regex-0.2.11/tests/test_default.rs | 77 - .../regex-0.2.11/tests/test_default_bytes.rs | 73 - vendor/regex-0.2.11/tests/test_nfa.rs | 60 - vendor/regex-0.2.11/tests/test_nfa_bytes.rs | 65 - .../regex-0.2.11/tests/test_nfa_utf8bytes.rs | 61 - vendor/regex-0.2.11/tests/unicode.rs | 110 - vendor/regex-0.2.11/tests/word_boundary.rs | 89 - .../regex-0.2.11/tests/word_boundary_ascii.rs | 9 - .../tests/word_boundary_unicode.rs | 8 - .../regex-syntax-0.5.6/.cargo-checksum.json | 1 - vendor/regex-syntax-0.5.6/benches/bench.rs | 73 - vendor/regex-syntax-0.5.6/src/ast/mod.rs | 1515 ----- vendor/regex-syntax-0.5.6/src/ast/parse.rs | 5365 ----------------- vendor/regex-syntax-0.5.6/src/ast/print.rs | 586 -- vendor/regex-syntax-0.5.6/src/ast/visitor.rs | 557 -- vendor/regex-syntax-0.5.6/src/either.rs | 8 - vendor/regex-syntax-0.5.6/src/error.rs | 297 - vendor/regex-syntax-0.5.6/src/hir/interval.rs | 490 -- .../regex-syntax-0.5.6/src/hir/literal/mod.rs | 1553 ----- vendor/regex-syntax-0.5.6/src/hir/mod.rs | 2055 ------- vendor/regex-syntax-0.5.6/src/hir/print.rs | 359 -- .../regex-syntax-0.5.6/src/hir/translate.rs | 2537 -------- vendor/regex-syntax-0.5.6/src/hir/visitor.rs | 222 - vendor/regex-syntax-0.5.6/src/lib.rs | 222 - vendor/regex-syntax-0.5.6/src/parser.rs | 206 - vendor/regex-syntax-0.5.6/src/unicode.rs | 472 -- .../src/unicode_tables/age.rs | 424 -- .../src/unicode_tables/case_folding_simple.rs | 662 -- .../src/unicode_tables/general_category.rs | 1844 ------ .../src/unicode_tables/mod.rs | 9 - .../src/unicode_tables/perl_word.rs | 179 - .../src/unicode_tables/property_bool.rs | 2576 -------- .../src/unicode_tables/property_names.rs | 145 - .../src/unicode_tables/property_values.rs | 277 - .../src/unicode_tables/script.rs | 765 --- .../src/unicode_tables/script_extension.rs | 785 --- vendor/rls-data/.cargo-checksum.json | 2 +- vendor/rls-data/Cargo.toml | 6 +- vendor/rls-span/.cargo-checksum.json | 2 +- vendor/rls-span/Cargo.toml | 36 +- vendor/rls-span/src/compiler.rs | 15 +- vendor/rls-span/src/lib.rs | 78 +- vendor/sha-1/.cargo-checksum.json | 1 + .../{error-chain-0.11.0 => sha-1}/Cargo.toml | 42 +- vendor/sha-1/LICENSE-APACHE | 201 + vendor/sha-1/LICENSE-MIT | 27 + vendor/sha-1/benches/lib.rs | 7 + vendor/sha-1/examples/sha1sum.rs | 49 + vendor/sha-1/src/consts.rs | 19 + vendor/sha-1/src/lib.rs | 120 + vendor/sha-1/src/utils.rs | 296 + .../sha-1/tests/data/one_million_a.output.bin | 1 + vendor/sha-1/tests/data/test1.input.bin | 1 + vendor/sha-1/tests/data/test1.output.bin | 1 + vendor/sha-1/tests/data/test2.input.bin | 1 + vendor/sha-1/tests/data/test2.output.bin | 1 + vendor/sha-1/tests/data/test3.input.bin | 1 + vendor/sha-1/tests/data/test3.output.bin | 1 + vendor/sha-1/tests/data/test4.input.bin | 1 + vendor/sha-1/tests/data/test4.output.bin | 1 + vendor/sha-1/tests/lib.rs | 19 + vendor/syn-0.11.11/.cargo-checksum.json | 1 - vendor/syn-0.11.11/Cargo.toml | 30 - vendor/syn-0.11.11/README.md | 205 - vendor/syn-0.11.11/src/aster/generics.rs | 231 - vendor/syn-0.11.11/src/aster/ident.rs | 39 - vendor/syn-0.11.11/src/aster/invoke.rs | 16 - vendor/syn-0.11.11/src/aster/lifetime.rs | 103 - vendor/syn-0.11.11/src/aster/mod.rs | 33 - vendor/syn-0.11.11/src/aster/path.rs | 327 - vendor/syn-0.11.11/src/aster/qpath.rs | 143 - vendor/syn-0.11.11/src/aster/ty.rs | 488 -- vendor/syn-0.11.11/src/aster/ty_param.rs | 262 - .../syn-0.11.11/src/aster/where_predicate.rs | 259 - vendor/syn-0.11.11/src/attr.rs | 305 - vendor/syn-0.11.11/src/constant.rs | 180 - vendor/syn-0.11.11/src/data.rs | 297 - vendor/syn-0.11.11/src/derive.rs | 124 - vendor/syn-0.11.11/src/escape.rs | 294 - vendor/syn-0.11.11/src/expr.rs | 1721 ------ vendor/syn-0.11.11/src/fold.rs | 942 --- vendor/syn-0.11.11/src/generics.rs | 513 -- vendor/syn-0.11.11/src/ident.rs | 129 - vendor/syn-0.11.11/src/item.rs | 1477 ----- vendor/syn-0.11.11/src/krate.rs | 57 - vendor/syn-0.11.11/src/lib.rs | 211 - vendor/syn-0.11.11/src/lit.rs | 484 -- vendor/syn-0.11.11/src/mac.rs | 430 -- vendor/syn-0.11.11/src/op.rs | 192 - vendor/syn-0.11.11/src/ty.rs | 844 --- vendor/syn-0.11.11/src/visit.rs | 778 --- vendor/synom/.cargo-checksum.json | 1 - vendor/synom/Cargo.toml | 20 - vendor/synom/README.md | 199 - vendor/synom/src/helper.rs | 543 -- vendor/synom/src/lib.rs | 1225 ---- vendor/synom/src/space.rs | 99 - vendor/toml-query/.cargo-checksum.json | 2 +- vendor/toml-query/CHANGELOG.md | 9 + vendor/toml-query/Cargo.toml | 14 +- vendor/toml-query/README.md | 10 + vendor/toml-query/src/error.rs | 6 + vendor/toml-query/src/insert.rs | 9 + vendor/toml-query/src/lib.rs | 7 + vendor/toml-query/src/read.rs | 52 + vendor/toml-query/src/set.rs | 53 + vendor/toml-query/src/value.rs | 20 +- vendor/typenum/.cargo-checksum.json | 1 + vendor/typenum/CHANGELOG.md | 56 + vendor/typenum/Cargo.toml | 31 + vendor/typenum/LICENSE | 21 + vendor/typenum/README.md | 42 + vendor/typenum/build/main.rs | 179 + vendor/typenum/build/op.rs | 533 ++ vendor/typenum/build/tests.rs | 301 + vendor/typenum/src/array.rs | 282 + vendor/typenum/src/bit.rs | 272 + vendor/typenum/src/int.rs | 935 +++ vendor/typenum/src/lib.rs | 135 + vendor/typenum/src/marker_traits.rs | 194 + vendor/typenum/src/operator_aliases.rs | 98 + vendor/typenum/src/private.rs | 361 ++ vendor/typenum/src/type_operators.rs | 500 ++ vendor/typenum/src/uint.rs | 1572 +++++ vendor/typenum/tests/test.rs | 2 + vendor/ucd-trie/.cargo-checksum.json | 1 + vendor/ucd-trie/Cargo.toml | 29 + vendor/{synom => ucd-trie}/LICENSE-APACHE | 0 vendor/ucd-trie/LICENSE-MIT | 21 + vendor/ucd-trie/README.md | 22 + vendor/ucd-trie/benches/bench.rs | 29 + vendor/ucd-trie/src/general_category.rs | 1433 +++++ vendor/ucd-trie/src/lib.rs | 119 + vendor/ucd-trie/src/owned.rs | 371 ++ vendor/unicode-xid-0.0.4/.cargo-checksum.json | 1 - vendor/unicode-xid-0.0.4/COPYRIGHT | 7 - vendor/unicode-xid-0.0.4/Cargo.toml | 26 - vendor/unicode-xid-0.0.4/LICENSE-MIT | 25 - vendor/unicode-xid-0.0.4/README.md | 34 - vendor/unicode-xid-0.0.4/scripts/unicode.py | 187 - vendor/unicode-xid-0.0.4/src/lib.rs | 87 - vendor/unicode-xid-0.0.4/src/tables.rs | 426 -- vendor/unicode-xid-0.0.4/src/tests.rs | 113 - version | 2 +- 3499 files changed, 104362 insertions(+), 143386 deletions(-) create mode 100644 src/ci/docker/dist-arm-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch create mode 100644 src/ci/docker/dist-armhf-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch create mode 100644 src/ci/docker/dist-armv7-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch create mode 100644 src/ci/docker/dist-powerpc-linux/patches/glibc/2.12.2/002-newer-gcc.patch create mode 100644 src/ci/docker/dist-powerpc64-linux/patches/glibc/2.12.2/003-newer-gcc.patch create mode 100644 src/ci/docker/dist-s390x-linux/patches/glibc/2.12.2/002-newer-gcc.patch rename src/ci/docker/{wasm32-unknown => test-various}/Dockerfile (63%) delete mode 100644 src/doc/book/.github/ISSUE_TEMPLATE.md delete mode 100644 src/doc/book/.github/PULL_REQUEST_TEMPLATE.md mode change 100644 => 100755 src/doc/book/ci/spellcheck.sh create mode 100644 src/doc/book/nostarch/appendix-a-new-section.md create mode 100644 src/doc/book/nostarch/chapter-03-integer-overflow-box.md create mode 100644 src/doc/book/nostarch/chapter-03-new-array-text.md create mode 100644 src/doc/book/nostarch/chapter-03-returning-values-from-loops.md create mode 100644 src/doc/book/nostarch/chapter-04-error-message-updates.md create mode 100644 src/doc/book/nostarch/chapter-04-stack-heap-box-edits.md create mode 100644 src/doc/book/nostarch/chapter-08-error-message-updates.md create mode 100644 src/doc/book/nostarch/chapter-08-listing-8-5.md create mode 100644 src/doc/book/nostarch/chapter-09-error-message-updates.md create mode 100644 src/doc/book/nostarch/chapter-09-listing-9-2-update.md create mode 100644 src/doc/book/nostarch/chapter-09-listing-9-5-update.md create mode 100644 src/doc/book/nostarch/chapter-09-match-update.md create mode 100644 src/doc/book/nostarch/chapter-09-read-to-string-update.md create mode 100644 src/doc/book/nostarch/chapter-12-error-message-updates.md create mode 100644 src/doc/book/nostarch/chapter-15-code-updates.md create mode 100644 src/doc/book/nostarch/chapter-15-error-message-updates.md create mode 100644 src/doc/book/nostarch/chapter-18-destructuring-nested-structs-and-enums.md create mode 100644 src/doc/book/nostarch/chapter-19-new-function-pointer-text.md create mode 100644 src/doc/book/nostarch/chapter10-traits-as-parameters.md create mode 100644 src/doc/book/nostarch/chapter11-using-result-in-tests.md create mode 100644 src/doc/book/nostarch/version-note.md delete mode 100644 src/doc/book/second-edition/nostarch/appendix.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter00.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter01.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter02.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter03.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter04.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter05.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter06.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter07.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter08.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter09.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter10.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter11.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter12.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter13.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter14.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter15.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter16.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter17.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter18.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter19.md delete mode 100644 src/doc/book/second-edition/nostarch/chapter20.md delete mode 100644 src/doc/book/second-edition/nostarch/foreword.md delete mode 100644 src/doc/book/second-edition/nostarch/introduction.md create mode 100644 src/doc/book/src/title-page.md create mode 100644 src/doc/embedded-book/.github/CODEOWNERS create mode 100644 src/doc/embedded-book/.github/bors.toml create mode 100644 src/doc/embedded-book/.travis.yml create mode 100644 src/doc/embedded-book/CNAME create mode 100644 src/doc/embedded-book/CODE_OF_CONDUCT.md create mode 100644 src/doc/embedded-book/LICENSE-APACHE create mode 100644 src/doc/embedded-book/LICENSE-CC-BY-SA create mode 100644 src/doc/embedded-book/LICENSE-MIT create mode 100644 src/doc/embedded-book/README.md create mode 100644 src/doc/embedded-book/book.toml create mode 100644 src/doc/embedded-book/ci/after-success.sh create mode 100644 src/doc/embedded-book/ci/install.sh create mode 100644 src/doc/embedded-book/ci/script.sh create mode 100644 src/doc/embedded-book/src/SUMMARY.md create mode 100644 src/doc/embedded-book/src/assets/embedded-hal.svg create mode 100644 src/doc/embedded-book/src/assets/f3.jpg create mode 100644 src/doc/embedded-book/src/assets/nrf52-memory-map.png create mode 100644 src/doc/embedded-book/src/assets/nrf52-spi-frequency-register.png create mode 100644 src/doc/embedded-book/src/assets/rust_layers.svg create mode 100644 src/doc/embedded-book/src/assets/verify.jpeg create mode 100644 src/doc/embedded-book/src/c-tips/index.md create mode 100644 src/doc/embedded-book/src/collections/index.md create mode 100644 src/doc/embedded-book/src/concurrency/index.md create mode 100644 src/doc/embedded-book/src/interoperability/c-with-rust.md create mode 100644 src/doc/embedded-book/src/interoperability/index.md create mode 100644 src/doc/embedded-book/src/interoperability/rust-with-c.md create mode 100644 src/doc/embedded-book/src/intro/hardware.md create mode 100644 src/doc/embedded-book/src/intro/index.md create mode 100644 src/doc/embedded-book/src/intro/install.md create mode 100644 src/doc/embedded-book/src/intro/install/linux.md create mode 100644 src/doc/embedded-book/src/intro/install/macos.md create mode 100644 src/doc/embedded-book/src/intro/install/verify.md create mode 100644 src/doc/embedded-book/src/intro/install/windows.md create mode 100644 src/doc/embedded-book/src/intro/no-std.md create mode 100644 src/doc/embedded-book/src/intro/tooling.md create mode 100644 src/doc/embedded-book/src/peripherals/a-first-attempt.md create mode 100644 src/doc/embedded-book/src/peripherals/borrowck.md create mode 100644 src/doc/embedded-book/src/peripherals/index.md create mode 100644 src/doc/embedded-book/src/peripherals/singletons.md create mode 100644 src/doc/embedded-book/src/portability/index.md create mode 100644 src/doc/embedded-book/src/start/exceptions.md create mode 100644 src/doc/embedded-book/src/start/hardware.md create mode 100644 src/doc/embedded-book/src/start/index.md create mode 100644 src/doc/embedded-book/src/start/interrupts.md create mode 100644 src/doc/embedded-book/src/start/io.md create mode 100644 src/doc/embedded-book/src/start/panicking.md create mode 100644 src/doc/embedded-book/src/start/qemu.md create mode 100644 src/doc/embedded-book/src/start/registers.md create mode 100644 src/doc/embedded-book/src/start/semihosting.md create mode 100644 src/doc/embedded-book/src/static-guarantees/design-contracts.md create mode 100644 src/doc/embedded-book/src/static-guarantees/index.md create mode 100644 src/doc/embedded-book/src/static-guarantees/state-machines.md create mode 100644 src/doc/embedded-book/src/static-guarantees/typestate-programming.md create mode 100644 src/doc/embedded-book/src/static-guarantees/zero-cost-abstractions.md create mode 100644 src/doc/embedded-book/src/unsorted/index.md create mode 100644 src/doc/embedded-book/src/unsorted/speed-vs-size.md create mode 100644 src/doc/rustc/src/linker-plugin-lto.md create mode 100644 src/doc/unstable-book/src/language-features/repr-align-enum.md create mode 100644 src/doc/unstable-book/src/library-features/is-sorted.md create mode 100644 src/liballoc/benches/btree/set.rs delete mode 100644 src/liballoc/task.rs create mode 100644 src/libcore/benches/fmt.rs create mode 100644 src/libcore/iter/adapters/chain.rs create mode 100644 src/libcore/iter/adapters/flatten.rs create mode 100644 src/libcore/iter/adapters/mod.rs create mode 100644 src/libcore/iter/adapters/zip.rs delete mode 100644 src/libcore/iter/traits.rs create mode 100644 src/libcore/iter/traits/accum.rs create mode 100644 src/libcore/iter/traits/collect.rs create mode 100644 src/libcore/iter/traits/double_ended.rs create mode 100644 src/libcore/iter/traits/exact_size.rs rename src/libcore/iter/{ => traits}/iterator.rs (95%) create mode 100644 src/libcore/iter/traits/marker.rs create mode 100644 src/libcore/iter/traits/mod.rs delete mode 100644 src/librustc_data_structures/obligation_forest/README.md create mode 100644 src/librustc_passes/layout_test.rs create mode 100644 src/librustc_target/spec/nvptx64_nvidia_cuda.rs create mode 100644 src/librustc_target/spec/powerpc64_unknown_freebsd.rs create mode 100644 src/librustc_target/spec/riscv64gc_unknown_none_elf.rs create mode 100644 src/librustc_target/spec/riscv64imac_unknown_none_elf.rs create mode 100644 src/librustdoc/html/static/favicon.ico create mode 100644 src/librustdoc/html/static/rust-logo.png create mode 100644 src/librustdoc/passes/check_code_block_syntax.rs create mode 100644 src/libserialize/tests/json.rs create mode 100644 src/libserialize/tests/opaque.rs create mode 100644 src/libstd/sync/mpsc/select_tests.rs create mode 100644 src/libstd/sys/cloudabi/io.rs create mode 100644 src/libstd/sys/redox/io.rs create mode 100644 src/libstd/sys/sgx/ext/ffi.rs create mode 100644 src/libstd/sys/sgx/io.rs create mode 100644 src/libstd/sys/unix/io.rs create mode 100644 src/libstd/sys/wasm/io.rs create mode 100644 src/libstd/sys/windows/io.rs create mode 100644 src/libstd/tests/run-time-detect.rs delete mode 100644 src/libsyntax/ext/quote.rs delete mode 100644 src/libsyntax/fold.rs create mode 100644 src/libsyntax/mut_visit.rs rename src/libsyntax/util/{move_map.rs => map_in_place.rs} (82%) delete mode 100644 src/stdsimd/ci/cross/nvptx64-nvidia-cuda.json rename src/stdsimd/ci/docker/{nvptx64-nvidia-cuda-cross => nvptx64-nvidia-cuda}/Dockerfile (100%) delete mode 100644 src/stdsimd/coresimd/x86/adx.rs delete mode 100644 src/stdsimd/coresimd/x86_64/adx.rs rename src/stdsimd/crates/{coresimd => core_arch}/Cargo.toml (72%) rename {vendor/crossbeam-deque => src/stdsimd/crates/core_arch}/LICENSE-APACHE (100%) rename {vendor/synom => src/stdsimd/crates/core_arch}/LICENSE-MIT (95%) create mode 100644 src/stdsimd/crates/core_arch/README.md create mode 100644 src/stdsimd/crates/core_arch/build.rs create mode 100755 src/stdsimd/crates/core_arch/foo.wasm rename src/stdsimd/{coresimd => crates/core_arch/src}/aarch64/crc.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/aarch64/crypto.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/aarch64/mod.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/aarch64/neon.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/aarch64/v8.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/armclang.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/cmsis.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/dsp.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/mod.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/neon.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/table_lookup_tests.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/v6.rs (97%) rename src/stdsimd/{coresimd => crates/core_arch/src}/arm/v7.rs (98%) create mode 100644 src/stdsimd/crates/core_arch/src/core_arch_docs.md rename src/stdsimd/crates/{coresimd => core_arch}/src/lib.rs (52%) rename src/stdsimd/{coresimd => crates/core_arch/src}/macros.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/mips/mod.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/mips/msa.rs (97%) rename src/stdsimd/{coresimd => crates/core_arch/src}/mod.rs (68%) rename src/stdsimd/{coresimd => crates/core_arch/src}/nvptx/mod.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/powerpc/altivec.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/powerpc/mod.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/powerpc/vsx.rs (96%) rename src/stdsimd/{coresimd => crates/core_arch/src}/powerpc64/mod.rs (89%) rename src/stdsimd/{coresimd => crates/core_arch/src}/simd.rs (93%) rename src/stdsimd/{coresimd => crates/core_arch/src}/simd_llvm.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/v64.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/wasm32/atomic.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/wasm32/memory.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/wasm32/mod.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/wasm32/simd128.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/abm.rs (98%) create mode 100644 src/stdsimd/crates/core_arch/src/x86/adx.rs rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/aes.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/avx.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/avx2.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/avx512f.rs (93%) create mode 100644 src/stdsimd/crates/core_arch/src/x86/avx512ifma.rs rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/bmi1.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/bmi2.rs (97%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/bswap.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/cpuid.rs (95%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/eflags.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/fma.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/fxsr.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/macros.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/mmx.rs (93%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/mod.rs (87%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/pclmulqdq.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/rdrand.rs (95%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/rdtsc.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/sha.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/sse.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/sse2.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/sse3.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/sse41.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/sse42.rs (96%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/sse4a.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/ssse3.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/tbm.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/test.rs (96%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86/xsave.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/abm.rs (98%) create mode 100644 src/stdsimd/crates/core_arch/src/x86_64/adx.rs rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/avx.rs (95%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/avx2.rs (95%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/bmi.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/bmi2.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/bswap.rs (90%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/cmpxchg16b.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/fxsr.rs (99%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/mod.rs (100%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/rdrand.rs (94%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/sse.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/sse2.rs (98%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/sse41.rs (95%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/sse42.rs (96%) rename src/stdsimd/{coresimd => crates/core_arch/src}/x86_64/xsave.rs (98%) rename src/stdsimd/crates/{coresimd => core_arch}/tests/cpu-detection.rs (98%) delete mode 100644 src/stdsimd/crates/coresimd/build.rs rename src/stdsimd/crates/{stdsimd => std_detect}/Cargo.toml (66%) rename {vendor/error-chain-0.11.0 => src/stdsimd/crates/std_detect}/LICENSE-APACHE (100%) rename {vendor/regex-0.2.11 => src/stdsimd/crates/std_detect}/LICENSE-MIT (95%) create mode 100644 src/stdsimd/crates/std_detect/README.md rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/arch/aarch64.rs (70%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/arch/arm.rs (82%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/arch/mips.rs (79%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/arch/mips64.rs (79%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/arch/powerpc.rs (72%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/arch/powerpc64.rs (72%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/arch/x86.rs (54%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/bit.rs (100%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/cache.rs (93%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/error_macros.rs (100%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/mod.rs (97%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/aarch64.rs (98%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/freebsd/aarch64.rs (95%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/freebsd/mod.rs (100%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/linux/aarch64.rs (97%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/linux/arm.rs (93%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/linux/auxvec.rs (74%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/linux/cpuinfo.rs (99%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/linux/mips.rs (92%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/linux/mod.rs (90%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/linux/powerpc.rs (94%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/other.rs (82%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/os/x86.rs (98%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/test_data/linux-rpi3.auxv (100%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/test_data/linux-x64-i7-6850k.auxv (100%) rename src/stdsimd/{stdsimd/arch => crates/std_detect/src}/detect/test_data/macos-virtualbox-linux-x86-4850HQ.auxv (100%) create mode 100644 src/stdsimd/crates/std_detect/src/lib.rs create mode 100644 src/stdsimd/crates/std_detect/src/mod.rs rename src/stdsimd/crates/{stdsimd => std_detect}/tests/cpu-detection.rs (99%) create mode 100644 src/stdsimd/crates/std_detect/tests/macro_trailing_commas.rs delete mode 100644 src/stdsimd/crates/stdsimd/src/lib.rs create mode 100644 src/stdsimd/examples/Cargo.toml delete mode 100644 src/stdsimd/stdsimd/mod.rs create mode 100644 src/stdsimd/vendor.yml create mode 100644 src/test/codegen/align-enum.rs create mode 100644 src/test/codegen/ffi-returns-twice.rs create mode 100644 src/test/codegen/inline-always-works-always.rs create mode 100644 src/test/codegen/optimize-attr-1.rs rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-abs.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-ceil.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-cos.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-exp.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-exp2.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-floor.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-fma.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-fsqrt.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-log.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-log10.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-log2.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-minmax.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-pow.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-powi.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-float-sin.rs (100%) create mode 100644 src/test/codegen/simd-intrinsic/simd-intrinsic-generic-arithmetic-saturating.rs create mode 100644 src/test/codegen/simd-intrinsic/simd-intrinsic-generic-bitmask.rs rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-generic-gather.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-generic-scatter.rs (100%) rename src/test/codegen/{ => simd-intrinsic}/simd-intrinsic-generic-select.rs (100%) create mode 100644 src/test/debuginfo/generators.rs create mode 100644 src/test/incremental/issue-54242.rs create mode 100644 src/test/incremental/lto.rs create mode 100644 src/test/mir-opt/unusual-item-types.rs create mode 100644 src/test/pretty/dollar-crate.pp create mode 100644 src/test/pretty/dollar-crate.rs delete mode 100644 src/test/run-fail-fulldeps/qquote.rs create mode 100644 src/test/run-make-fulldeps/cross-lang-lto-clang/Makefile create mode 100644 src/test/run-make-fulldeps/cross-lang-lto-clang/clib.c create mode 100644 src/test/run-make-fulldeps/cross-lang-lto-clang/cmain.c create mode 100644 src/test/run-make-fulldeps/cross-lang-lto-clang/main.rs create mode 100644 src/test/run-make-fulldeps/cross-lang-lto-clang/rustlib.rs create mode 100644 src/test/run-make-fulldeps/static-extern-type/Makefile create mode 100644 src/test/run-make-fulldeps/static-extern-type/define-foo.c create mode 100644 src/test/run-make-fulldeps/static-extern-type/use-foo.rs create mode 100644 src/test/run-make/nvptx-binary-crate/Makefile create mode 100644 src/test/run-make/nvptx-binary-crate/main.rs create mode 100644 src/test/run-make/nvptx-dylib-crate/Makefile create mode 100644 src/test/run-make/nvptx-dylib-crate/dep.rs create mode 100644 src/test/run-make/nvptx-dylib-crate/kernel.rs create mode 100644 src/test/run-make/nvptx-emit-asm/Makefile create mode 100644 src/test/run-make/nvptx-emit-asm/kernel.rs create mode 100644 src/test/run-make/wasm-stringify-ints-small/Makefile create mode 100644 src/test/run-make/wasm-stringify-ints-small/foo.rs delete mode 100644 src/test/run-pass-fulldeps/auxiliary/issue-16723.rs delete mode 100644 src/test/run-pass-fulldeps/auxiliary/plugin_with_plugin_lib.rs delete mode 100644 src/test/run-pass-fulldeps/auxiliary/procedural_mbe_matching.rs delete mode 100644 src/test/run-pass-fulldeps/auxiliary/syntax_extension_with_dll_deps_2.rs delete mode 100644 src/test/run-pass-fulldeps/issue-16723.rs delete mode 100644 src/test/run-pass-fulldeps/issue-16992.rs delete mode 100644 src/test/run-pass-fulldeps/issue-18763-quote-token-tree.rs delete mode 100644 src/test/run-pass-fulldeps/macro-crate-does-hygiene-work.rs delete mode 100644 src/test/run-pass-fulldeps/macro-crate-multi-decorator-literals.rs delete mode 100644 src/test/run-pass-fulldeps/macro-crate.rs delete mode 100644 src/test/run-pass-fulldeps/mbe_matching_test_macro.rs delete mode 100644 src/test/run-pass-fulldeps/plugin-lib-ok-in-plugin.rs delete mode 100644 src/test/run-pass-fulldeps/plugin-plus-extern-crate.rs delete mode 100644 src/test/run-pass-fulldeps/qquote.rs delete mode 100644 src/test/run-pass-fulldeps/quote-tokens.rs delete mode 100644 src/test/run-pass-fulldeps/quote-unused-sp-no-warning.rs delete mode 100644 src/test/run-pass-fulldeps/syntax-extension-with-dll-deps.rs create mode 100644 src/test/run-pass/auxiliary/arc_wake.rs delete mode 100644 src/test/run-pass/command-before-exec.rs create mode 100644 src/test/run-pass/command-pre-exec.rs create mode 100644 src/test/run-pass/const-int-saturating-arith.rs create mode 100644 src/test/run-pass/generator/non-static-is-unpin.rs create mode 100644 src/test/run-pass/generator/pin-box-generator.rs create mode 100644 src/test/run-pass/issues/issue-27949.rs create mode 100644 src/test/run-pass/simd/simd-intrinsic-generic-arithmetic-saturating.rs create mode 100644 src/test/run-pass/simd/simd-intrinsic-generic-bitmask.rs create mode 100644 src/test/run-pass/structs-enums/align-enum.rs create mode 100644 src/test/run-pass/try_from.rs rename src/test/{rustdoc-js => rustdoc-js-std}/alias-1.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/alias-2.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/alias-3.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/alias.js (100%) create mode 100644 src/test/rustdoc-js-std/basic.js rename src/test/{rustdoc-js => rustdoc-js-std}/deduplication.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/enum-option.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/filter-crate.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/fn-forget.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/from_u.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/keyword.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/macro-check.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/macro-print.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/multi-query.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/never.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/quoted.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/should-fail.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/string-from_ut.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/struct-vec.js (100%) rename src/test/{rustdoc-js => rustdoc-js-std}/vec-new.js (100%) create mode 100644 src/test/rustdoc-js/basic.rs delete mode 100644 src/test/rustdoc-js/substring.js create mode 100644 src/test/rustdoc/bad-codeblock-syntax.rs create mode 100644 src/test/rustdoc/intra-link-prim-methods.rs create mode 100644 src/test/rustdoc/issue-56701.rs create mode 100644 src/test/rustdoc/process-termination.rs create mode 100644 src/test/rustdoc/rustc_deprecated-future.rs create mode 100644 src/test/rustdoc/stability.rs create mode 100644 src/test/rustdoc/trait_alias.rs create mode 100644 src/test/rustdoc/use-attr.rs create mode 100644 src/test/rustdoc/without-redirect.rs create mode 100644 src/test/rustdoc/wrapping.rs delete mode 100644 src/test/ui-fulldeps/auxiliary/macro_crate_test.rs delete mode 100644 src/test/ui-fulldeps/gated-quote.rs delete mode 100644 src/test/ui-fulldeps/gated-quote.stderr delete mode 100644 src/test/ui-fulldeps/issue-48941.rs delete mode 100644 src/test/ui-fulldeps/issue-48941.stderr delete mode 100644 src/test/ui-fulldeps/macro-crate-doesnt-resolve.rs delete mode 100644 src/test/ui-fulldeps/macro-crate-doesnt-resolve.stderr delete mode 100644 src/test/ui-fulldeps/macro-crate-unexported-macro.rs delete mode 100644 src/test/ui-fulldeps/macro-crate-unexported-macro.stderr delete mode 100644 src/test/ui-fulldeps/plugin-plus-extern-crate.rs delete mode 100644 src/test/ui-fulldeps/plugin-plus-extern-crate.stderr delete mode 100644 src/test/ui-fulldeps/qquote.rs delete mode 100644 src/test/ui-fulldeps/qquote.stderr create mode 100644 src/test/ui/attr-eq-token-tree.stderr create mode 100644 src/test/ui/attribute-with-no-generics-in-parameter-list.rs create mode 100644 src/test/ui/attribute-with-no-generics-in-parameter-list.stderr create mode 100644 src/test/ui/binop/binop-consume-args.nll.stderr create mode 100644 src/test/ui/borrowck/borrowck-consume-unsize-vec.nll.stderr create mode 100644 src/test/ui/borrowck/issue-58776-borrowck-scans-children.ast.stderr create mode 100644 src/test/ui/borrowck/issue-58776-borrowck-scans-children.migrate.stderr create mode 100644 src/test/ui/borrowck/issue-58776-borrowck-scans-children.nll.stderr create mode 100644 src/test/ui/borrowck/issue-58776-borrowck-scans-children.rs create mode 100644 src/test/ui/const-generics/const-expression-parameter.rs create mode 100644 src/test/ui/const-generics/const-expression-parameter.stderr create mode 100644 src/test/ui/const-generics/const-fn-with-const-param.rs create mode 100644 src/test/ui/const-generics/const-fn-with-const-param.stderr create mode 100644 src/test/ui/const-generics/const-param-before-other-params.rs create mode 100644 src/test/ui/const-generics/const-param-before-other-params.stderr create mode 100644 src/test/ui/const-generics/const-param-from-outer-fn.rs create mode 100644 src/test/ui/const-generics/const-param-from-outer-fn.stderr create mode 100644 src/test/ui/const-generics/const-parameter-uppercase-lint.rs create mode 100644 src/test/ui/const-generics/const-parameter-uppercase-lint.stderr create mode 100644 src/test/ui/consts/const_arg_local.rs create mode 100644 src/test/ui/consts/const_arg_local.stderr create mode 100644 src/test/ui/consts/const_arg_promotable.rs create mode 100644 src/test/ui/consts/const_arg_promotable.stderr create mode 100644 src/test/ui/consts/const_arg_wrapper.rs create mode 100644 src/test/ui/consts/const_arg_wrapper.stderr create mode 100644 src/test/ui/consts/drop_none.rs create mode 100644 src/test/ui/consts/invalid_promotion.rs create mode 100644 src/test/ui/consts/match_ice.rs create mode 100644 src/test/ui/consts/match_ice.stderr create mode 100644 src/test/ui/consts/miri_unleashed/assoc_const.rs create mode 100644 src/test/ui/consts/miri_unleashed/assoc_const.stderr create mode 100644 src/test/ui/consts/miri_unleashed/assoc_const_2.rs create mode 100644 src/test/ui/consts/miri_unleashed/assoc_const_2.stderr create mode 100644 src/test/ui/consts/miri_unleashed/feature-gate-unleash_the_miri_inside_of_you.rs create mode 100644 src/test/ui/consts/miri_unleashed/feature-gate-unleash_the_miri_inside_of_you.stderr create mode 100644 src/test/ui/consts/promote_evaluation_unused_result.rs create mode 100644 src/test/ui/deprecation/atomic_initializers.fixed create mode 100644 src/test/ui/deprecation/atomic_initializers.rs create mode 100644 src/test/ui/deprecation/atomic_initializers.stderr create mode 100644 src/test/ui/deprecation/derive_on_deprecated.rs create mode 100644 src/test/ui/deprecation/derive_on_deprecated_forbidden.rs create mode 100644 src/test/ui/deprecation/invalid-literal.rs create mode 100644 src/test/ui/deprecation/invalid-literal.stderr create mode 100644 src/test/ui/deprecation/rustc_deprecation-in-future.rs create mode 100644 src/test/ui/deprecation/rustc_deprecation-in-future.stderr delete mode 100644 src/test/ui/error-codes/E0232.rs delete mode 100644 src/test/ui/error-codes/E0232.stderr delete mode 100644 src/test/ui/error-codes/E0296.rs delete mode 100644 src/test/ui/error-codes/E0296.stderr delete mode 100644 src/test/ui/error-codes/E0558.rs delete mode 100644 src/test/ui/error-codes/E0558.stderr create mode 100644 src/test/ui/existential_types/auxiliary/cross_crate_ice.rs create mode 100644 src/test/ui/existential_types/auxiliary/cross_crate_ice2.rs create mode 100644 src/test/ui/existential_types/cross_crate_ice.rs create mode 100644 src/test/ui/existential_types/cross_crate_ice2.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use10.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use2.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use2.stderr create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use3.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use3.stderr create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use4.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use4.stderr create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use5.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use5.stderr create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use6.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use6.stderr create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use7.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use8.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use8.stderr create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use9.rs create mode 100644 src/test/ui/existential_types/generic_duplicate_param_use9.stderr create mode 100644 src/test/ui/existential_types/not_a_defining_use.rs create mode 100644 src/test/ui/existential_types/not_a_defining_use.stderr delete mode 100644 src/test/ui/existential_types/unused_generic_param.stderr create mode 100644 src/test/ui/feature-gate-optimize_attribute.rs create mode 100644 src/test/ui/feature-gate-optimize_attribute.stderr create mode 100644 src/test/ui/feature-gate/feature-gate-static-nobundle-2.rs create mode 100644 src/test/ui/feature-gate/feature-gate-static-nobundle-2.stderr create mode 100644 src/test/ui/feature-gates/auxiliary/pub_dep.rs create mode 100644 src/test/ui/feature-gates/feature-gate-const_generics.rs create mode 100644 src/test/ui/feature-gates/feature-gate-const_generics.stderr delete mode 100644 src/test/ui/feature-gates/feature-gate-extern_crate_self.rs delete mode 100644 src/test/ui/feature-gates/feature-gate-extern_crate_self.stderr create mode 100644 src/test/ui/feature-gates/feature-gate-ffi_returns_twice.rs create mode 100644 src/test/ui/feature-gates/feature-gate-ffi_returns_twice.stderr create mode 100644 src/test/ui/feature-gates/feature-gate-is_sorted.rs create mode 100644 src/test/ui/feature-gates/feature-gate-is_sorted.stderr create mode 100644 src/test/ui/feature-gates/feature-gate-public_private_dependencies.rs create mode 100644 src/test/ui/feature-gates/feature-gate-repr_align_enum.rs create mode 100644 src/test/ui/feature-gates/feature-gate-repr_align_enum.stderr delete mode 100644 src/test/ui/feature-gates/feature-gate-unrestricted-attribute-tokens.rs delete mode 100644 src/test/ui/feature-gates/feature-gate-unrestricted-attribute-tokens.stderr create mode 100644 src/test/ui/ffi_returns_twice.rs create mode 100644 src/test/ui/ffi_returns_twice.stderr create mode 100644 src/test/ui/generator/static-not-unpin.rs create mode 100644 src/test/ui/generator/static-not-unpin.stderr create mode 100644 src/test/ui/huge-array-simple.stderr create mode 100644 src/test/ui/impl-trait/issue-57979-deeply-nested-impl-trait-in-assoc-proj.rs create mode 100644 src/test/ui/impl-trait/issue-57979-deeply-nested-impl-trait-in-assoc-proj.stderr create mode 100644 src/test/ui/impl-trait/issue-57979-impl-trait-in-path.rs create mode 100644 src/test/ui/impl-trait/issue-57979-impl-trait-in-path.stderr create mode 100644 src/test/ui/impl-trait/issue-57979-nested-impl-trait-in-assoc-proj.rs create mode 100644 src/test/ui/impl-trait/issue-57979-nested-impl-trait-in-assoc-proj.stderr rename src/test/ui/imports/{ => extern-crate-self}/extern-crate-self-fail.rs (85%) rename src/test/ui/imports/{ => extern-crate-self}/extern-crate-self-fail.stderr (91%) create mode 100644 src/test/ui/imports/extern-crate-self/extern-crate-self-macro-alias.rs create mode 100644 src/test/ui/imports/extern-crate-self/extern-crate-self-macro-item.rs create mode 100644 src/test/ui/imports/extern-crate-self/extern-crate-self-macro-self.rs rename src/test/ui/imports/{ => extern-crate-self}/extern-crate-self-pass.rs (79%) create mode 100644 src/test/ui/imports/issue-57539.rs create mode 100644 src/test/ui/imports/issue-57539.stderr create mode 100644 src/test/ui/issue-42944.rs create mode 100644 src/test/ui/issue-42944.stderr create mode 100644 src/test/ui/issue-53787-inline-assembler-macro.rs create mode 100644 src/test/ui/issue-53787-inline-assembler-macro.stderr create mode 100644 src/test/ui/issue-54943.stderr create mode 100644 src/test/ui/issues/auxiliary/issue-52891.rs create mode 100644 src/test/ui/issues/auxiliary/issue-56943.rs create mode 100644 src/test/ui/issues/issue-25700.nll.stderr create mode 100644 src/test/ui/issues/issue-34721.rs create mode 100644 src/test/ui/issues/issue-34721.stderr create mode 100644 src/test/ui/issues/issue-52496.rs create mode 100644 src/test/ui/issues/issue-52496.stderr create mode 100644 src/test/ui/issues/issue-52891.fixed create mode 100644 src/test/ui/issues/issue-52891.rs create mode 100644 src/test/ui/issues/issue-52891.stderr create mode 100644 src/test/ui/issues/issue-54521-1.rs create mode 100644 src/test/ui/issues/issue-54521-2.fixed create mode 100644 src/test/ui/issues/issue-54521-2.rs create mode 100644 src/test/ui/issues/issue-54521-2.stderr create mode 100644 src/test/ui/issues/issue-54521.fixed create mode 100644 src/test/ui/issues/issue-54521.rs create mode 100644 src/test/ui/issues/issue-54521.stderr create mode 100644 src/test/ui/issues/issue-54582.rs create mode 100644 src/test/ui/issues/issue-56488.rs create mode 100644 src/test/ui/issues/issue-56685.rs create mode 100644 src/test/ui/issues/issue-56685.stderr create mode 100644 src/test/ui/issues/issue-56943.rs create mode 100644 src/test/ui/issues/issue-56943.stderr create mode 100644 src/test/ui/issues/issue-57362-1.rs create mode 100644 src/test/ui/issues/issue-57362-1.stderr create mode 100644 src/test/ui/issues/issue-57362-2.rs create mode 100644 src/test/ui/issues/issue-57362-2.stderr create mode 100644 src/test/ui/issues/issue-57410-1.rs create mode 100644 src/test/ui/issues/issue-57410.rs create mode 100644 src/test/ui/issues/issue-57597.rs create mode 100644 src/test/ui/issues/issue-57597.stderr create mode 100644 src/test/ui/issues/issue-57684.fixed create mode 100644 src/test/ui/issues/issue-57684.rs create mode 100644 src/test/ui/issues/issue-57684.stderr create mode 100644 src/test/ui/issues/issue-57741-1.rs create mode 100644 src/test/ui/issues/issue-57741-1.stderr create mode 100644 src/test/ui/issues/issue-57741.fixed create mode 100644 src/test/ui/issues/issue-57741.rs create mode 100644 src/test/ui/issues/issue-57741.stderr create mode 100644 src/test/ui/issues/issue-57819.fixed create mode 100644 src/test/ui/issues/issue-57819.rs create mode 100644 src/test/ui/issues/issue-57819.stderr create mode 100644 src/test/ui/issues/issue-57866.rs create mode 100644 src/test/ui/issues/issue-58856-1.rs create mode 100644 src/test/ui/issues/issue-58856-1.stderr create mode 100644 src/test/ui/issues/issue-58856-2.rs create mode 100644 src/test/ui/issues/issue-58856-2.stderr create mode 100644 src/test/ui/issues/issue-58857.rs create mode 100644 src/test/ui/issues/issue-58857.stderr create mode 100644 src/test/ui/layout/homogeneous-aggr-zero-sized-c-struct.rs create mode 100644 src/test/ui/layout/homogeneous-aggr-zero-sized-c-struct.stderr create mode 100644 src/test/ui/layout/homogeneous-aggr-zero-sized-repr-rust.rs create mode 100644 src/test/ui/layout/homogeneous-aggr-zero-sized-repr-rust.stderr create mode 100644 src/test/ui/layout/zero-sized-array-union.rs create mode 100644 src/test/ui/layout/zero-sized-array-union.stderr create mode 100644 src/test/ui/lifetime-before-type-params.rs create mode 100644 src/test/ui/lifetime-before-type-params.stderr rename src/test/ui/{editions/edition-deny-overflowing-literals-2018.rs => lint/deny-overflowing-literals.rs} (82%) rename src/test/ui/{editions/edition-deny-overflowing-literals-2018.stderr => lint/deny-overflowing-literals.stderr} (76%) create mode 100644 src/test/ui/lint/lint-incoherent-auto-trait-objects.rs create mode 100644 src/test/ui/lint/lint-incoherent-auto-trait-objects.stderr create mode 100644 src/test/ui/macros/macro-multiple-matcher-bindings.rs create mode 100644 src/test/ui/macros/macro-multiple-matcher-bindings.stderr create mode 100644 src/test/ui/macros/meta-item-absolute-path.rs create mode 100644 src/test/ui/macros/meta-item-absolute-path.stderr create mode 100644 src/test/ui/malformed/malformed-interpolated.rs create mode 100644 src/test/ui/malformed/malformed-interpolated.stderr create mode 100644 src/test/ui/malformed/malformed-regressions.rs create mode 100644 src/test/ui/malformed/malformed-regressions.stderr create mode 100644 src/test/ui/malformed/malformed-special-attrs.rs create mode 100644 src/test/ui/malformed/malformed-special-attrs.stderr create mode 100644 src/test/ui/match/match-ref-mut-stability.rs create mode 100644 src/test/ui/match/match-type-err-first-arm.rs create mode 100644 src/test/ui/match/match-type-err-first-arm.stderr create mode 100644 src/test/ui/moves/move-guard-same-consts.nll.stderr create mode 100644 src/test/ui/moves/move-in-guard-1.nll.stderr create mode 100644 src/test/ui/nll/closure-requirements/issue-58127-mutliple-requirements.rs create mode 100644 src/test/ui/nll/issue-48697.stderr create mode 100644 src/test/ui/nll/issue-53773.rs create mode 100644 src/test/ui/nll/issue-53773.stderr create mode 100644 src/test/ui/nll/issue-58053.rs create mode 100644 src/test/ui/nll/issue-58053.stderr create mode 100644 src/test/ui/nll/issue-58299.rs create mode 100644 src/test/ui/nll/issue-58299.stderr create mode 100644 src/test/ui/nll/match-cfg-fake-edges.rs create mode 100644 src/test/ui/nll/match-cfg-fake-edges.stderr create mode 100644 src/test/ui/nll/promoted-bounds.rs create mode 100644 src/test/ui/nll/promoted-bounds.stderr create mode 100644 src/test/ui/nll/promoted-closure-pair.rs create mode 100644 src/test/ui/nll/promoted-closure-pair.stderr create mode 100644 src/test/ui/nll/ty-outlives/wf-unreachable.rs create mode 100644 src/test/ui/nll/ty-outlives/wf-unreachable.stderr create mode 100644 src/test/ui/nll/user-annotations/constant-in-expr-inherent-2.rs create mode 100644 src/test/ui/nll/user-annotations/constant-in-expr-inherent-2.stderr create mode 100644 src/test/ui/nll/user-annotations/downcast-infer.rs create mode 100644 src/test/ui/nll/user-annotations/inherent-associated-constants.rs create mode 100644 src/test/ui/nll/user-annotations/inherent-associated-constants.stderr create mode 100644 src/test/ui/nll/user-annotations/issue-57731-ascibed-coupled-types.rs create mode 100644 src/test/ui/nll/user-annotations/issue-57731-ascibed-coupled-types.stderr create mode 100644 src/test/ui/nll/user-annotations/promoted-annotation.rs create mode 100644 src/test/ui/nll/user-annotations/promoted-annotation.stderr create mode 100644 src/test/ui/once-cant-call-twice-on-heap.nll.stderr rename src/test/ui/{parenthesised-deref-suggestion.rs => parenthesized-deref-suggestion.rs} (100%) rename src/test/ui/{parenthesised-deref-suggestion.stderr => parenthesized-deref-suggestion.stderr} (88%) create mode 100644 src/test/ui/parser/issue-33418.fixed create mode 100644 src/test/ui/parser/issue-33418.rs create mode 100644 src/test/ui/parser/issue-33418.stderr create mode 100644 src/test/ui/parser/lex-bad-char-literals-6.rs create mode 100644 src/test/ui/parser/lex-bad-char-literals-6.stderr create mode 100644 src/test/ui/parser/unclosed-delimiter-in-dep.rs create mode 100644 src/test/ui/parser/unclosed-delimiter-in-dep.stderr create mode 100644 src/test/ui/parser/unclosed_delim_mod.rs create mode 100644 src/test/ui/parser/unclosed_delim_mod.stderr create mode 100644 src/test/ui/parser/unicode-quote-chars.rs create mode 100644 src/test/ui/parser/unicode-quote-chars.stderr create mode 100644 src/test/ui/point-to-type-err-cause-on-impl-trait-return-2.rs create mode 100644 src/test/ui/point-to-type-err-cause-on-impl-trait-return-2.stderr create mode 100644 src/test/ui/point-to-type-err-cause-on-impl-trait-return.rs create mode 100644 src/test/ui/point-to-type-err-cause-on-impl-trait-return.stderr create mode 100644 src/test/ui/privacy/pub-priv-dep/auxiliary/priv_dep.rs create mode 100644 src/test/ui/privacy/pub-priv-dep/auxiliary/pub_dep.rs create mode 100644 src/test/ui/privacy/pub-priv-dep/pub-priv1.rs create mode 100644 src/test/ui/privacy/pub-priv-dep/pub-priv1.stderr create mode 100644 src/test/ui/privacy/pub-priv-dep/std-pub.rs delete mode 100644 src/test/ui/proc-macro/shadow-builtin.rs delete mode 100644 src/test/ui/proc-macro/shadow-builtin.stderr delete mode 100644 src/test/ui/quote-with-interpolated.rs delete mode 100644 src/test/ui/quote-with-interpolated.stderr create mode 100644 src/test/ui/regions/regions-assoc-type-in-supertrait-outlives-container.ast.stderr create mode 100644 src/test/ui/regions/regions-assoc-type-in-supertrait-outlives-container.mir.stderr create mode 100644 src/test/ui/regions/regions-free-region-ordering-caller.ast.stderr create mode 100644 src/test/ui/regions/regions-free-region-ordering-caller.mir.stderr create mode 100644 src/test/ui/regions/regions-outlives-projection-container-hrtb.ast.stderr create mode 100644 src/test/ui/regions/regions-outlives-projection-container-hrtb.mir.stderr create mode 100644 src/test/ui/regions/regions-outlives-projection-container-wc.ast.stderr create mode 100644 src/test/ui/regions/regions-outlives-projection-container-wc.mir.stderr create mode 100644 src/test/ui/rust-2018/uniform-paths/auxiliary/cross-crate.rs create mode 100644 src/test/ui/rust-2018/uniform-paths/cross-crate.rs create mode 100644 src/test/ui/rust-2018/uniform-paths/cross-crate.stderr create mode 100644 src/test/ui/simd-intrinsic/simd-intrinsic-generic-arithmetic-saturating.rs create mode 100644 src/test/ui/simd-intrinsic/simd-intrinsic-generic-arithmetic-saturating.stderr create mode 100644 src/test/ui/simd-intrinsic/simd-intrinsic-generic-bitmask.rs create mode 100644 src/test/ui/simd-intrinsic/simd-intrinsic-generic-bitmask.stderr create mode 100644 src/test/ui/specialization/issue-39448.rs create mode 100644 src/test/ui/specialization/issue-39448.stderr create mode 100644 src/test/ui/stability-attribute/missing-stability-attr-at-top-level.rs create mode 100644 src/test/ui/stability-attribute/missing-stability-attr-at-top-level.stderr create mode 100644 src/test/ui/stability-attribute/stability-attribute-sanity-4.rs create mode 100644 src/test/ui/stability-attribute/stability-attribute-sanity-4.stderr create mode 100644 src/test/ui/stability-in-private-module.rs create mode 100644 src/test/ui/stability-in-private-module.stderr create mode 100644 src/test/ui/suggestions/attribute-typos.rs create mode 100644 src/test/ui/suggestions/attribute-typos.stderr create mode 100644 src/test/ui/suggestions/recover-invalid-float.rs create mode 100644 src/test/ui/suggestions/recover-invalid-float.stderr create mode 100644 src/test/ui/suggestions/suggest-move-types.rs create mode 100644 src/test/ui/suggestions/suggest-move-types.stderr create mode 100644 src/test/ui/suggestions/type-mismatch-struct-field-shorthand-2.rs create mode 100644 src/test/ui/suggestions/type-mismatch-struct-field-shorthand-2.stderr create mode 100644 src/test/ui/suggestions/type-mismatch-struct-field-shorthand.fixed create mode 100644 src/test/ui/suggestions/type-mismatch-struct-field-shorthand.rs create mode 100644 src/test/ui/suggestions/type-mismatch-struct-field-shorthand.stderr create mode 100644 src/test/ui/thread-local-mutation.nll.stderr create mode 100644 src/test/ui/thread-local-mutation.rs create mode 100644 src/test/ui/thread-local-mutation.stderr create mode 100644 src/test/ui/traits/auxiliary/trait_alias.rs create mode 100644 src/test/ui/traits/trait-alias-cross-crate.rs create mode 100644 src/test/ui/traits/trait-alias-cross-crate.stderr create mode 100644 src/test/ui/traits/trait-alias-syntax.rs create mode 100644 src/test/ui/traits/trait-alias-syntax.stderr create mode 100644 src/test/ui/type-alias-enum-variants-priority-2.rs create mode 100644 src/test/ui/type-alias-enum-variants-priority-2.stderr create mode 100644 src/test/ui/type-alias-enum-variants-priority-3.rs create mode 100644 src/test/ui/type-alias-enum-variants-priority-3.stderr create mode 100644 src/test/ui/type-alias-enum-variants-priority.rs create mode 100644 src/test/ui/type-alias-enum-variants-priority.stderr create mode 100644 src/tools/rustdoc-js-std/tester.js create mode 100644 vendor/arrayref/.cargo-checksum.json create mode 100644 vendor/arrayref/Cargo.toml create mode 100644 vendor/arrayref/LICENSE create mode 100644 vendor/arrayref/README.md create mode 100644 vendor/arrayref/examples/array_refs.rs create mode 100644 vendor/arrayref/examples/array_refs_with_const.rs create mode 100644 vendor/arrayref/examples/simple-case.rs create mode 100644 vendor/arrayref/src/lib.rs create mode 100644 vendor/block-buffer/.cargo-checksum.json create mode 100644 vendor/block-buffer/Cargo.toml rename vendor/{unicode-xid-0.0.4 => block-buffer}/LICENSE-APACHE (99%) rename vendor/{regex-syntax-0.5.6 => block-buffer}/LICENSE-MIT (95%) create mode 100644 vendor/block-buffer/src/lib.rs create mode 100644 vendor/block-buffer/src/paddings.rs create mode 100644 vendor/byte-tools/.cargo-checksum.json rename vendor/{regex-syntax-0.5.6 => byte-tools}/Cargo.toml (64%) create mode 100644 vendor/byte-tools/LICENSE-APACHE rename vendor/{error-chain-0.11.0 => byte-tools}/LICENSE-MIT (92%) create mode 100644 vendor/byte-tools/src/lib.rs create mode 100644 vendor/byte-tools/src/read_single.rs create mode 100644 vendor/byte-tools/src/read_slice.rs create mode 100644 vendor/byte-tools/src/write_single.rs create mode 100644 vendor/byte-tools/src/write_slice.rs rename vendor/{crossbeam-deque => crossbeam-deque-0.2.0}/.cargo-checksum.json (100%) rename vendor/{crossbeam-deque => crossbeam-deque-0.2.0}/CHANGELOG.md (100%) rename vendor/{crossbeam-deque => crossbeam-deque-0.2.0}/Cargo.toml (100%) rename vendor/{itertools => crossbeam-deque-0.2.0}/LICENSE-APACHE (100%) rename vendor/{crossbeam-deque => crossbeam-deque-0.2.0}/LICENSE-MIT (100%) rename vendor/{crossbeam-deque => crossbeam-deque-0.2.0}/README.md (100%) rename vendor/{crossbeam-deque => crossbeam-deque-0.2.0}/src/lib.rs (100%) create mode 100644 vendor/digest/.cargo-checksum.json create mode 100644 vendor/digest/Cargo.toml create mode 100644 vendor/digest/LICENSE-APACHE rename vendor/{syn-0.11.11 => digest}/LICENSE-MIT (95%) create mode 100644 vendor/digest/src/dev.rs create mode 100644 vendor/digest/src/digest.rs create mode 100644 vendor/digest/src/errors.rs create mode 100644 vendor/digest/src/lib.rs delete mode 100644 vendor/error-chain-0.11.0/.cargo-checksum.json delete mode 100644 vendor/error-chain-0.11.0/CHANGELOG.md delete mode 100644 vendor/error-chain-0.11.0/README.md delete mode 100644 vendor/error-chain-0.11.0/examples/all.rs delete mode 100644 vendor/error-chain-0.11.0/examples/chain_err.rs delete mode 100644 vendor/error-chain-0.11.0/examples/doc.rs delete mode 100644 vendor/error-chain-0.11.0/examples/quickstart.rs delete mode 100644 vendor/error-chain-0.11.0/examples/size.rs delete mode 100644 vendor/error-chain-0.11.0/src/bin/has_backtrace.rs delete mode 100644 vendor/error-chain-0.11.0/src/error_chain.rs delete mode 100644 vendor/error-chain-0.11.0/src/example_generated.rs delete mode 100644 vendor/error-chain-0.11.0/src/impl_error_chain_kind.rs delete mode 100644 vendor/error-chain-0.11.0/src/lib.rs delete mode 100644 vendor/error-chain-0.11.0/src/quick_main.rs delete mode 100644 vendor/error-chain-0.11.0/tests/quick_main.rs delete mode 100644 vendor/error-chain-0.11.0/tests/tests.rs create mode 100644 vendor/failure/Cargo.lock.ci create mode 100644 vendor/failure/tests/basic_fail.rs create mode 100644 vendor/failure/tests/fail_compat.rs create mode 100644 vendor/failure/tests/macro_trailing_comma.rs create mode 100644 vendor/fake-simd/.cargo-checksum.json create mode 100644 vendor/fake-simd/Cargo.toml create mode 100644 vendor/fake-simd/LICENSE-APACHE create mode 100644 vendor/fake-simd/LICENSE-MIT create mode 100644 vendor/fake-simd/src/lib.rs create mode 100644 vendor/generic-array/.cargo-checksum.json create mode 100644 vendor/generic-array/Cargo.toml create mode 100644 vendor/generic-array/LICENSE create mode 100644 vendor/generic-array/README.md create mode 100644 vendor/generic-array/rustfmt.toml create mode 100644 vendor/generic-array/src/arr.rs create mode 100644 vendor/generic-array/src/hex.rs create mode 100644 vendor/generic-array/src/impl_serde.rs create mode 100644 vendor/generic-array/src/impls.rs create mode 100644 vendor/generic-array/src/iter.rs create mode 100644 vendor/generic-array/src/lib.rs create mode 100644 vendor/generic-array/tests/hex.rs create mode 100644 vendor/generic-array/tests/import_name.rs create mode 100644 vendor/generic-array/tests/mod.rs create mode 100644 vendor/handlebars/src/helpers/helper_boolean.rs create mode 100644 vendor/handlebars/src/macros.rs create mode 100644 vendor/handlebars/src/output.rs create mode 100644 vendor/handlebars/src/value.rs create mode 100644 vendor/handlebars/tests/helper_macro.rs rename vendor/{itertools => itertools-0.7.8}/.cargo-checksum.json (100%) rename vendor/{itertools => itertools-0.7.8}/Cargo.toml (100%) rename vendor/{quote-0.3.15 => itertools-0.7.8}/LICENSE-APACHE (100%) rename vendor/{itertools => itertools-0.7.8}/LICENSE-MIT (100%) rename vendor/{itertools => itertools-0.7.8}/Makefile (100%) rename vendor/{itertools => itertools-0.7.8}/README.rst (100%) rename vendor/{itertools => itertools-0.7.8}/benches/bench1.rs (100%) rename vendor/{itertools => itertools-0.7.8}/benches/extra/mod.rs (100%) rename vendor/{itertools => itertools-0.7.8}/benches/extra/zipslices.rs (100%) rename vendor/{itertools => itertools-0.7.8}/benches/tree_fold1.rs (100%) rename vendor/{itertools => itertools-0.7.8}/benches/tuple_combinations.rs (100%) rename vendor/{itertools => itertools-0.7.8}/benches/tuples.rs (100%) rename vendor/{itertools => itertools-0.7.8}/bors.toml (100%) rename vendor/{itertools => itertools-0.7.8}/custom.css (100%) rename vendor/{itertools => itertools-0.7.8}/examples/iris.data (100%) rename vendor/{itertools => itertools-0.7.8}/examples/iris.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/adaptors/mod.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/adaptors/multi_product.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/combinations.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/concat_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/cons_tuples_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/diff.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/either_or_both.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/format.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/free.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/group_map.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/groupbylazy.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/impl_macros.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/intersperse.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/kmerge_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/lib.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/merge_join.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/minmax.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/multipeek_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/pad_tail.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/peeking_take_while.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/process_results_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/put_back_n_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/rciter_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/repeatn.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/size_hint.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/sources.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/tee.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/tuple_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/unique_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/with_position.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/zip_eq_impl.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/zip_longest.rs (100%) rename vendor/{itertools => itertools-0.7.8}/src/ziptuple.rs (100%) rename vendor/{itertools => itertools-0.7.8}/tests/merge_join.rs (100%) rename vendor/{itertools => itertools-0.7.8}/tests/peeking_take_while.rs (100%) rename vendor/{itertools => itertools-0.7.8}/tests/quick.rs (100%) rename vendor/{itertools => itertools-0.7.8}/tests/test_core.rs (100%) rename vendor/{itertools => itertools-0.7.8}/tests/test_std.rs (100%) rename vendor/{itertools => itertools-0.7.8}/tests/tuples.rs (100%) rename vendor/{itertools => itertools-0.7.8}/tests/zip.rs (100%) delete mode 100644 vendor/mdbook/build.rs delete mode 100644 vendor/mdbook/ci/github_pages.sh delete mode 100644 vendor/mdbook/ci/install.sh create mode 100644 vendor/mdbook/examples/nop-preprocessor.rs create mode 100644 vendor/mdbook/release.toml delete mode 100644 vendor/mdbook/rustfmt.toml delete mode 100644 vendor/mdbook/src/bin/serve.rs delete mode 100644 vendor/mdbook/src/bin/test.rs rename vendor/mdbook/src/{bin => cmd}/build.rs (54%) rename vendor/mdbook/src/{bin => cmd}/clean.rs (55%) rename vendor/mdbook/src/{bin => cmd}/init.rs (88%) create mode 100644 vendor/mdbook/src/cmd/mod.rs create mode 100644 vendor/mdbook/src/cmd/serve.rs create mode 100644 vendor/mdbook/src/cmd/test.rs rename vendor/mdbook/src/{bin => cmd}/watch.rs (81%) rename vendor/mdbook/src/{bin/mdbook.rs => main.rs} (57%) create mode 100644 vendor/mdbook/src/preprocess/cmd.rs create mode 100644 vendor/mdbook/src/preprocess/index.rs create mode 100644 vendor/mdbook/src/renderer/html_handlebars/helpers/theme.rs delete mode 100644 vendor/mdbook/src/theme/book.css create mode 100644 vendor/mdbook/src/theme/css/chrome.css create mode 100644 vendor/mdbook/src/theme/css/general.css create mode 100644 vendor/mdbook/src/theme/css/print.css create mode 100644 vendor/mdbook/src/theme/css/variables.css create mode 100644 vendor/mdbook/tests/build_process.rs create mode 100644 vendor/mdbook/tests/custom_preprocessors.rs create mode 100644 vendor/mdbook/tests/dummy_book/src/README.md create mode 100644 vendor/mdbook/tests/dummy_book/src/first/recursive.md create mode 100644 vendor/mdbook/tests/dummy_book/src/second/nested.md create mode 100644 vendor/mdbook/tests/dummy_book/src2/README.md create mode 100644 vendor/mdbook/tests/dummy_book/src2/SUMMARY.md create mode 100644 vendor/mdbook/tests/dummy_book/src2/first/README.md create mode 100644 vendor/mdbook/tests/dummy_book/src2/second/README.md create mode 100644 vendor/mdbook/tests/dummy_book/src2/second/index.md create mode 100644 vendor/minifier/src/js/utils.rs rename vendor/{regex-0.2.11 => parking_lot_core}/LICENSE-APACHE (100%) rename vendor/{quote-0.3.15 => parking_lot_core}/LICENSE-MIT (100%) create mode 100644 vendor/parking_lot_core/build.rs create mode 100644 vendor/pest/src/stack.rs create mode 100644 vendor/pest/src/unicode/binary.rs create mode 100644 vendor/pest/src/unicode/category.rs create mode 100644 vendor/pest/src/unicode/mod.rs delete mode 100644 vendor/pest_derive/src/generator.rs delete mode 100644 vendor/pest_derive/src/optimizer.rs delete mode 100644 vendor/pest_derive/src/parser.rs delete mode 100644 vendor/pest_derive/src/validator.rs create mode 100644 vendor/pest_derive/tests/grammar_inline.rs create mode 100644 vendor/pest_derive/tests/lists.pest create mode 100644 vendor/pest_derive/tests/lists.rs create mode 100644 vendor/pest_generator/.cargo-checksum.json create mode 100644 vendor/pest_generator/Cargo.toml rename vendor/{regex-syntax-0.5.6 => pest_generator}/LICENSE-APACHE (100%) create mode 100644 vendor/pest_generator/LICENSE-MIT create mode 100644 vendor/pest_generator/_README.md create mode 100644 vendor/pest_generator/src/generator.rs create mode 100644 vendor/pest_generator/src/lib.rs create mode 100644 vendor/pest_generator/src/macros.rs create mode 100644 vendor/pest_meta/.cargo-checksum.json create mode 100644 vendor/pest_meta/Cargo.toml rename vendor/{syn-0.11.11 => pest_meta}/LICENSE-APACHE (100%) create mode 100644 vendor/pest_meta/LICENSE-MIT create mode 100644 vendor/pest_meta/_README.md rename vendor/{pest_derive => pest_meta}/src/ast.rs (59%) create mode 100644 vendor/pest_meta/src/grammar.pest create mode 100644 vendor/pest_meta/src/grammar.rs create mode 100644 vendor/pest_meta/src/lib.rs create mode 100644 vendor/pest_meta/src/optimizer/concatenator.rs create mode 100644 vendor/pest_meta/src/optimizer/factorizer.rs create mode 100644 vendor/pest_meta/src/optimizer/mod.rs create mode 100644 vendor/pest_meta/src/optimizer/restorer.rs create mode 100644 vendor/pest_meta/src/optimizer/rotater.rs create mode 100644 vendor/pest_meta/src/optimizer/skipper.rs create mode 100644 vendor/pest_meta/src/optimizer/unroller.rs create mode 100644 vendor/pest_meta/src/parser.rs create mode 100644 vendor/pest_meta/src/validator.rs delete mode 100644 vendor/quote-0.3.15/.cargo-checksum.json delete mode 100644 vendor/quote-0.3.15/Cargo.toml delete mode 100644 vendor/quote-0.3.15/README.md delete mode 100644 vendor/quote-0.3.15/src/ident.rs delete mode 100644 vendor/quote-0.3.15/src/lib.rs delete mode 100644 vendor/quote-0.3.15/src/to_tokens.rs delete mode 100644 vendor/quote-0.3.15/src/tokens.rs delete mode 100644 vendor/quote-0.3.15/tests/test.rs delete mode 100644 vendor/regex-0.2.11/.cargo-checksum.json delete mode 100644 vendor/regex-0.2.11/CHANGELOG.md delete mode 100644 vendor/regex-0.2.11/Cargo.toml delete mode 100644 vendor/regex-0.2.11/HACKING.md delete mode 100644 vendor/regex-0.2.11/PERFORMANCE.md delete mode 100644 vendor/regex-0.2.11/README.md delete mode 100644 vendor/regex-0.2.11/UNICODE.md delete mode 100644 vendor/regex-0.2.11/appveyor.yml delete mode 100644 vendor/regex-0.2.11/build.rs delete mode 100755 vendor/regex-0.2.11/ci/after_success.sh delete mode 100755 vendor/regex-0.2.11/ci/run-kcov delete mode 100755 vendor/regex-0.2.11/ci/run-shootout-test delete mode 100755 vendor/regex-0.2.11/ci/script.sh delete mode 100644 vendor/regex-0.2.11/examples/regexdna-input.txt delete mode 100644 vendor/regex-0.2.11/examples/regexdna-output.txt delete mode 100644 vendor/regex-0.2.11/examples/shootout-regex-dna-bytes.rs delete mode 100644 vendor/regex-0.2.11/examples/shootout-regex-dna-cheat.rs delete mode 100644 vendor/regex-0.2.11/examples/shootout-regex-dna-replace.rs delete mode 100644 vendor/regex-0.2.11/examples/shootout-regex-dna-single-cheat.rs delete mode 100644 vendor/regex-0.2.11/examples/shootout-regex-dna-single.rs delete mode 100644 vendor/regex-0.2.11/examples/shootout-regex-dna.rs delete mode 100755 vendor/regex-0.2.11/scripts/frequencies.py delete mode 100755 vendor/regex-0.2.11/scripts/regex-match-tests.py delete mode 100644 vendor/regex-0.2.11/src/backtrack.rs delete mode 100644 vendor/regex-0.2.11/src/compile.rs delete mode 100644 vendor/regex-0.2.11/src/dfa.rs delete mode 100644 vendor/regex-0.2.11/src/error.rs delete mode 100644 vendor/regex-0.2.11/src/exec.rs delete mode 100644 vendor/regex-0.2.11/src/expand.rs delete mode 100644 vendor/regex-0.2.11/src/freqs.rs delete mode 100644 vendor/regex-0.2.11/src/input.rs delete mode 100644 vendor/regex-0.2.11/src/lib.rs delete mode 100644 vendor/regex-0.2.11/src/literal/mod.rs delete mode 100644 vendor/regex-0.2.11/src/literal/teddy_avx2/fallback.rs delete mode 100644 vendor/regex-0.2.11/src/literal/teddy_avx2/imp.rs delete mode 100644 vendor/regex-0.2.11/src/literal/teddy_avx2/mod.rs delete mode 100644 vendor/regex-0.2.11/src/literal/teddy_ssse3/fallback.rs delete mode 100644 vendor/regex-0.2.11/src/literal/teddy_ssse3/imp.rs delete mode 100644 vendor/regex-0.2.11/src/literal/teddy_ssse3/mod.rs delete mode 100644 vendor/regex-0.2.11/src/pattern.rs delete mode 100644 vendor/regex-0.2.11/src/pikevm.rs delete mode 100644 vendor/regex-0.2.11/src/prog.rs delete mode 100644 vendor/regex-0.2.11/src/re_builder.rs delete mode 100644 vendor/regex-0.2.11/src/re_bytes.rs delete mode 100644 vendor/regex-0.2.11/src/re_set.rs delete mode 100644 vendor/regex-0.2.11/src/re_trait.rs delete mode 100644 vendor/regex-0.2.11/src/re_unicode.rs delete mode 100644 vendor/regex-0.2.11/src/sparse.rs delete mode 100644 vendor/regex-0.2.11/src/testdata/LICENSE delete mode 100644 vendor/regex-0.2.11/src/testdata/README delete mode 100644 vendor/regex-0.2.11/src/testdata/basic.dat delete mode 100644 vendor/regex-0.2.11/src/testdata/nullsubexpr.dat delete mode 100644 vendor/regex-0.2.11/src/testdata/repetition.dat delete mode 100644 vendor/regex-0.2.11/src/utf8.rs delete mode 100644 vendor/regex-0.2.11/src/vector/avx2.rs delete mode 100644 vendor/regex-0.2.11/src/vector/mod.rs delete mode 100644 vendor/regex-0.2.11/src/vector/ssse3.rs delete mode 100644 vendor/regex-0.2.11/tests/api.rs delete mode 100644 vendor/regex-0.2.11/tests/api_str.rs delete mode 100644 vendor/regex-0.2.11/tests/bytes.rs delete mode 100644 vendor/regex-0.2.11/tests/crazy.rs delete mode 100644 vendor/regex-0.2.11/tests/flags.rs delete mode 100644 vendor/regex-0.2.11/tests/fowler.rs delete mode 100644 vendor/regex-0.2.11/tests/macros.rs delete mode 100644 vendor/regex-0.2.11/tests/macros_bytes.rs delete mode 100644 vendor/regex-0.2.11/tests/macros_str.rs delete mode 100644 vendor/regex-0.2.11/tests/misc.rs delete mode 100644 vendor/regex-0.2.11/tests/multiline.rs delete mode 100644 vendor/regex-0.2.11/tests/noparse.rs delete mode 100644 vendor/regex-0.2.11/tests/regression.rs delete mode 100644 vendor/regex-0.2.11/tests/replace.rs delete mode 100644 vendor/regex-0.2.11/tests/searcher.rs delete mode 100644 vendor/regex-0.2.11/tests/set.rs delete mode 100644 vendor/regex-0.2.11/tests/shortest_match.rs delete mode 100644 vendor/regex-0.2.11/tests/suffix_reverse.rs delete mode 100644 vendor/regex-0.2.11/tests/test_backtrack.rs delete mode 100644 vendor/regex-0.2.11/tests/test_backtrack_bytes.rs delete mode 100644 vendor/regex-0.2.11/tests/test_backtrack_utf8bytes.rs delete mode 100644 vendor/regex-0.2.11/tests/test_default.rs delete mode 100644 vendor/regex-0.2.11/tests/test_default_bytes.rs delete mode 100644 vendor/regex-0.2.11/tests/test_nfa.rs delete mode 100644 vendor/regex-0.2.11/tests/test_nfa_bytes.rs delete mode 100644 vendor/regex-0.2.11/tests/test_nfa_utf8bytes.rs delete mode 100644 vendor/regex-0.2.11/tests/unicode.rs delete mode 100644 vendor/regex-0.2.11/tests/word_boundary.rs delete mode 100644 vendor/regex-0.2.11/tests/word_boundary_ascii.rs delete mode 100644 vendor/regex-0.2.11/tests/word_boundary_unicode.rs delete mode 100644 vendor/regex-syntax-0.5.6/.cargo-checksum.json delete mode 100644 vendor/regex-syntax-0.5.6/benches/bench.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/ast/mod.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/ast/parse.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/ast/print.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/ast/visitor.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/either.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/error.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/hir/interval.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/hir/literal/mod.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/hir/mod.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/hir/print.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/hir/translate.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/hir/visitor.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/lib.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/parser.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/age.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/case_folding_simple.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/general_category.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/mod.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/perl_word.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/property_bool.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/property_names.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/property_values.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/script.rs delete mode 100644 vendor/regex-syntax-0.5.6/src/unicode_tables/script_extension.rs create mode 100644 vendor/sha-1/.cargo-checksum.json rename vendor/{error-chain-0.11.0 => sha-1}/Cargo.toml (50%) create mode 100644 vendor/sha-1/LICENSE-APACHE create mode 100644 vendor/sha-1/LICENSE-MIT create mode 100644 vendor/sha-1/benches/lib.rs create mode 100644 vendor/sha-1/examples/sha1sum.rs create mode 100644 vendor/sha-1/src/consts.rs create mode 100644 vendor/sha-1/src/lib.rs create mode 100644 vendor/sha-1/src/utils.rs create mode 100644 vendor/sha-1/tests/data/one_million_a.output.bin create mode 100644 vendor/sha-1/tests/data/test1.input.bin create mode 100644 vendor/sha-1/tests/data/test1.output.bin create mode 100644 vendor/sha-1/tests/data/test2.input.bin create mode 100644 vendor/sha-1/tests/data/test2.output.bin create mode 100644 vendor/sha-1/tests/data/test3.input.bin create mode 100644 vendor/sha-1/tests/data/test3.output.bin create mode 100644 vendor/sha-1/tests/data/test4.input.bin create mode 100644 vendor/sha-1/tests/data/test4.output.bin create mode 100644 vendor/sha-1/tests/lib.rs delete mode 100644 vendor/syn-0.11.11/.cargo-checksum.json delete mode 100644 vendor/syn-0.11.11/Cargo.toml delete mode 100644 vendor/syn-0.11.11/README.md delete mode 100644 vendor/syn-0.11.11/src/aster/generics.rs delete mode 100644 vendor/syn-0.11.11/src/aster/ident.rs delete mode 100644 vendor/syn-0.11.11/src/aster/invoke.rs delete mode 100644 vendor/syn-0.11.11/src/aster/lifetime.rs delete mode 100644 vendor/syn-0.11.11/src/aster/mod.rs delete mode 100644 vendor/syn-0.11.11/src/aster/path.rs delete mode 100644 vendor/syn-0.11.11/src/aster/qpath.rs delete mode 100644 vendor/syn-0.11.11/src/aster/ty.rs delete mode 100644 vendor/syn-0.11.11/src/aster/ty_param.rs delete mode 100644 vendor/syn-0.11.11/src/aster/where_predicate.rs delete mode 100644 vendor/syn-0.11.11/src/attr.rs delete mode 100644 vendor/syn-0.11.11/src/constant.rs delete mode 100644 vendor/syn-0.11.11/src/data.rs delete mode 100644 vendor/syn-0.11.11/src/derive.rs delete mode 100644 vendor/syn-0.11.11/src/escape.rs delete mode 100644 vendor/syn-0.11.11/src/expr.rs delete mode 100644 vendor/syn-0.11.11/src/fold.rs delete mode 100644 vendor/syn-0.11.11/src/generics.rs delete mode 100644 vendor/syn-0.11.11/src/ident.rs delete mode 100644 vendor/syn-0.11.11/src/item.rs delete mode 100644 vendor/syn-0.11.11/src/krate.rs delete mode 100644 vendor/syn-0.11.11/src/lib.rs delete mode 100644 vendor/syn-0.11.11/src/lit.rs delete mode 100644 vendor/syn-0.11.11/src/mac.rs delete mode 100644 vendor/syn-0.11.11/src/op.rs delete mode 100644 vendor/syn-0.11.11/src/ty.rs delete mode 100644 vendor/syn-0.11.11/src/visit.rs delete mode 100644 vendor/synom/.cargo-checksum.json delete mode 100644 vendor/synom/Cargo.toml delete mode 100644 vendor/synom/README.md delete mode 100644 vendor/synom/src/helper.rs delete mode 100644 vendor/synom/src/lib.rs delete mode 100644 vendor/synom/src/space.rs create mode 100644 vendor/typenum/.cargo-checksum.json create mode 100644 vendor/typenum/CHANGELOG.md create mode 100644 vendor/typenum/Cargo.toml create mode 100644 vendor/typenum/LICENSE create mode 100644 vendor/typenum/README.md create mode 100644 vendor/typenum/build/main.rs create mode 100644 vendor/typenum/build/op.rs create mode 100644 vendor/typenum/build/tests.rs create mode 100644 vendor/typenum/src/array.rs create mode 100644 vendor/typenum/src/bit.rs create mode 100644 vendor/typenum/src/int.rs create mode 100644 vendor/typenum/src/lib.rs create mode 100644 vendor/typenum/src/marker_traits.rs create mode 100644 vendor/typenum/src/operator_aliases.rs create mode 100644 vendor/typenum/src/private.rs create mode 100644 vendor/typenum/src/type_operators.rs create mode 100644 vendor/typenum/src/uint.rs create mode 100644 vendor/typenum/tests/test.rs create mode 100644 vendor/ucd-trie/.cargo-checksum.json create mode 100644 vendor/ucd-trie/Cargo.toml rename vendor/{synom => ucd-trie}/LICENSE-APACHE (100%) create mode 100644 vendor/ucd-trie/LICENSE-MIT create mode 100644 vendor/ucd-trie/README.md create mode 100644 vendor/ucd-trie/benches/bench.rs create mode 100644 vendor/ucd-trie/src/general_category.rs create mode 100644 vendor/ucd-trie/src/lib.rs create mode 100644 vendor/ucd-trie/src/owned.rs delete mode 100644 vendor/unicode-xid-0.0.4/.cargo-checksum.json delete mode 100644 vendor/unicode-xid-0.0.4/COPYRIGHT delete mode 100644 vendor/unicode-xid-0.0.4/Cargo.toml delete mode 100644 vendor/unicode-xid-0.0.4/LICENSE-MIT delete mode 100644 vendor/unicode-xid-0.0.4/README.md delete mode 100755 vendor/unicode-xid-0.0.4/scripts/unicode.py delete mode 100644 vendor/unicode-xid-0.0.4/src/lib.rs delete mode 100644 vendor/unicode-xid-0.0.4/src/tables.rs delete mode 100644 vendor/unicode-xid-0.0.4/src/tests.rs diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 65cdfe67b5..e785f03d7d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -19,9 +19,16 @@ hop on [#rust-internals][pound-rust-internals]. As a reminder, all contributors are expected to follow our [Code of Conduct][coc]. +The [rustc-guide] is your friend! It describes how the compiler works and how +to contribute to it in more detail than this document. + +If this is your first time contributing, the [walkthrough] chapter of the guide +can give you a good example of how a typical contribution would go. + [pound-rust-internals]: https://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust-internals [internals]: https://internals.rust-lang.org [coc]: https://www.rust-lang.org/conduct.html +[walkthrough]: https://rust-lang.github.io/rustc-guide/walkthrough.html ## Feature Requests [feature-requests]: #feature-requests @@ -89,222 +96,14 @@ $ RUST_BACKTRACE=1 rustc ... ``` ## The Build System -[the-build-system]: #the-build-system - -Rust's build system allows you to bootstrap the compiler, run tests & -benchmarks, generate documentation, install a fresh build of Rust, and more. -It's your best friend when working on Rust, allowing you to compile & test -your contributions before submission. - -The build system lives in [the `src/bootstrap` directory][bootstrap] in the -project root. Our build system is itself written in Rust and is based on Cargo -to actually build all the compiler's crates. If you have questions on the build -system internals, try asking in [`#rust-internals`][pound-rust-internals]. - -[bootstrap]: https://github.com/rust-lang/rust/tree/master/src/bootstrap/ - -### Configuration -[configuration]: #configuration - -Before you can start building the compiler you need to configure the build for -your system. In most cases, that will just mean using the defaults provided -for Rust. - -To change configuration, you must copy the file `config.toml.example` -to `config.toml` in the directory from which you will be running the build, and -change the settings provided. - -There are large number of options provided in this config file that will alter the -configuration used in the build process. Some options to note: - -#### `[llvm]`: -- `assertions = true` = This enables LLVM assertions, which makes LLVM misuse cause an assertion failure instead of weird misbehavior. This also slows down the compiler's runtime by ~20%. -- `ccache = true` - Use ccache when building llvm - -#### `[build]`: -- `compiler-docs = true` - Build compiler documentation - -#### `[rust]`: -- `debuginfo = true` - Build a compiler with debuginfo. Makes building rustc slower, but then you can use a debugger to debug `rustc`. -- `debuginfo-lines = true` - An alternative to `debuginfo = true` that doesn't let you use a debugger, but doesn't make building rustc slower and still gives you line numbers in backtraces. -- `debuginfo-tools = true` - Build the extended tools with debuginfo. -- `debug-assertions = true` - Makes the log output of `debug!` work. -- `optimize = false` - Disable optimizations to speed up compilation of stage1 rust, but makes the stage1 compiler x100 slower. - -For more options, the `config.toml` file contains commented out defaults, with -descriptions of what each option will do. - -Note: Previously the `./configure` script was used to configure this -project. It can still be used, but it's recommended to use a `config.toml` -file. If you still have a `config.mk` file in your directory - from -`./configure` - you may need to delete it for `config.toml` to work. - -### Building -[building]: #building - -A default configuration requires around 3.5 GB of disk space, whereas building a debug configuration may require more than 30 GB. -Dependencies -- [build dependencies](README.md#building-from-source) -- `gdb` 6.2.0 minimum, 7.1 or later recommended for test builds +For info on how to configure and build the compiler, please see [this +chapter][rustcguidebuild] of the rustc-guide. This chapter contains info for +contributions to the compiler and the standard library. It also lists some +really useful commands to the build system (`./x.py`), which could save you a +lot of time. -The build system uses the `x.py` script to control the build process. This script -is used to build, test, and document various parts of the compiler. You can -execute it as: - -```sh -python x.py build -``` - -On some systems you can also use the shorter version: - -```sh -./x.py build -``` - -To learn more about the driver and top-level targets, you can execute: - -```sh -python x.py --help -``` - -The general format for the driver script is: - -```sh -python x.py [] -``` - -Some example commands are `build`, `test`, and `doc`. These will build, test, -and document the specified directory. The second argument, ``, is -optional and defaults to working over the entire compiler. If specified, -however, only that specific directory will be built. For example: - -```sh -# build the entire compiler -python x.py build - -# build all documentation -python x.py doc - -# run all test suites -python x.py test - -# build only the standard library -python x.py build src/libstd - -# test only one particular test suite -python x.py test src/test/rustdoc - -# build only the stage0 libcore library -python x.py build src/libcore --stage 0 -``` - -You can explore the build system through the various `--help` pages for each -subcommand. For example to learn more about a command you can run: - -``` -python x.py build --help -``` - -To learn about all possible rules you can execute, run: - -``` -python x.py build --help --verbose -``` - -Note: Previously `./configure` and `make` were used to build this project. -They are still available, but `x.py` is the recommended build system. - -### Useful commands -[useful-commands]: #useful-commands - -Some common invocations of `x.py` are: - -- `x.py build --help` - show the help message and explain the subcommand -- `x.py build src/libtest --stage 1` - build up to (and including) the first - stage. For most cases we don't need to build the stage2 compiler, so we can - save time by not building it. The stage1 compiler is a fully functioning - compiler and (probably) will be enough to determine if your change works as - expected. -- `x.py build src/rustc --stage 1` - This will build just rustc, without libstd. - This is the fastest way to recompile after you changed only rustc source code. - Note however that the resulting rustc binary won't have a stdlib to link - against by default. You can build libstd once with `x.py build src/libstd`, - but it is only guaranteed to work if recompiled, so if there are any issues - recompile it. -- `x.py test` - build the full compiler & run all tests (takes a while). This - is what gets run by the continuous integration system against your pull - request. You should run this before submitting to make sure your tests pass - & everything builds in the correct manner. -- `x.py test src/libstd --stage 1` - test the standard library without - recompiling stage 2. -- `x.py test src/test/run-pass --test-args TESTNAME` - Run a matching set of - tests. - - `TESTNAME` should be a substring of the tests to match against e.g. it could - be the fully qualified test name, or just a part of it. - `TESTNAME=collections::hash::map::test_map::test_capacity_not_less_than_len` - or `TESTNAME=test_capacity_not_less_than_len`. -- `x.py test src/test/run-pass --stage 1 --test-args ` - - Run a single rpass test with the stage1 compiler (this will be quicker than - running the command above as we only build the stage1 compiler, not the entire - thing). You can also leave off the directory argument to run all stage1 test - types. -- `x.py test src/libcore --stage 1` - Run stage1 tests in `libcore`. -- `x.py test src/tools/tidy` - Check that the source code is in compliance with - Rust's style guidelines. There is no official document describing Rust's full - guidelines as of yet, but basic rules like 4 spaces for indentation and no - more than 99 characters in a single line should be kept in mind when writing - code. - -### Using your local build -[using-local-build]: #using-local-build - -If you use Rustup to manage your rust install, it has a feature called ["custom -toolchains"][toolchain-link] that you can use to access your newly-built compiler -without having to install it to your system or user PATH. If you've run `python -x.py build`, then you can add your custom rustc to a new toolchain like this: - -[toolchain-link]: https://github.com/rust-lang-nursery/rustup.rs#working-with-custom-toolchains-and-local-builds - -``` -rustup toolchain link build//stage2 -``` - -Where `` is the build triple for the host (the triple of your -computer, by default), and `` is the name for your custom toolchain. (If you -added `--stage 1` to your build command, the compiler will be in the `stage1` -folder instead.) You'll only need to do this once - it will automatically point -to the latest build you've done. - -Once this is set up, you can use your custom toolchain just like any other. For -example, if you've named your toolchain `local`, running `cargo +local build` will -compile a project with your custom rustc, setting `rustup override set local` will -override the toolchain for your current directory, and `cargo +local doc` will use -your custom rustc and rustdoc to generate docs. (If you do this with a `--stage 1` -build, you'll need to build rustdoc specially, since it's not normally built in -stage 1. `python x.py build --stage 1 src/libstd src/tools/rustdoc` will build -rustdoc and libstd, which will allow rustdoc to be run with that toolchain.) - -### Out-of-tree builds -[out-of-tree-builds]: #out-of-tree-builds - -Rust's `x.py` script fully supports out-of-tree builds - it looks for -the Rust source code from the directory `x.py` was found in, but it -reads the `config.toml` configuration file from the directory it's -run in, and places all build artifacts within a subdirectory named `build`. - -This means that if you want to do an out-of-tree build, you can just do it: -``` -$ cd my/build/dir -$ cp ~/my-config.toml config.toml # Or fill in config.toml otherwise -$ path/to/rust/x.py build -... -$ # This will use the Rust source code in `path/to/rust`, but build -$ # artifacts will now be in ./build -``` - -It's absolutely fine to have multiple build directories with different -`config.toml` configurations using the same code. +[rustcguidebuild]: https://rust-lang.github.io/rustc-guide/how-to-build-and-run.html ## Pull Requests [pull-requests]: #pull-requests @@ -320,26 +119,13 @@ bring those changes into the source repository. Please make pull requests against the `master` branch. -Compiling all of `./x.py test` can take a while. When testing your pull request, -consider using one of the more specialized `./x.py` targets to cut down on the -amount of time you have to wait. You need to have built the compiler at least -once before running these will work, but that’s only one full build rather than -one each time. - - $ python x.py test --stage 1 - -is one such example, which builds just `rustc`, and then runs the tests. If -you’re adding something to the standard library, try - - $ python x.py test src/libstd --stage 1 - Please make sure your pull request is in compliance with Rust's style guidelines by running $ python x.py test src/tools/tidy Make this check before every pull request (and every new commit in a pull -request) ; you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) +request); you can add [git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) before every push to make sure you never forget to make this check. All pull requests are reviewed by another person. We have a bot, @@ -375,10 +161,10 @@ it can be found [here][rctd]. Currently building Rust will also build the following external projects: -* [clippy](https://github.com/rust-lang-nursery/rust-clippy) -* [miri](https://github.com/solson/miri) -* [rustfmt](https://github.com/rust-lang-nursery/rustfmt) -* [rls](https://github.com/rust-lang-nursery/rls/) +* [clippy](https://github.com/rust-lang/rust-clippy) +* [miri](https://github.com/rust-lang/miri) +* [rustfmt](https://github.com/rust-lang/rustfmt) +* [rls](https://github.com/rust-lang/rls/) We allow breakage of these tools in the nightly channel. Maintainers of these projects will be notified of the breakages and should fix them as soon as @@ -405,9 +191,9 @@ before the PR is merged. Rust's build system builds a number of tools that make use of the internals of the compiler. This includes -[Clippy](https://github.com/rust-lang-nursery/rust-clippy), -[RLS](https://github.com/rust-lang-nursery/rls) and -[rustfmt](https://github.com/rust-lang-nursery/rustfmt). If these tools +[Clippy](https://github.com/rust-lang/rust-clippy), +[RLS](https://github.com/rust-lang/rls) and +[rustfmt](https://github.com/rust-lang/rustfmt). If these tools break because of your changes, you may run into a sort of "chicken and egg" problem. These tools rely on the latest compiler to be built so you can't update them to reflect your changes to the compiler until those changes are merged into @@ -467,10 +253,10 @@ to complete a few more steps which are outlined with their rationale below. *(This error may change in the future to include more information.)* ``` -error: failed to resolve patches for `https://github.com/rust-lang-nursery/rustfmt` +error: failed to resolve patches for `https://github.com/rust-lang/rustfmt` Caused by: - patch for `rustfmt-nightly` in `https://github.com/rust-lang-nursery/rustfmt` did not resolve to any crates + patch for `rustfmt-nightly` in `https://github.com/rust-lang/rustfmt` did not resolve to any crates failed to run: ~/rust/build/x86_64-unknown-linux-gnu/stage0/bin/cargo build --manifest-path ~/rust/src/bootstrap/Cargo.toml ``` @@ -532,6 +318,12 @@ to check small fixes. For example, `rustdoc src/doc/reference.md` will render reference to `doc/reference.html`. The CSS might be messed up, but you can verify that the HTML is right. +Additionally, contributions to the [rustc-guide] are always welcome. Contributions +can be made directly at [the +rust-lang/rustc-guide](https://github.com/rust-lang/rustc-guide) repo. The issue +tracker in that repo is also a great way to find things that need doing. There +are issues for beginners and advanced compiler devs alike! + ## Issue Triage [issue-triage]: #issue-triage @@ -627,7 +419,7 @@ For people new to Rust, and just starting to contribute, or even for more seasoned developers, some useful places to look for information are: -* The [rustc guide] contains information about how various parts of the compiler work +* The [rustc guide] contains information about how various parts of the compiler work and how to contribute to the compiler * [Rust Forge][rustforge] contains additional documentation, including write-ups of how to achieve common tasks * The [Rust Internals forum][rif], a place to ask questions and discuss Rust's internals diff --git a/COPYRIGHT b/COPYRIGHT index 6596c5a3d9..dc9abf84b8 100644 --- a/COPYRIGHT +++ b/COPYRIGHT @@ -23,7 +23,7 @@ The Rust Project includes packages written by third parties. The following third party packages are included, and carry their own copyright notices and license terms: -* LLVM. Code for this package is found in src/llvm. +* LLVM. Code for this package is found in src/llvm-project. Copyright (c) 2003-2013 University of Illinois at Urbana-Champaign. All rights reserved. @@ -73,8 +73,8 @@ their own copyright notices and license terms: OTHER DEALINGS WITH THE SOFTWARE. * Additional libraries included in LLVM carry separate - BSD-compatible licenses. See src/llvm/LICENSE.txt for - details. + BSD-compatible licenses. See src/llvm-project/llvm/LICENSE.TXT + for details. * compiler-rt, in src/compiler-rt is dual licensed under LLVM's license and MIT: diff --git a/Cargo.lock b/Cargo.lock index 9f2bba2830..e8bab07444 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -1,3 +1,5 @@ +# This file is automatically @generated by Cargo. +# It is not intended for manual editing. [[package]] name = "adler32" version = "1.0.3" @@ -15,7 +17,7 @@ dependencies = [ name = "alloc" version = "0.0.0" dependencies = [ - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", "rand_xorshift 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)", @@ -42,6 +44,11 @@ dependencies = [ "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "arc-swap" +version = "0.3.7" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "arena" version = "0.0.0" @@ -50,24 +57,25 @@ dependencies = [ ] [[package]] -name = "arrayvec" -version = "0.4.7" +name = "argon2rs" +version = "0.2.5" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "nodrop 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)", + "blake2-rfc 0.2.18 (registry+https://github.com/rust-lang/crates.io-index)", + "scoped_threadpool 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] -name = "assert_cli" -version = "0.6.2" +name = "arrayref" +version = "0.3.5" +source = "registry+https://github.com/rust-lang/crates.io-index" + +[[package]] +name = "arrayvec" +version = "0.4.7" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "colored 1.6.0 (registry+https://github.com/rust-lang/crates.io-index)", - "difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "environment 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", - "failure_derive 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", - "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", + "nodrop 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] @@ -98,7 +106,7 @@ version = "0.1.27" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-std-workspace-core 1.0.0", ] @@ -126,6 +134,24 @@ name = "bitflags" version = "1.0.4" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "blake2-rfc" +version = "0.2.18" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)", + "constant_time_eq 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "block-buffer" +version = "0.3.3" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "arrayref 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)", + "byte-tools 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "bootstrap" version = "0.0.0" @@ -170,9 +196,14 @@ source = "registry+https://github.com/rust-lang/crates.io-index" name = "build_helper" version = "0.1.0" +[[package]] +name = "byte-tools" +version = "0.2.0" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "bytecount" -version = "0.4.0" +version = "0.5.1" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "packed_simd 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)", @@ -183,6 +214,15 @@ name = "byteorder" version = "1.2.7" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "bytes" +version = "0.4.11" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", + "iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "bytesize" version = "1.0.0" @@ -190,7 +230,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "cargo" -version = "0.34.0" +version = "0.35.0" dependencies = [ "atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)", "bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", @@ -198,13 +238,13 @@ dependencies = [ "bytesize 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)", "clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)", "core-foundation 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)", - "crates-io 0.22.0", + "crates-io 0.23.0", "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", "crypto-hash 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)", "curl 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)", "curl-sys 0.4.15 (registry+https://github.com/rust-lang/crates.io-index)", "env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)", "flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)", "fs2 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)", @@ -214,8 +254,8 @@ dependencies = [ "glob 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)", "hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", "home 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", - "ignore 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)", - "im-rc 12.2.0 (registry+https://github.com/rust-lang/crates.io-index)", + "ignore 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "im-rc 12.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "jobserver 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "lazycell 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)", @@ -258,6 +298,18 @@ dependencies = [ "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "cargo_metadata" +version = "0.7.1" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)", + "semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)", + "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "cargotest2" version = "0.1.0" @@ -318,7 +370,7 @@ dependencies = [ name = "clippy" version = "0.0.212" dependencies = [ - "cargo_metadata 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "clippy-mini-macro-test 0.2.0", "clippy_dev 0.0.1", "clippy_lints 0.0.212", @@ -342,7 +394,7 @@ name = "clippy_dev" version = "0.0.1" dependencies = [ "clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)", - "itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", + "itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", "walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)", @@ -352,9 +404,9 @@ dependencies = [ name = "clippy_lints" version = "0.0.212" dependencies = [ - "cargo_metadata 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "if_chain 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", - "itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", + "itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", "pulldown-cmark 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", @@ -411,7 +463,7 @@ dependencies = [ [[package]] name = "compiler_builtins" -version = "0.1.4" +version = "0.1.5" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)", @@ -459,6 +511,11 @@ dependencies = [ "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "constant_time_eq" +version = "0.1.3" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "core" version = "0.0.0" @@ -482,10 +539,11 @@ source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "crates-io" -version = "0.22.0" +version = "0.23.0" dependencies = [ "curl 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)", - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", + "http 0.1.16 (registry+https://github.com/rust-lang/crates.io-index)", "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", @@ -510,13 +568,13 @@ dependencies = [ [[package]] name = "crossbeam-channel" -version = "0.2.6" +version = "0.3.4" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "crossbeam-epoch 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", - "crossbeam-utils 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)", - "parking_lot 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)", - "rand 0.5.5 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-epoch 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", + "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", "smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)", ] @@ -529,6 +587,15 @@ dependencies = [ "crossbeam-utils 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "crossbeam-deque" +version = "0.6.3" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "crossbeam-epoch 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "crossbeam-epoch" version = "0.3.1" @@ -545,12 +612,12 @@ dependencies = [ [[package]] name = "crossbeam-epoch" -version = "0.6.0" +version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)", "cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", - "crossbeam-utils 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "memoffset 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)", "scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", @@ -564,11 +631,6 @@ dependencies = [ "cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", ] -[[package]] -name = "crossbeam-utils" -version = "0.5.0" -source = "registry+https://github.com/rust-lang/crates.io-index" - [[package]] name = "crossbeam-utils" version = "0.6.2" @@ -654,6 +716,14 @@ name = "difference" version = "2.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "digest" +version = "0.7.6" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "generic-array 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "directories" version = "1.0.2" @@ -663,12 +733,22 @@ dependencies = [ "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "dirs" +version = "1.0.4" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "redox_users 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "dlmalloc" -version = "0.1.1" +version = "0.1.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-std-workspace-core 1.0.0", ] @@ -724,11 +804,6 @@ dependencies = [ "termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", ] -[[package]] -name = "environment" -version = "0.1.1" -source = "registry+https://github.com/rust-lang/crates.io-index" - [[package]] name = "error-chain" version = "0.11.0" @@ -754,16 +829,16 @@ dependencies = [ [[package]] name = "failure" -version = "0.1.3" +version = "0.1.5" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "backtrace 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)", - "failure_derive 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "failure_derive 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "failure_derive" -version = "0.1.3" +version = "0.1.5" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)", @@ -772,6 +847,11 @@ dependencies = [ "synstructure 0.10.1 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "fake-simd" +version = "0.1.2" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "filetime" version = "0.2.4" @@ -826,7 +906,7 @@ name = "fortanix-sgx-abi" version = "0.3.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-std-workspace-core 1.0.0", ] @@ -889,6 +969,14 @@ dependencies = [ "termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "generic-array" +version = "0.9.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "typenum 1.10.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "getopts" version = "0.2.17" @@ -955,6 +1043,22 @@ dependencies = [ "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "handlebars" +version = "1.1.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "pest_derive 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "quick-error 1.2.2 (registry+https://github.com/rust-lang/crates.io-index)", + "regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", + "walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "heck" version = "0.3.0" @@ -990,6 +1094,16 @@ dependencies = [ "syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "http" +version = "0.1.16" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "fnv 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)", + "itoa 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "humantime" version = "1.2.0" @@ -1015,10 +1129,10 @@ source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "ignore" -version = "0.4.4" +version = "0.4.6" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "crossbeam-channel 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)", "globset 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", @@ -1032,7 +1146,7 @@ dependencies = [ [[package]] name = "im-rc" -version = "12.2.0" +version = "12.3.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", @@ -1054,6 +1168,15 @@ dependencies = [ "xz2 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "iovec" +version = "0.1.2" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "is-match" version = "0.1.0" @@ -1067,6 +1190,14 @@ dependencies = [ "either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "itertools" +version = "0.8.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "itoa" version = "0.4.3" @@ -1099,7 +1230,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "jsonrpc-core" -version = "9.0.0" +version = "10.0.1" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", @@ -1118,21 +1249,6 @@ dependencies = [ "winapi-build 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", ] -[[package]] -name = "languageserver-types" -version = "0.51.1" -source = "registry+https://github.com/rust-lang/crates.io-index" -dependencies = [ - "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", - "num-derive 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", - "num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)", - "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", - "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", - "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", - "url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)", - "url_serde 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", -] - [[package]] name = "lazy_static" version = "0.2.11" @@ -1232,6 +1348,31 @@ dependencies = [ "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "lsp-codec" +version = "0.1.1" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "lsp-types" +version = "0.55.4" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", + "num-derive 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", + "num-traits 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)", + "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", + "url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)", + "url_serde 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "lzma-sys" version = "0.1.10" @@ -1306,6 +1447,34 @@ dependencies = [ "toml-query 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "mdbook" +version = "0.2.3" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "ammonia 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "chrono 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)", + "elasticlunr-rs 2.3.4 (registry+https://github.com/rust-lang/crates.io-index)", + "env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)", + "error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)", + "handlebars 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", + "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)", + "open 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)", + "pulldown-cmark 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", + "regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", + "shlex 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", + "tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)", + "toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)", + "toml-query 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "memchr" version = "2.1.1" @@ -1332,7 +1501,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "minifier" -version = "0.0.20" +version = "0.0.28" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "macro-utils 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", @@ -1366,6 +1535,56 @@ dependencies = [ "miniz_oxide 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "mio" +version = "0.6.16" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "fuchsia-zircon 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", + "fuchsia-zircon-sys 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", + "iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", + "kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)", + "lazycell 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)", + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "miow 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)", + "net2 0.2.33 (registry+https://github.com/rust-lang/crates.io-index)", + "slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "mio-named-pipes" +version = "0.1.6" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "miow 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "mio-uds" +version = "0.6.7" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "miow" +version = "0.2.1" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)", + "net2 0.2.33 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", + "ws2_32-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "miow" version = "0.3.3" @@ -1388,9 +1607,20 @@ dependencies = [ "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-workspace-hack 1.0.0", "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", + "shell-escape 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", "vergen 3.0.4 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "net2" +version = "0.2.33" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "new_debug_unreachable" version = "1.0.1" @@ -1446,8 +1676,8 @@ name = "opener" version = "0.3.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", - "failure_derive 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", + "failure_derive 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] @@ -1519,7 +1749,7 @@ dependencies = [ name = "panic_abort" version = "0.0.0" dependencies = [ - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", ] @@ -1529,7 +1759,7 @@ name = "panic_unwind" version = "0.0.0" dependencies = [ "alloc 0.0.0", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", "unwind 0.0.0", @@ -1544,6 +1774,15 @@ dependencies = [ "parking_lot_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "parking_lot" +version = "0.7.1" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "lock_api 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "parking_lot_core 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "parking_lot_core" version = "0.3.0" @@ -1555,6 +1794,18 @@ dependencies = [ "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "parking_lot_core" +version = "0.4.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc_version 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", + "smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "percent-encoding" version = "1.0.1" @@ -1565,6 +1816,14 @@ name = "pest" version = "1.0.6" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "pest" +version = "2.1.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "ucd-trie 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "pest_derive" version = "1.0.8" @@ -1575,6 +1834,37 @@ dependencies = [ "syn 0.11.11 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "pest_derive" +version = "2.1.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "pest_generator 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "pest_generator" +version = "2.1.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "pest_meta 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "proc-macro2 0.4.24 (registry+https://github.com/rust-lang/crates.io-index)", + "quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)", + "syn 0.15.22 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "pest_meta" +version = "2.1.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "maplit 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)", + "pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "sha-1 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "petgraph" version = "0.4.13" @@ -1682,7 +1972,7 @@ name = "profiler_builtins" version = "0.0.0" dependencies = [ "cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", ] @@ -1754,7 +2044,7 @@ dependencies = [ [[package]] name = "racer" -version = "2.1.16" +version = "2.1.19" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", @@ -1764,8 +2054,8 @@ dependencies = [ "humantime 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-syntax 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-syntax 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] @@ -1897,6 +2187,17 @@ dependencies = [ "redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "redox_users" +version = "0.2.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "argon2rs 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", + "rand 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)", + "redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "regex" version = "0.2.11" @@ -1955,41 +2256,48 @@ dependencies = [ [[package]] name = "rls" -version = "1.33.0" +version = "1.34.0" dependencies = [ - "cargo 0.34.0", - "cargo_metadata 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "cargo 0.35.0", + "cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "clippy_lints 0.0.212", - "crossbeam-channel 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)", "difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)", - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "heck 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", "home 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", - "itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", - "jsonrpc-core 9.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "languageserver-types 0.51.1 (registry+https://github.com/rust-lang/crates.io-index)", + "itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)", + "jsonrpc-core 10.0.1 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "lsp-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", + "lsp-types 0.55.4 (registry+https://github.com/rust-lang/crates.io-index)", "num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)", "ordslice 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)", - "racer 2.1.16 (registry+https://github.com/rust-lang/crates.io-index)", - "rand 0.5.5 (registry+https://github.com/rust-lang/crates.io-index)", + "racer 2.1.19 (registry+https://github.com/rust-lang/crates.io-index)", + "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", "rayon 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)", "regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-analysis 0.16.10 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-analysis 0.16.12 (registry+https://github.com/rust-lang/crates.io-index)", "rls-blacklist 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-data 0.18.1 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)", "rls-rustc 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)", "rls-vfs 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-workspace-hack 1.0.0", "rustc_tools_util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", - "rustfmt-nightly 1.0.1", + "rustfmt-nightly 1.0.3", "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", + "serde_ignored 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)", "tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-process 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-timer 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", "toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)", "url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)", "walkdir 2.2.7 (registry+https://github.com/rust-lang/crates.io-index)", @@ -1997,7 +2305,7 @@ dependencies = [ [[package]] name = "rls-analysis" -version = "0.16.10" +version = "0.16.12" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "derive-new 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2005,8 +2313,8 @@ dependencies = [ "itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", "json 0.11.13 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-data 0.18.1 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)", ] @@ -2017,10 +2325,10 @@ source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "rls-data" -version = "0.18.1" +version = "0.18.2" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)", "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2033,7 +2341,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "rls-span" -version = "0.4.0" +version = "0.4.1" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2047,7 +2355,7 @@ version = "0.7.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] @@ -2056,6 +2364,7 @@ version = "0.1.0" dependencies = [ "clap 2.32.0 (registry+https://github.com/rust-lang/crates.io-index)", "mdbook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)", + "mdbook 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] @@ -2073,7 +2382,8 @@ dependencies = [ "jobserver 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "parking_lot 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)", + "num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)", + "parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "polonius-engine 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-rayon 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-rayon-core 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2092,20 +2402,20 @@ dependencies = [ [[package]] name = "rustc-ap-arena" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "rustc-ap-rustc_data_structures 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_data_structures 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rustc-ap-graphviz" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" [[package]] name = "rustc-ap-rustc_cratesio_shim" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2115,16 +2425,16 @@ dependencies = [ [[package]] name = "rustc-ap-rustc_data_structures" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", "ena 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", "parking_lot 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-graphviz 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_cratesio_shim 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-serialize 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-graphviz 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_cratesio_shim 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-serialize 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-rayon 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-rayon-core 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2134,34 +2444,34 @@ dependencies = [ [[package]] name = "rustc-ap-rustc_errors" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_cratesio_shim 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_data_structures 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-serialize 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-syntax_pos 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_cratesio_shim 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_data_structures 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-serialize 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-syntax_pos 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", "termcolor 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rustc-ap-rustc_target" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_cratesio_shim 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_data_structures 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-serialize 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_cratesio_shim 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_data_structures 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-serialize 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rustc-ap-serialize" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2169,29 +2479,29 @@ dependencies = [ [[package]] name = "rustc-ap-syntax" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_data_structures 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_errors 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_target 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-serialize 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-syntax_pos 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_data_structures 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_errors 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_target 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-serialize 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-syntax_pos 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", "scoped-tls 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", "smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] name = "rustc-ap-syntax_pos" -version = "306.0.0" +version = "373.0.0" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-arena 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_data_structures 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-serialize 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-arena 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_data_structures 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-serialize 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", "scoped-tls 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", "unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", ] @@ -2201,7 +2511,7 @@ name = "rustc-demangle" version = "0.1.10" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-std-workspace-core 1.0.0", ] @@ -2261,7 +2571,7 @@ name = "rustc-workspace-hack" version = "1.0.0" dependencies = [ "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", - "parking_lot 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)", + "parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "rand 0.5.5 (registry+https://github.com/rust-lang/crates.io-index)", "scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2301,7 +2611,7 @@ dependencies = [ "alloc 0.0.0", "build_helper 0.1.0", "cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", ] @@ -2390,7 +2700,7 @@ dependencies = [ "ena 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)", "graphviz 0.0.0", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "parking_lot 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)", + "parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-rayon 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-rayon-core 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2495,7 +2805,7 @@ dependencies = [ "alloc 0.0.0", "build_helper 0.1.0", "cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", ] @@ -2522,7 +2832,6 @@ name = "rustc_mir" version = "0.0.0" dependencies = [ "arena 0.0.0", - "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)", "either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)", "graphviz 0.0.0", @@ -2547,7 +2856,7 @@ dependencies = [ "alloc 0.0.0", "build_helper 0.1.0", "cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", ] @@ -2561,6 +2870,7 @@ dependencies = [ "rustc_errors 0.0.0", "rustc_mir 0.0.0", "syntax 0.0.0", + "syntax_ext 0.0.0", "syntax_pos 0.0.0", ] @@ -2579,6 +2889,7 @@ dependencies = [ name = "rustc_privacy" version = "0.0.0" dependencies = [ + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", "rustc 0.0.0", "rustc_data_structures 0.0.0", "rustc_typeck 0.0.0", @@ -2606,8 +2917,8 @@ name = "rustc_save_analysis" version = "0.0.0" dependencies = [ "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-data 0.18.1 (registry+https://github.com/rust-lang/crates.io-index)", - "rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)", + "rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)", "rustc 0.0.0", "rustc-serialize 0.3.24 (registry+https://github.com/rust-lang/crates.io-index)", "rustc_codegen_utils 0.0.0", @@ -2661,7 +2972,7 @@ dependencies = [ "alloc 0.0.0", "build_helper 0.1.0", "cmake 0.1.33 (registry+https://github.com/rust-lang/crates.io-index)", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", ] @@ -2692,8 +3003,8 @@ dependencies = [ name = "rustdoc" version = "0.0.0" dependencies = [ - "minifier 0.0.20 (registry+https://github.com/rust-lang/crates.io-index)", - "parking_lot 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)", + "minifier 0.0.28 (registry+https://github.com/rust-lang/crates.io-index)", + "parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "pulldown-cmark 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", "tempfile 3.0.5 (registry+https://github.com/rust-lang/crates.io-index)", ] @@ -2714,7 +3025,7 @@ name = "rustfix" version = "0.4.4" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2723,24 +3034,24 @@ dependencies = [ [[package]] name = "rustfmt-nightly" -version = "1.0.1" +version = "1.0.3" dependencies = [ - "assert_cli 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", "atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)", - "bytecount 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", - "cargo_metadata 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "bytecount 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)", + "cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", "derive-new 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)", "diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", - "env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)", - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "dirs 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", + "env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)", - "itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)", + "itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)", "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", "regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-rustc_target 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-syntax 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", - "rustc-ap-syntax_pos 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-rustc_target 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-syntax 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rustc-ap-syntax_pos 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)", "rustc-workspace-hack 1.0.0", "serde 1.0.82 (registry+https://github.com/rust-lang/crates.io-index)", "serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)", @@ -2748,6 +3059,8 @@ dependencies = [ "term 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)", "toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)", "unicode-segmentation 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)", + "unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", + "unicode_categories 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] @@ -2788,6 +3101,11 @@ name = "scoped-tls" version = "0.1.2" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "scoped_threadpool" +version = "0.1.9" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "scopeguard" version = "0.3.3" @@ -2850,6 +3168,17 @@ dependencies = [ "smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "sha-1" +version = "0.7.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "block-buffer 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)", + "byte-tools 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", + "digest 0.7.6 (registry+https://github.com/rust-lang/crates.io-index)", + "fake-simd 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "shell-escape" version = "0.1.4" @@ -2860,11 +3189,25 @@ name = "shlex" version = "0.1.1" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "signal-hook" +version = "0.1.7" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "arc-swap 0.3.7 (registry+https://github.com/rust-lang/crates.io-index)", + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "siphasher" version = "0.2.2" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "slab" +version = "0.4.2" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "smallvec" version = "0.6.7" @@ -2896,9 +3239,9 @@ dependencies = [ "alloc 0.0.0", "backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)", "cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)", - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", - "dlmalloc 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", + "dlmalloc 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", "fortanix-sgx-abi 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)", "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", "panic_abort 0.0.0", @@ -3154,6 +3497,194 @@ dependencies = [ "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "tokio" +version = "0.1.14" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-current-thread 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-fs 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-tcp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-threadpool 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-timer 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-udp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-uds 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-codec" +version = "0.1.1" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-current-thread" +version = "0.1.4" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-executor" +version = "0.1.6" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-fs" +version = "0.1.5" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-threadpool 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-io" +version = "0.1.11" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-process" +version = "0.2.3" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "mio-named-pipes 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-signal 0.2.7 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-reactor" +version = "0.1.8" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)", + "parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)", + "slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-signal" +version = "0.2.7" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "mio-uds 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)", + "signal-hook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-tcp" +version = "0.1.3" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-threadpool" +version = "0.1.10" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-deque 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)", + "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "num_cpus 1.8.0 (registry+https://github.com/rust-lang/crates.io-index)", + "rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-timer" +version = "0.2.8" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-udp" +version = "0.1.3" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", +] + +[[package]] +name = "tokio-uds" +version = "0.2.5" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)", + "futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)", + "iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)", + "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", + "log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", + "mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)", + "mio-uds 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)", + "tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "toml" version = "0.4.10" @@ -3174,11 +3705,28 @@ dependencies = [ "toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "toml-query" +version = "0.7.0" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)", + "is-match 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)", + "regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)", + "toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "typenum" version = "1.10.0" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "ucd-trie" +version = "0.1.1" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "ucd-util" version = "0.1.3" @@ -3217,6 +3765,11 @@ name = "unicode-xid" version = "0.1.0" source = "registry+https://github.com/rust-lang/crates.io-index" +[[package]] +name = "unicode_categories" +version = "0.1.1" +source = "registry+https://github.com/rust-lang/crates.io-index" + [[package]] name = "unreachable" version = "1.0.0" @@ -3237,7 +3790,7 @@ dependencies = [ name = "unwind" version = "0.0.0" dependencies = [ - "compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)", + "compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", "core 0.0.0", "libc 0.2.46 (registry+https://github.com/rust-lang/crates.io-index)", ] @@ -3288,7 +3841,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)", "chrono 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)", - "failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)", + "failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)", ] [[package]] @@ -3365,6 +3918,15 @@ dependencies = [ "winapi-util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", ] +[[package]] +name = "ws2_32-sys" +version = "0.2.1" +source = "registry+https://github.com/rust-lang/crates.io-index" +dependencies = [ + "winapi 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)", + "winapi-build 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)", +] + [[package]] name = "xattr" version = "0.2.2" @@ -3391,8 +3953,10 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum aho-corasick 0.6.9 (registry+https://github.com/rust-lang/crates.io-index)" = "1e9a933f4e58658d7b12defcf96dc5c720f20832deebe3e0a19efd3b6aaeeb9e" "checksum ammonia 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "fd4c682378117e4186a492b2252b9537990e1617f44aed9788b9a1149de45477" "checksum ansi_term 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ee49baf6cb617b853aa8d93bf420db2383fab46d314482ca2803b40d5fde979b" +"checksum arc-swap 0.3.7 (registry+https://github.com/rust-lang/crates.io-index)" = "1025aeae2b664ca0ea726a89d574fe8f4e77dd712d443236ad1de00379450cf6" +"checksum argon2rs 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)" = "3f67b0b6a86dae6e67ff4ca2b6201396074996379fba2b92ff649126f37cb392" +"checksum arrayref 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)" = "0d382e583f07208808f6b1249e60848879ba3543f57c32277bf52d69c2f0f0ee" "checksum arrayvec 0.4.7 (registry+https://github.com/rust-lang/crates.io-index)" = "a1e964f9e24d588183fcb43503abda40d288c8657dfc27311516ce2f05675aef" -"checksum assert_cli 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "98589b0e465a6c510d95fceebd365bb79bedece7f6e18a480897f2015f85ec51" "checksum atty 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "9a7d5b8723950951411ee34d271d99dddcc2035a16ab25310ea2c8cfd4369652" "checksum backtrace 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)" = "18b65ea1161bfb2dd6da6fade5edd4dbd08fba85012123dd333d2fd1b90b2782" "checksum backtrace-sys 0.1.27 (registry+https://github.com/rust-lang/crates.io-index)" = "6ea90dd7b012b3d1a2cb6bec16670a0db2c95d4e931e84f4047e0460c1b34c8d" @@ -3400,12 +3964,17 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum bit-vec 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4440d5cb623bb7390ae27fec0bb6c61111969860f8e3ae198bfa0663645e67cf" "checksum bitflags 0.9.1 (registry+https://github.com/rust-lang/crates.io-index)" = "4efd02e230a02e18f92fc2735f44597385ed02ad8f831e7c1c1156ee5e1ab3a5" "checksum bitflags 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "228047a76f468627ca71776ecdebd732a3423081fcf5125585bcd7c49886ce12" +"checksum blake2-rfc 0.2.18 (registry+https://github.com/rust-lang/crates.io-index)" = "5d6d530bdd2d52966a6d03b7a964add7ae1a288d25214066fd4b600f0f796400" +"checksum block-buffer 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "a076c298b9ecdb530ed9d967e74a6027d6a7478924520acddcddc24c1c8ab3ab" "checksum bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "40e38929add23cdf8a366df9b0e088953150724bcbe5fc330b0d8eb3b328eec8" "checksum build_const 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "39092a32794787acd8525ee150305ff051b0aa6cc2abaf193924f5ab05425f39" -"checksum bytecount 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "b92204551573580e078dc80017f36a213eb77a0450e4ddd8cfa0f3f2d1f0178f" +"checksum byte-tools 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "560c32574a12a89ecd91f5e742165893f86e3ab98d21f8ea548658eb9eef5f40" +"checksum bytecount 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)" = "be0fdd54b507df8f22012890aadd099979befdba27713c767993f8380112ca7c" "checksum byteorder 1.2.7 (registry+https://github.com/rust-lang/crates.io-index)" = "94f88df23a25417badc922ab0f5716cc1330e87f71ddd9203b3a3ccd9cedf75d" +"checksum bytes 0.4.11 (registry+https://github.com/rust-lang/crates.io-index)" = "40ade3d27603c2cb345eb0912aec461a6dec7e06a4ae48589904e808335c7afa" "checksum bytesize 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "716960a18f978640f25101b5cbf1c6f6b0d3192fab36a2d98ca96f0ecbe41010" "checksum cargo_metadata 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "7d8dfe3adeb30f7938e6c1dd5327f29235d8ada3e898aeb08c343005ec2915a2" +"checksum cargo_metadata 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)" = "585784cac9b05c93a53b17a0b24a5cdd1dfdda5256f030e089b549d2390cc720" "checksum cc 1.0.28 (registry+https://github.com/rust-lang/crates.io-index)" = "bb4a8b715cb4597106ea87c7c84b2f1d452c7492033765df7f32651e66fcf749" "checksum cfg-if 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = "082bb9b28e00d3c9d39cc03e64ce4cea0f1bb9b3fde493f0cbc008472d22bdf4" "checksum chalk-engine 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "17ec698a6f053a23bfbe646d9f2fde4b02abc19125595270a99e6f44ae0bdd1a" @@ -3417,18 +3986,19 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum colored 1.6.0 (registry+https://github.com/rust-lang/crates.io-index)" = "b0aa3473e85a3161b59845d6096b289bb577874cafeaf75ea1b1beaa6572c7fc" "checksum commoncrypto 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d056a8586ba25a1e4d61cb090900e495952c7886786fc55f909ab2f819b69007" "checksum commoncrypto-sys 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1fed34f46747aa73dfaa578069fd8279d2818ade2b55f38f22a9401c7f4083e2" -"checksum compiler_builtins 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "bd14d75a16b6c836c62350e2e8c85495ed8e13df30a7298c574cb1ee4cdac7bc" +"checksum compiler_builtins 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "6711d51cb46744dd8305293cc3fbc392aaff7a8f5095a7c4fae1e5113ef07c96" "checksum compiletest_rs 0.3.18 (registry+https://github.com/rust-lang/crates.io-index)" = "0d76d4322a40f6b0db7259d4f2c8a65ed8b0d84fce0bbc61b98cf47f8ec6eec3" +"checksum constant_time_eq 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "8ff012e225ce166d4422e0e78419d901719760f62ae2b7969ca6b564d1b54a9e" "checksum core-foundation 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)" = "4e2640d6d0bf22e82bed1b73c6aef8d5dd31e5abe6666c57e6d45e2649f4f887" "checksum core-foundation-sys 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e7ca8a5221364ef15ce201e8ed2f609fc312682a8f4e0e3d4aa5879764e0fa3b" "checksum crc 1.8.1 (registry+https://github.com/rust-lang/crates.io-index)" = "d663548de7f5cca343f1e0a48d14dcfb0e9eb4e079ec58883b7251539fa10aeb" "checksum crc32fast 1.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e91d5240c6975ef33aeb5f148f35275c25eda8e8a5f95abe421978b05b8bf192" -"checksum crossbeam-channel 0.2.6 (registry+https://github.com/rust-lang/crates.io-index)" = "7b85741761b7f160bc5e7e0c14986ef685b7f8bf9b7ad081c60c604bb4649827" +"checksum crossbeam-channel 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "5b2a9ea8f77c7f9efd317a8a5645f515d903a2d86ee14d2337a5facd1bd52c12" "checksum crossbeam-deque 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f739f8c5363aca78cfb059edf753d8f0d36908c348f3d8d1503f03d8b75d9cf3" +"checksum crossbeam-deque 0.6.3 (registry+https://github.com/rust-lang/crates.io-index)" = "05e44b8cf3e1a625844d1750e1f7820da46044ff6d28f4d43e455ba3e5bb2c13" "checksum crossbeam-epoch 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)" = "927121f5407de9956180ff5e936fe3cf4324279280001cd56b669d28ee7e9150" -"checksum crossbeam-epoch 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9c90f1474584f38e270b5b613e898c8c328aa4f3dea85e0a27ac2e642f009416" +"checksum crossbeam-epoch 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f10a4f8f409aaac4b16a5474fb233624238fcdeefb9ba50d5ea059aab63ba31c" "checksum crossbeam-utils 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "2760899e32a1d58d5abb31129f8fae5de75220bc2176e77ff7c627ae45c918d9" -"checksum crossbeam-utils 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "677d453a17e8bd2b913fa38e8b9cf04bcdbb5be790aa294f2389661d72036015" "checksum crossbeam-utils 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e07fc155212827475223f0bcfae57e945e694fc90950ddf3f6695bbfd5555c72" "checksum crypto-hash 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)" = "09de9ee0fc255ace04c7fa0763c9395a945c37c8292bb554f8d48361d1dcf1b4" "checksum curl 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)" = "c7c9d851c825e0c033979d4516c9173bc19a78a96eb4d6ae51d4045440eafa16" @@ -3438,18 +4008,20 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum derive_more 0.13.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3f57d78cf3bd45270dad4e70c21ec77a960b36c7a841ff9db76aaa775a8fb871" "checksum diff 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "3c2b69f912779fbb121ceb775d74d51e915af17aaebc38d28a592843a2dd0a3a" "checksum difference 2.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "524cbf6897b527295dff137cec09ecf3a05f4fddffd7dfcd1585403449e74198" +"checksum digest 0.7.6 (registry+https://github.com/rust-lang/crates.io-index)" = "03b072242a8cbaf9c145665af9d250c59af3b958f83ed6824e13533cf76d5b90" "checksum directories 1.0.2 (registry+https://github.com/rust-lang/crates.io-index)" = "72d337a64190607d4fcca2cb78982c5dd57f4916e19696b48a575fa746b6cb0f" -"checksum dlmalloc 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "4c46c65de42b063004b31c67a98abe071089b289ff0919c660ed7ff4f59317f8" +"checksum dirs 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "88972de891f6118092b643d85a0b28e0678e0f948d7f879aa32f2d5aafe97d2a" +"checksum dlmalloc 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "d56ad71b31043818d0ee10a7fb9664882f8e45849c81647585e6a3124f185517" "checksum either 1.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3be565ca5c557d7f59e7cfcf1844f9e3033650c929c6566f511e8005f205c1d0" "checksum elasticlunr-rs 2.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "a99a310cd1f9770e7bf8e48810c7bcbb0e078c8fb23a8c7bcf0da4c2bf61a455" "checksum ena 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f56c93cc076508c549d9bb747f79aa9b4eb098be7b8cad8830c3137ef52d1e00" "checksum env_logger 0.5.13 (registry+https://github.com/rust-lang/crates.io-index)" = "15b0a4d2e39f8420210be8b27eeda28029729e2fd4291019455016c348240c38" "checksum env_logger 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)" = "afb070faf94c85d17d50ca44f6ad076bce18ae92f0037d350947240a36e9d42e" -"checksum environment 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "1f4b14e20978669064c33b4c1e0fb4083412e40fe56cbea2eae80fd7591503ee" "checksum error-chain 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ff511d5dc435d703f4971bc399647c9bc38e20cb41452e3b9feb4765419ed3f3" "checksum error-chain 0.12.0 (registry+https://github.com/rust-lang/crates.io-index)" = "07e791d3be96241c77c43846b665ef1384606da2cd2a48730abe606a12906e02" -"checksum failure 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "6dd377bcc1b1b7ce911967e3ec24fa19c3224394ec05b54aa7b083d498341ac7" -"checksum failure_derive 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "64c2d913fe8ed3b6c6518eedf4538255b989945c14c2a7d5cbff62a5e2120596" +"checksum failure 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "795bd83d3abeb9220f257e597aa0080a508b27533824adf336529648f6abf7e2" +"checksum failure_derive 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "ea1063915fd7ef4309e222a5a07cf9c319fb9c7836b1f89b85458672dbb127e1" +"checksum fake-simd 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e88a8acf291dafb59c2d96e8f59828f3838bb1a70398823ade51a84de6a6deed" "checksum filetime 0.2.4 (registry+https://github.com/rust-lang/crates.io-index)" = "a2df5c1a8c4be27e7707789dc42ae65976e60b394afd293d1419ab915833e646" "checksum fixedbitset 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)" = "86d4de0081402f5e88cdac65c8dcdcc73118c1a7a465e2a05f0da05843a8ea33" "checksum flate2 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)" = "2291c165c8e703ee54ef3055ad6188e3d51108e2ded18e9f2476e774fc5ad3d4" @@ -3465,30 +4037,34 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum futf 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "7c9c1ce3fa9336301af935ab852c437817d14cd33690446569392e65170aac3b" "checksum futures 0.1.21 (registry+https://github.com/rust-lang/crates.io-index)" = "1a70b146671de62ec8c8ed572219ca5d594d9b06c0b364d5e67b722fc559b48c" "checksum fwdansi 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "34dd4c507af68d37ffef962063dfa1944ce0dd4d5b82043dbab1dabe088610c3" +"checksum generic-array 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ef25c5683767570c2bbd7deba372926a55eaae9982d7726ee2a1050239d45b9d" "checksum getopts 0.2.17 (registry+https://github.com/rust-lang/crates.io-index)" = "b900c08c1939860ce8b54dc6a89e26e00c04c380fd0e09796799bd7f12861e05" "checksum git2 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)" = "c7339329bfa14a00223244311560d11f8f489b453fb90092af97f267a6090ab0" "checksum git2-curl 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d58551e903ed7e2d6fe3a2f3c7efa3a784ec29b19d0fbb035aaf0497c183fbdd" "checksum glob 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "8be18de09a56b60ed0edf84bc9df007e30040691af7acd1c41874faac5895bfb" "checksum globset 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)" = "4743617a7464bbda3c8aec8558ff2f9429047e025771037df561d383337ff865" "checksum handlebars 0.32.4 (registry+https://github.com/rust-lang/crates.io-index)" = "d89ec99d1594f285d4590fc32bac5f75cdab383f1123d504d27862c644a807dd" +"checksum handlebars 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d82e5750d8027a97b9640e3fefa66bbaf852a35228e1c90790efd13c4b09c166" "checksum heck 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ea04fa3ead4e05e51a7c806fc07271fdbde4e246a6c6d1efd52e72230b771b82" "checksum hex 0.3.2 (registry+https://github.com/rust-lang/crates.io-index)" = "805026a5d0141ffc30abb3be3173848ad46a1b1664fe632428479619a3644d77" "checksum home 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "80dff82fb58cfbbc617fb9a9184b010be0529201553cda50ad04372bc2333aff" "checksum html5ever 0.22.5 (registry+https://github.com/rust-lang/crates.io-index)" = "c213fa6a618dc1da552f54f85cba74b05d8e883c92ec4e89067736938084c26e" +"checksum http 0.1.16 (registry+https://github.com/rust-lang/crates.io-index)" = "fe67e3678f2827030e89cc4b9e7ecd16d52f132c0b940ab5005f88e821500f6a" "checksum humantime 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "3ca7e5f2e110db35f93b837c81797f3714500b81d517bf20c431b16d3ca4f114" "checksum idna 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "38f09e0f0b1fb55fdee1f17470ad800da77af5186a1a76c026b679358b7e844e" "checksum if_chain 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "4bac95d9aa0624e7b78187d6fb8ab012b41d9f6f54b1bcb61e61c4845f8357ec" -"checksum ignore 0.4.4 (registry+https://github.com/rust-lang/crates.io-index)" = "36ecfc5ad80f0b1226df948c562e2cddd446096be3f644c95106400eae8a5e01" -"checksum im-rc 12.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "d4591152fd573cf453a890b5f9fdc5c328a751a0785539316739d5f85e5c468c" +"checksum ignore 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "ad03ca67dc12474ecd91fdb94d758cbd20cb4e7a78ebe831df26a9b7511e1162" +"checksum im-rc 12.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9460397452f537fd51808056ff209f4c4c4c9d20d42ae952f517708726284972" +"checksum iovec 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "dbe6e417e7d0975db6512b90796e8ce223145ac4e33c377e4a42882a0e88bb08" "checksum is-match 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "7e5b386aef33a1c677be65237cb9d32c3f3ef56bd035949710c4bb13083eb053" "checksum itertools 0.7.8 (registry+https://github.com/rust-lang/crates.io-index)" = "f58856976b776fedd95533137617a02fb25719f40e7d9b01c7043cd65474f450" +"checksum itertools 0.8.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5b8467d9c1cebe26feb08c640139247fac215782d35371ade9a2136ed6085358" "checksum itoa 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)" = "1306f3464951f30e30d12373d31c79fbd52d236e5e896fd92f96ec7babbbe60b" "checksum jemalloc-sys 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)" = "bfc62c8e50e381768ce8ee0428ee53741929f7ebd73e4d83f669bcf7693e00ae" "checksum jobserver 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)" = "dd80e58f77e0cdea53ba96acc5e04479e5ffc5d869626a6beafe50fed867eace" "checksum json 0.11.13 (registry+https://github.com/rust-lang/crates.io-index)" = "9ad0485404155f45cce53a40d4b2d6ac356418300daed05273d9e26f91c390be" -"checksum jsonrpc-core 9.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4e9cbeda300803d381390fb65e8158437728c39e6987ed23bee82728b73511a7" +"checksum jsonrpc-core 10.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7a5152c3fda235dfd68341b3edf4121bc4428642c93acbd6de88c26bf95fc5d7" "checksum kernel32-sys 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "7507624b29483431c0ba2d82aece8ca6cdba9382bff4ddd0f7490560c056098d" -"checksum languageserver-types 0.51.1 (registry+https://github.com/rust-lang/crates.io-index)" = "68de833188ada4e175d04a028f03f244f6370eedbcc75a05604d47d925933f69" "checksum lazy_static 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "76f033c7ad61445c5b347c7382dd1237847eb1bce590fe50365dcb33d546be73" "checksum lazy_static 1.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "a374c89b9db55895453a74c1e38861d9deec0b01b405a82516e9d5de4820dea1" "checksum lazycell 1.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "b294d6fa9ee409a054354afc4352b0b9ef7ca222c69b8812cbea9e7d2bf3783f" @@ -3500,6 +4076,8 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum lock_api 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "949826a5ccf18c1b3a7c3d57692778d21768b79e46eb9dd07bfc4c2160036c54" "checksum log 0.4.6 (registry+https://github.com/rust-lang/crates.io-index)" = "c84ec4b527950aa83a329754b01dbe3f58361d1c5efacd1f6d68c494d08a17c6" "checksum log_settings 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "19af41f0565d7c19b2058153ad0b42d4d5ce89ec4dbf06ed6741114a8b63e7cd" +"checksum lsp-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "f3570f641b984e3e4613a1ca34db2ea72549bbc3c0316d33f5af91ab514dcbff" +"checksum lsp-types 0.55.4 (registry+https://github.com/rust-lang/crates.io-index)" = "6392b5843615b8a2adeebe87b83fdd29567c0870baba3407a67e6dbfee4712f8" "checksum lzma-sys 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)" = "d1eaa027402541975218bb0eec67d6b0412f6233af96e0d096d31dbdfd22e614" "checksum mac 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "c41e0c4fef86961ac6d6f8a82609f55f31b05e4fce149ac5710e439df7619ba4" "checksum macro-utils 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "f2c4deaccc2ead6a28c16c0ba82f07d52b6475397415ce40876e559b0b0ea510" @@ -3507,14 +4085,20 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum markup5ever 0.7.2 (registry+https://github.com/rust-lang/crates.io-index)" = "bfedc97d5a503e96816d10fedcd5b42f760b2e525ce2f7ec71f6a41780548475" "checksum matches 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)" = "7ffc5c5338469d4d3ea17d269fa8ea3512ad247247c30bd2df69e68309ed0a08" "checksum mdbook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)" = "90b5a8d7e341ceee5db3882a06078d42661ddcfa2b3687319cc5da76ec4e782f" +"checksum mdbook 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "0ba0d44cb4089c741b9a91f3e5218298a40699c2f3a070a85014eed290c60819" "checksum memchr 2.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "0a3eb002f0535929f1199681417029ebea04aadc0c7a4224b46be99c7f5d6a16" "checksum memmap 0.6.2 (registry+https://github.com/rust-lang/crates.io-index)" = "e2ffa2c986de11a9df78620c01eeaaf27d94d3ff02bf81bfcca953102dd0c6ff" "checksum memoffset 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "0f9dc261e2b62d7a622bf416ea3c5245cdd5d9a7fcc428c0d06804dfce1775b3" -"checksum minifier 0.0.20 (registry+https://github.com/rust-lang/crates.io-index)" = "96c269bb45c39b333392b2b18ad71760b34ac65666591386b0e959ed58b3f474" +"checksum minifier 0.0.28 (registry+https://github.com/rust-lang/crates.io-index)" = "3a2898502751dcc9d66b6fff57f3cf63cc91605e83e1a33515396f5027f8e4ca" "checksum miniz-sys 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "0300eafb20369952951699b68243ab4334f4b10a88f411c221d444b36c40e649" "checksum miniz_oxide 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5ad30a47319c16cde58d0314f5d98202a80c9083b5f61178457403dfb14e509c" "checksum miniz_oxide_c_api 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "28edaef377517fd9fe3e085c37d892ce7acd1fbeab9239c5a36eec352d8a8b7e" +"checksum mio 0.6.16 (registry+https://github.com/rust-lang/crates.io-index)" = "71646331f2619b1026cc302f87a2b8b648d5c6dd6937846a16cc8ce0f347f432" +"checksum mio-named-pipes 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = "f5e374eff525ce1c5b7687c4cef63943e7686524a387933ad27ca7ec43779cb3" +"checksum mio-uds 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)" = "966257a94e196b11bb43aca423754d87429960a768de9414f3691d6957abf125" +"checksum miow 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "8c1f2f3b1cf331de6896aabf6e9d55dca90356cc9960cca7eaaf408a355ae919" "checksum miow 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "396aa0f2003d7df8395cb93e09871561ccc3e785f0acb369170e8cc74ddf9226" +"checksum net2 0.2.33 (registry+https://github.com/rust-lang/crates.io-index)" = "42550d9fb7b6684a6d404d9fa7250c2eb2646df731d1c06afc06dcee9e1bcf88" "checksum new_debug_unreachable 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "0cdc457076c78ab54d5e0d6fa7c47981757f1e34dc39ff92787f217dede586c4" "checksum nodrop 0.1.12 (registry+https://github.com/rust-lang/crates.io-index)" = "9a2228dca57108069a5262f2ed8bd2e82496d2e074a06d1ccc7ce1687b6ae0a2" "checksum num-derive 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "8af1847c907c2f04d7bfd572fb25bbb4385c637fe5be163cf2f8c5d778fe1e7d" @@ -3532,10 +4116,16 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum owning_ref 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "cdf84f41639e037b484f93433aa3897863b561ed65c6e59c7073d7c561710f37" "checksum packed_simd 0.3.1 (registry+https://github.com/rust-lang/crates.io-index)" = "25d36de864f7218ec5633572a800109bbe5a1cc8d9d95a967f3daf93ea7e6ddc" "checksum parking_lot 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)" = "f0802bff09003b291ba756dc7e79313e51cc31667e94afbe847def490424cde5" +"checksum parking_lot 0.7.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ab41b4aed082705d1056416ae4468b6ea99d52599ecf3169b00088d43113e337" "checksum parking_lot_core 0.3.0 (registry+https://github.com/rust-lang/crates.io-index)" = "06a2b6aae052309c2fd2161ef58f5067bc17bb758377a0de9d4b279d603fdd8a" +"checksum parking_lot_core 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "94c8c7923936b28d546dfd14d4472eaf34c99b14e1c973a32b3e6d4eb04298c9" "checksum percent-encoding 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "31010dd2e1ac33d5b46a5b413495239882813e0369f8ed8a5e266f173602f831" "checksum pest 1.0.6 (registry+https://github.com/rust-lang/crates.io-index)" = "0fce5d8b5cc33983fc74f78ad552b5522ab41442c4ca91606e4236eb4b5ceefc" +"checksum pest 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "54f0c72a98d8ab3c99560bfd16df8059cc10e1f9a8e83e6e3b97718dd766e9c3" "checksum pest_derive 1.0.8 (registry+https://github.com/rust-lang/crates.io-index)" = "ca3294f437119209b084c797604295f40227cffa35c57220b1e99a6ff3bf8ee4" +"checksum pest_derive 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "833d1ae558dc601e9a60366421196a8d94bc0ac980476d0b67e1d0988d72b2d0" +"checksum pest_generator 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "63120576c4efd69615b5537d3d052257328a4ca82876771d6944424ccfd9f646" +"checksum pest_meta 2.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "f5a3492a4ed208ffc247adcdcc7ba2a95be3104f58877d0d02f0df39bf3efb5e" "checksum petgraph 0.4.13 (registry+https://github.com/rust-lang/crates.io-index)" = "9c3659d1ee90221741f65dd128d9998311b0e40c5d3c23a62445938214abce4f" "checksum phf 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)" = "7d37a244c75a9748e049225155f56dbcb98fe71b192fd25fd23cb914b5ad62f2" "checksum phf_codegen 0.7.22 (registry+https://github.com/rust-lang/crates.io-index)" = "4e4048fe7dd7a06b8127ecd6d3803149126e9b33c7558879846da3a63f734f2b" @@ -3556,7 +4146,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum quote 0.3.15 (registry+https://github.com/rust-lang/crates.io-index)" = "7a6e920b65c65f10b2ae65c831a81a073a89edd28c7cce89475bff467ab4167a" "checksum quote 0.5.2 (registry+https://github.com/rust-lang/crates.io-index)" = "9949cfe66888ffe1d53e6ec9d9f3b70714083854be20fd5e271b232a017401e8" "checksum quote 0.6.10 (registry+https://github.com/rust-lang/crates.io-index)" = "53fa22a1994bd0f9372d7a816207d8a2677ad0325b073f5c5332760f0fb62b5c" -"checksum racer 2.1.16 (registry+https://github.com/rust-lang/crates.io-index)" = "fbfcf2686b50f75a279cb42d9c6d253a1e68a475b415ea4baf7fb177ce94839a" +"checksum racer 2.1.19 (registry+https://github.com/rust-lang/crates.io-index)" = "d634483bed41bb116122b84ffe0ef8740345c2ceb2784ce86c33499700eb13a7" "checksum rand 0.4.3 (registry+https://github.com/rust-lang/crates.io-index)" = "8356f47b32624fef5b3301c1be97e5944ecdd595409cc5da11d05f211db6cfbd" "checksum rand 0.5.5 (registry+https://github.com/rust-lang/crates.io-index)" = "e464cd887e869cddcae8792a4ee31d23c7edd516700695608f5b98c67ee0131c" "checksum rand 0.6.1 (registry+https://github.com/rust-lang/crates.io-index)" = "ae9d223d52ae411a33cf7e54ec6034ec165df296ccd23533d671a28252b6f66a" @@ -3571,26 +4161,27 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum rayon-core 1.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "9d24ad214285a7729b174ed6d3bcfcb80177807f959d95fafd5bfc5c4f201ac8" "checksum redox_syscall 0.1.43 (registry+https://github.com/rust-lang/crates.io-index)" = "679da7508e9a6390aeaf7fbd02a800fdc64b73fe2204dd2c8ae66d22d9d5ad5d" "checksum redox_termios 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7e891cfe48e9100a70a3b6eb652fef28920c117d366339687bd5576160db0f76" +"checksum redox_users 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "214a97e49be64fd2c86f568dd0cb2c757d2cc53de95b273b6ad0a1c908482f26" "checksum regex 0.2.11 (registry+https://github.com/rust-lang/crates.io-index)" = "9329abc99e39129fcceabd24cf5d85b4671ef7c29c50e972bc5afe32438ec384" "checksum regex 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "37e7cbbd370869ce2e8dff25c7018702d10b21a20ef7135316f8daecd6c25b7f" "checksum regex-syntax 0.5.6 (registry+https://github.com/rust-lang/crates.io-index)" = "7d707a4fa2637f2dca2ef9fd02225ec7661fe01a53623c1e6515b6916511f7a7" "checksum regex-syntax 0.6.4 (registry+https://github.com/rust-lang/crates.io-index)" = "4e47a2ed29da7a9e1960e1639e7a982e6edc6d49be308a3b02daf511504a16d1" "checksum remove_dir_all 0.5.1 (registry+https://github.com/rust-lang/crates.io-index)" = "3488ba1b9a2084d38645c4c08276a1752dcbf2c7130d74f1569681ad5d2799c5" -"checksum rls-analysis 0.16.10 (registry+https://github.com/rust-lang/crates.io-index)" = "2de1187cceaf16d7642cc78835a2890b55b35ed9e8a8e3c6348a6297d8dd0fb1" +"checksum rls-analysis 0.16.12 (registry+https://github.com/rust-lang/crates.io-index)" = "ae18d8ad01dec3b2014f4d7ae3c607d7adbcff79e5d3b48ea42ea71c10d43a71" "checksum rls-blacklist 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "b8ce1fdac03e138c4617ff87b194e1ff57a39bb985a044ccbd8673d30701e411" -"checksum rls-data 0.18.1 (registry+https://github.com/rust-lang/crates.io-index)" = "3a209ce46bb52813cbe0786a7baadc0c1a3f5543ef93f179eda3b841ed72cf2e" +"checksum rls-data 0.18.2 (registry+https://github.com/rust-lang/crates.io-index)" = "5f80b84551b32e26affaf7f12374913b5061730c0dcd185d9e8fa5a15e36e65c" "checksum rls-rustc 0.5.0 (registry+https://github.com/rust-lang/crates.io-index)" = "2f9dba7390427aefa953608429701e3665192ca810ba8ae09301e001b7c7bed0" -"checksum rls-span 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5d7c7046dc6a92f2ae02ed302746db4382e75131b9ce20ce967259f6b5867a6a" +"checksum rls-span 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)" = "33d66f1d6c6ccd5c98029f162544131698f6ebb61d8c697681cac409dcd08805" "checksum rls-vfs 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "72d56425bd5aa86d9d4372b76f0381d3b4bda9c0220e71956c9fcc929f45c1f1" -"checksum rustc-ap-arena 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "cbfb540c1347a3993060896b18e0d64084203fa37aaffdc5e5c31264f275d476" -"checksum rustc-ap-graphviz 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "790ac657d5bf69be9ef56f6810e8a0238b07e8460a88526e11d41f8214eb6c4e" -"checksum rustc-ap-rustc_cratesio_shim 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "b721cf32b543f3ee90240d7b757ca4a45930fe9981458a50678b4ccd75c472e2" -"checksum rustc-ap-rustc_data_structures 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4fa11df199d45ce948b07792ca593f59c1d19d2cb05d35c6b0a02271e772a416" -"checksum rustc-ap-rustc_errors 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "b7ead3163ef995bbba520b88739e1d60f9ccf74fdacdda985067644c8134e827" -"checksum rustc-ap-rustc_target 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "688fef9cc27837755019b72b4f13e7a3d3e5012473475f377b75dbb1f07beb5f" -"checksum rustc-ap-serialize 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "5b2c0e8161e956647592a737074736e6ce05ea36b70c770ea8cca3eb9cb33737" -"checksum rustc-ap-syntax 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1adc189e5e4500a4167b9afa04e67067f40d0039e0e05870c977bebb561f065a" -"checksum rustc-ap-syntax_pos 306.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "4d42c430dbb0be4377bfe6aa5099074c63ac8796b24098562c2e2154aecc5652" +"checksum rustc-ap-arena 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "8be999235b541fc8eb54901b66e899a06076709ac5f53d6b2c5c59d29ad54780" +"checksum rustc-ap-graphviz 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "532b5df15ca1a19a42815e37e521a20a7632b86b36868d1447932f8476f8f789" +"checksum rustc-ap-rustc_cratesio_shim 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "c388afe1ef810013c878bdf9073ab1ae28dc49e9325863b351afb10acf4cc46e" +"checksum rustc-ap-rustc_data_structures 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "63a8f08b9fb6d607afb842ee7206273d09d69c9201bfc1c479a726093251a24e" +"checksum rustc-ap-rustc_errors 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "6dc0df7bf31588ea67e6386f6ad19f6b9a37ba7d5726ecad1cacce22e231bd98" +"checksum rustc-ap-rustc_target 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "8fb4623a6f6c65b928cbe8d9c52b38cf57ba1722677645dc53fb1bdadfd0e127" +"checksum rustc-ap-serialize 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "0c290b148c9e4e08bbcb8a313393e257c1103cedf6a038aefc9f957c8a77c755" +"checksum rustc-ap-syntax 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "526fdc5bdbaaeae3b2a9ba42e5f5f7f29cda6ce8971b607a2955b1cb4ca339b5" +"checksum rustc-ap-syntax_pos 373.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "8e4f88a1213562373cee9de5a1d77bbf16dd706030304af041c9733492fcc952" "checksum rustc-demangle 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)" = "82ae957aa1b3055d8e086486723c0ccd3d7b8fa190ae8fa2e35543b6171c810e" "checksum rustc-hash 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7540fc8b0c49f096ee9c961cda096467dce8084bec6bdca2fc83895fd9b28cb8" "checksum rustc-rayon 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "8c6d5a683c6ba4ed37959097e88d71c9e8e26659a3cb5be8b389078e7ad45306" @@ -3604,6 +4195,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum same-file 1.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "8f20c4be53a8a1ff4c1f1b2bd14570d2f634628709752f0702ecdd2b3f9a5267" "checksum schannel 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)" = "0e1a231dc10abf6749cfa5d7767f25888d484201accbd919b66ab5413c502d56" "checksum scoped-tls 0.1.2 (registry+https://github.com/rust-lang/crates.io-index)" = "332ffa32bf586782a3efaeb58f127980944bbc8c4d6913a86107ac2a5ab24b28" +"checksum scoped_threadpool 0.1.9 (registry+https://github.com/rust-lang/crates.io-index)" = "1d51f5df5af43ab3f1360b429fa5e0152ac5ce8c0bd6485cae490332e96846a8" "checksum scopeguard 0.3.3 (registry+https://github.com/rust-lang/crates.io-index)" = "94258f53601af11e6a49f722422f6e3425c52b06245a5cf9bc09908b174f5e27" "checksum semver 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)" = "1d7eb9ef2c18661902cc47e535f9bc51b78acd254da71d375c2f6720d9a40403" "checksum semver-parser 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "388a1df253eca08550bef6c72392cfe7c30914bf41df5269b68cbd6ff8f570a3" @@ -3611,9 +4203,12 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum serde_derive 1.0.81 (registry+https://github.com/rust-lang/crates.io-index)" = "477b13b646f5b5b56fc95bedfc3b550d12141ce84f466f6c44b9a17589923885" "checksum serde_ignored 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "190e9765dcedb56be63b6e0993a006c7e3b071a016a304736e4a315dc01fb142" "checksum serde_json 1.0.33 (registry+https://github.com/rust-lang/crates.io-index)" = "c37ccd6be3ed1fdf419ee848f7c758eb31b054d7cd3ae3600e3bae0adf569811" +"checksum sha-1 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "51b9d1f3b5de8a167ab06834a7c883bd197f2191e1dda1a22d9ccfeedbf9aded" "checksum shell-escape 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "170a13e64f2a51b77a45702ba77287f5c6829375b04a69cf2222acd17d0cfab9" "checksum shlex 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "7fdf1b9db47230893d76faad238fd6097fd6d6a9245cd7a4d90dbd639536bbd2" +"checksum signal-hook 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)" = "1f272d1b7586bec132ed427f532dd418d8beca1ca7f2caf7df35569b1415a4b4" "checksum siphasher 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "0df90a788073e8d0235a67e50441d47db7c8ad9debd91cbf43736a2a92d36537" +"checksum slab 0.4.2 (registry+https://github.com/rust-lang/crates.io-index)" = "c111b5bd5695e56cffe5129854aa230b39c93a305372fdbb2668ca2394eea9f8" "checksum smallvec 0.6.7 (registry+https://github.com/rust-lang/crates.io-index)" = "b73ea3738b47563803ef814925e69be00799a8c07420be8b996f8e98fb2336db" "checksum socket2 0.3.8 (registry+https://github.com/rust-lang/crates.io-index)" = "c4d11a52082057d87cb5caa31ad812f4504b97ab44732cd8359df2e9ff9f48e7" "checksum stable_deref_trait 1.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ffbc596e092fe5f598b12ef46cc03754085ac2f4d8c739ad61c4ae266cc3b3fa" @@ -3636,9 +4231,25 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum textwrap 0.10.0 (registry+https://github.com/rust-lang/crates.io-index)" = "307686869c93e71f94da64286f9a9524c0f308a9e1c87a583de8e9c9039ad3f6" "checksum thread_local 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)" = "c6b53e329000edc2b34dbe8545fd20e55a333362d0a321909685a19bd28c3f1b" "checksum time 0.1.40 (registry+https://github.com/rust-lang/crates.io-index)" = "d825be0eb33fda1a7e68012d51e9c7f451dc1a69391e7fdc197060bb8c56667b" +"checksum tokio 0.1.14 (registry+https://github.com/rust-lang/crates.io-index)" = "4790d0be6f4ba6ae4f48190efa2ed7780c9e3567796abdb285003cf39840d9c5" +"checksum tokio-codec 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "5c501eceaf96f0e1793cf26beb63da3d11c738c4a943fdf3746d81d64684c39f" +"checksum tokio-current-thread 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)" = "331c8acc267855ec06eb0c94618dcbbfea45bed2d20b77252940095273fb58f6" +"checksum tokio-executor 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = "30c6dbf2d1ad1de300b393910e8a3aa272b724a400b6531da03eed99e329fbf0" +"checksum tokio-fs 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "0e9cbbc8a3698b7ab652340f46633364f9eaa928ddaaee79d8b8f356dd79a09d" +"checksum tokio-io 0.1.11 (registry+https://github.com/rust-lang/crates.io-index)" = "b53aeb9d3f5ccf2ebb29e19788f96987fa1355f8fe45ea193928eaaaf3ae820f" +"checksum tokio-process 0.2.3 (registry+https://github.com/rust-lang/crates.io-index)" = "88e1281e412013f1ff5787def044a9577a0bed059f451e835f1643201f8b777d" +"checksum tokio-reactor 0.1.8 (registry+https://github.com/rust-lang/crates.io-index)" = "afbcdb0f0d2a1e4c440af82d7bbf0bf91a8a8c0575bcd20c05d15be7e9d3a02f" +"checksum tokio-signal 0.2.7 (registry+https://github.com/rust-lang/crates.io-index)" = "dd6dc5276ea05ce379a16de90083ec80836440d5ef8a6a39545a3207373b8296" +"checksum tokio-tcp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "1d14b10654be682ac43efee27401d792507e30fd8d26389e1da3b185de2e4119" +"checksum tokio-threadpool 0.1.10 (registry+https://github.com/rust-lang/crates.io-index)" = "17465013014410310f9f61fa10bf4724803c149ea1d51efece131c38efca93aa" +"checksum tokio-timer 0.2.8 (registry+https://github.com/rust-lang/crates.io-index)" = "4f37f0111d76cc5da132fe9bc0590b9b9cfd079bc7e75ac3846278430a299ff8" +"checksum tokio-udp 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "66268575b80f4a4a710ef83d087fdfeeabdce9b74c797535fbac18a2cb906e92" +"checksum tokio-uds 0.2.5 (registry+https://github.com/rust-lang/crates.io-index)" = "037ffc3ba0e12a0ab4aca92e5234e0dedeb48fddf6ccd260f1f150a36a9f2445" "checksum toml 0.4.10 (registry+https://github.com/rust-lang/crates.io-index)" = "758664fc71a3a69038656bee8b6be6477d2a6c315a6b81f7081f591bffa4111f" "checksum toml-query 0.6.0 (registry+https://github.com/rust-lang/crates.io-index)" = "6854664bfc6df0360c695480836ee90e2d0c965f06db291d10be9344792d43e8" +"checksum toml-query 0.7.0 (registry+https://github.com/rust-lang/crates.io-index)" = "ab234a943a2363ad774020e2f9474a38a85bc4396bace01a96380144aef17db3" "checksum typenum 1.10.0 (registry+https://github.com/rust-lang/crates.io-index)" = "612d636f949607bdf9b123b4a6f6d966dedf3ff669f7f045890d3a4a73948169" +"checksum ucd-trie 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "71a9c5b1fe77426cf144cc30e49e955270f5086e31a6441dfa8b32efc09b9d77" "checksum ucd-util 0.1.3 (registry+https://github.com/rust-lang/crates.io-index)" = "535c204ee4d8434478593480b8f86ab45ec9aae0e83c568ca81abf0fd0e88f86" "checksum unicode-bidi 0.3.4 (registry+https://github.com/rust-lang/crates.io-index)" = "49f2bd0c6468a8230e1db229cff8029217cf623c767ea5d60bfbd42729ea54d5" "checksum unicode-normalization 0.1.7 (registry+https://github.com/rust-lang/crates.io-index)" = "6a0180bc61fc5a987082bfa111f4cc95c4caff7f9799f3e46df09163a937aa25" @@ -3646,6 +4257,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum unicode-width 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "882386231c45df4700b275c7ff55b6f3698780a650026380e72dabe76fa46526" "checksum unicode-xid 0.0.4 (registry+https://github.com/rust-lang/crates.io-index)" = "8c1f860d7d29cf02cb2f3f359fd35991af3d30bac52c57d265a3c461074cb4dc" "checksum unicode-xid 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)" = "fc72304796d0818e357ead4e000d19c9c174ab23dc11093ac919054d20a6a7fc" +"checksum unicode_categories 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "39ec24b3121d976906ece63c9daad25b85969647682eee313cb5779fdd69e14e" "checksum unreachable 1.0.0 (registry+https://github.com/rust-lang/crates.io-index)" = "382810877fe448991dfc7f0dd6e3ae5d58088fd0ea5e35189655f84e6814fa56" "checksum url 1.7.2 (registry+https://github.com/rust-lang/crates.io-index)" = "dd4e7c0d531266369519a4aa4f399d748bd37043b00bde1e4ff1f60a120b355a" "checksum url_serde 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = "74e7d099f1ee52f823d4bdd60c93c3602043c728f5db3b97bdb548467f7bddea" @@ -3665,6 +4277,7 @@ source = "registry+https://github.com/rust-lang/crates.io-index" "checksum winapi-util 0.1.1 (registry+https://github.com/rust-lang/crates.io-index)" = "afc5508759c5bf4285e61feb862b6083c8480aec864fa17a81fdec6f69b461ab" "checksum winapi-x86_64-pc-windows-gnu 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)" = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f" "checksum wincolor 1.0.1 (registry+https://github.com/rust-lang/crates.io-index)" = "561ed901ae465d6185fa7864d63fbd5720d0ef718366c9a4dc83cf6170d7e9ba" +"checksum ws2_32-sys 0.2.1 (registry+https://github.com/rust-lang/crates.io-index)" = "d59cefebd0c892fa2dd6de581e937301d8552cb44489cdff035c6187cb63fa5e" "checksum xattr 0.2.2 (registry+https://github.com/rust-lang/crates.io-index)" = "244c3741f4240ef46274860397c7c74e50eb23624996930e484c16679633a54c" "checksum xz2 0.1.5 (registry+https://github.com/rust-lang/crates.io-index)" = "df8bf41d3030c3577c9458fd6640a05afbf43b150d0b531b16bd77d3f794f27a" "checksum yaml-rust 0.3.5 (registry+https://github.com/rust-lang/crates.io-index)" = "e66366e18dc58b46801afbf2ca7661a9f59cc8c5962c29892b6039b4f86fa992" diff --git a/README.md b/README.md index cb1f06257e..514e420ca4 100644 --- a/README.md +++ b/README.md @@ -13,9 +13,13 @@ Read ["Installation"] from [The Book]. ["Installation"]: https://doc.rust-lang.org/book/ch01-01-installation.html [The Book]: https://doc.rust-lang.org/book/index.html -## Building from Source +## Installing from Source [building-from-source]: #building-from-source +_Note: If you wish to contribute to the compiler, you should read +[this chapter](https://rust-lang.github.io/rustc-guide/how-to-build-and-run.html) +of the rustc-guide instead._ + ### Building on *nix 1. Make sure you have installed the dependencies: diff --git a/RELEASES.md b/RELEASES.md index 4cda02c5c2..48bd13105b 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -1,3 +1,168 @@ +Version 1.34.2 (2019-05-14) +=========================== + +* [Destabilize the `Error::type_id` function due to a security + vulnerability][60785] + +[60785]: https://github.com/rust-lang/rust/pull/60785 + +Version 1.34.1 (2019-04-25) +=========================== + +* [Fix false positives for the `redundant_closure` Clippy lint][clippy/3821] +* [Fix false positives for the `missing_const_for_fn` Clippy lint][clippy/3844] +* [Fix Clippy panic when checking some macros][clippy/3805] + +[clippy/3821]: https://github.com/rust-lang/rust-clippy/pull/3821 +[clippy/3844]: https://github.com/rust-lang/rust-clippy/pull/3844 +[clippy/3805]: https://github.com/rust-lang/rust-clippy/pull/3805 + +Version 1.34.0 (2019-04-11) +========================== + +Language +-------- +- [You can now use `#[deprecated = "reason"]`][58166] as a shorthand for + `#[deprecated(note = "reason")]`. This was previously allowed by mistake + but had no effect. +- [You can now accept token streams in `#[attr()]`,`#[attr[]]`, and + `#[attr{}]` procedural macros.][57367] +- [You can now write `extern crate self as foo;`][57407] to import your + crate's root into the extern prelude. + + +Compiler +-------- +- [You can now target `riscv64imac-unknown-none-elf` and + `riscv64gc-unknown-none-elf`.][58406] +- [You can now enable linker plugin LTO optimisations with + `-C linker-plugin-lto`.][58057] This allows rustc to compile your Rust code + into LLVM bitcode allowing LLVM to perform LTO optimisations across C/C++ FFI + boundaries. +- [You can now target `powerpc64-unknown-freebsd`.][57809] + + +Libraries +--------- +- [The trait bounds have been removed on some of `HashMap`'s and + `HashSet`'s basic methods.][58370] Most notably you no longer require + the `Hash` trait to create an iterator. +- [The `Ord` trait bounds have been removed on some of `BinaryHeap`'s basic + methods.][58421] Most notably you no longer require the `Ord` trait to create + an iterator. +- [The methods `overflowing_neg` and `wrapping_neg` are now `const` functions + for all numeric types.][58044] +- [Indexing a `str` is now generic over all types that + implement `SliceIndex`.][57604] +- [`str::trim`, `str::trim_matches`, `str::trim_{start, end}`, and + `str::trim_{start, end}_matches` are now `#[must_use]`][57106] and will + produce a warning if their returning type is unused. +- [The methods `checked_pow`, `saturating_pow`, `wrapping_pow`, and + `overflowing_pow` are now available for all numeric types.][57873] These are + equivalvent to methods such as `wrapping_add` for the `pow` operation. + + +Stabilized APIs +--------------- + +#### std & core +* [`Any::type_id`] +* [`Error::type_id`] +* [`atomic::AtomicI16`] +* [`atomic::AtomicI32`] +* [`atomic::AtomicI64`] +* [`atomic::AtomicI8`] +* [`atomic::AtomicU16`] +* [`atomic::AtomicU32`] +* [`atomic::AtomicU64`] +* [`atomic::AtomicU8`] +* [`convert::Infallible`] +* [`convert::TryFrom`] +* [`convert::TryInto`] +* [`iter::from_fn`] +* [`iter::successors`] +* [`num::NonZeroI128`] +* [`num::NonZeroI16`] +* [`num::NonZeroI32`] +* [`num::NonZeroI64`] +* [`num::NonZeroI8`] +* [`num::NonZeroIsize`] +* [`slice::sort_by_cached_key`] +* [`str::escape_debug`] +* [`str::escape_default`] +* [`str::escape_unicode`] +* [`str::split_ascii_whitespace`] + +#### std +* [`Instant::checked_add`] +* [`Instant::checked_sub`] +* [`SystemTime::checked_add`] +* [`SystemTime::checked_sub`] + +Cargo +----- +- [You can now use alternative registries to crates.io.][cargo/6654] + +Misc +---- +- [You can now use the `?` operator in your documentation tests without manually + adding `fn main() -> Result<(), _> {}`.][56470] + +Compatibility Notes +------------------- +- [`Command::before_exec` is now deprecated in favor of the + unsafe method `Command::pre_exec`.][58059] +- [Use of `ATOMIC_{BOOL, ISIZE, USIZE}_INIT` is now deprecated.][57425] As you + can now use `const` functions in `static` variables. + +[58370]: https://github.com/rust-lang/rust/pull/58370/ +[58406]: https://github.com/rust-lang/rust/pull/58406/ +[58421]: https://github.com/rust-lang/rust/pull/58421/ +[58166]: https://github.com/rust-lang/rust/pull/58166/ +[58044]: https://github.com/rust-lang/rust/pull/58044/ +[58057]: https://github.com/rust-lang/rust/pull/58057/ +[58059]: https://github.com/rust-lang/rust/pull/58059/ +[57809]: https://github.com/rust-lang/rust/pull/57809/ +[57873]: https://github.com/rust-lang/rust/pull/57873/ +[57604]: https://github.com/rust-lang/rust/pull/57604/ +[57367]: https://github.com/rust-lang/rust/pull/57367/ +[57407]: https://github.com/rust-lang/rust/pull/57407/ +[57425]: https://github.com/rust-lang/rust/pull/57425/ +[57106]: https://github.com/rust-lang/rust/pull/57106/ +[56470]: https://github.com/rust-lang/rust/pull/56470/ +[cargo/6654]: https://github.com/rust-lang/cargo/pull/6654/ +[`Any::type_id`]: https://doc.rust-lang.org/std/any/trait.Any.html#tymethod.type_id +[`Error::type_id`]: https://doc.rust-lang.org/std/error/trait.Error.html#method.type_id +[`atomic::AtomicI16`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicI16.html +[`atomic::AtomicI32`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicI32.html +[`atomic::AtomicI64`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicI64.html +[`atomic::AtomicI8`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicI8.html +[`atomic::AtomicU16`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU16.html +[`atomic::AtomicU32`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.html +[`atomic::AtomicU64`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU64.html +[`atomic::AtomicU8`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU8.html +[`convert::Infallible`]: https://doc.rust-lang.org/std/convert/enum.Infallible.html +[`convert::TryFrom`]: https://doc.rust-lang.org/std/convert/trait.TryFrom.html +[`convert::TryInto`]: https://doc.rust-lang.org/std/convert/trait.TryInto.html +[`iter::from_fn`]: https://doc.rust-lang.org/std/iter/fn.from_fn.html +[`iter::successors`]: https://doc.rust-lang.org/std/iter/fn.successors.html +[`num::NonZeroI128`]: https://doc.rust-lang.org/std/num/struct.NonZeroI128.html +[`num::NonZeroI16`]: https://doc.rust-lang.org/std/num/struct.NonZeroI16.html +[`num::NonZeroI32`]: https://doc.rust-lang.org/std/num/struct.NonZeroI32.html +[`num::NonZeroI64`]: https://doc.rust-lang.org/std/num/struct.NonZeroI64.html +[`num::NonZeroI8`]: https://doc.rust-lang.org/std/num/struct.NonZeroI8.html +[`num::NonZeroIsize`]: https://doc.rust-lang.org/std/num/struct.NonZeroIsize.html +[`slice::sort_by_cached_key`]: https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key +[`str::escape_debug`]: https://doc.rust-lang.org/std/primitive.str.html#method.escape_debug +[`str::escape_default`]: https://doc.rust-lang.org/std/primitive.str.html#method.escape_default +[`str::escape_unicode`]: https://doc.rust-lang.org/std/primitive.str.html#method.escape_unicode +[`str::split_ascii_whitespace`]: https://doc.rust-lang.org/std/primitive.str.html#method.split_ascii_whitespace +[`Instant::checked_add`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_add +[`Instant::checked_sub`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_sub +[`SystemTime::checked_add`]: https://doc.rust-lang.org/std/time/struct.SystemTime.html#method.checked_add +[`SystemTime::checked_sub`]: https://doc.rust-lang.org/std/time/struct.SystemTime.html#method.checked_sub + + Version 1.33.0 (2019-02-28) ========================== @@ -99,6 +264,8 @@ Stabilized APIs Cargo ----- +- [You can now publish crates that require a feature flag to compile with + `cargo publish --features` or `cargo publish --all-features`.][cargo/6453] - [Cargo should now rebuild a crate if a file was modified during the initial build.][cargo/6484] @@ -110,8 +277,11 @@ Compatibility Notes methods instead. - The `Error::cause` method has been deprecated in favor of `Error::source` which supports downcasting. +- [Libtest no longer creates a new thread for each test when + `--test-threads=1`. It also runs the tests in deterministic order][56243] [55982]: https://github.com/rust-lang/rust/pull/55982/ +[56243]: https://github.com/rust-lang/rust/pull/56243 [56303]: https://github.com/rust-lang/rust/pull/56303/ [56351]: https://github.com/rust-lang/rust/pull/56351/ [56362]: https://github.com/rust-lang/rust/pull/56362 @@ -132,6 +302,7 @@ Compatibility Notes [57535]: https://github.com/rust-lang/rust/pull/57535/ [57566]: https://github.com/rust-lang/rust/pull/57566/ [57615]: https://github.com/rust-lang/rust/pull/57615/ +[cargo/6453]: https://github.com/rust-lang/cargo/pull/6453/ [cargo/6484]: https://github.com/rust-lang/cargo/pull/6484/ [`unix::FileExt::read_exact_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.read_exact_at [`unix::FileExt::write_all_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.write_all_at diff --git a/config.toml.example b/config.toml.example index 23943d34b7..f45db37c33 100644 --- a/config.toml.example +++ b/config.toml.example @@ -90,12 +90,21 @@ # with clang-cl, so this is special in that it only compiles LLVM with clang-cl #clang-cl = '/path/to/clang-cl.exe' +# Pass extra compiler and linker flags to the LLVM CMake build. +#cflags = "-fextra-flag" +#cxxflags = "-fextra-flag" +#ldflags = "-Wl,extra-flag" + # Use libc++ when building LLVM instead of libstdc++. This is the default on # platforms already use libc++ as the default C++ library, but this option # allows you to use libc++ even on platforms when it's not. You need to ensure # that your host compiler ships with libc++. #use-libcxx = true +# The value specified here will be passed as `-DLLVM_USE_LINKER` to CMake. +#use-linker = "lld" + + # ============================================================================= # General build configuration options # ============================================================================= @@ -312,8 +321,8 @@ # Whether to always use incremental compilation when building rustc #incremental = false -# Build rustc with experimental parallelization -#experimental-parallel-queries = false +# Build a multi-threaded rustc +#parallel-compiler = false # The default linker that will be hard-coded into the generated compiler for # targets that don't specify linker explicitly in their target specifications. diff --git a/git-commit-hash b/git-commit-hash index 531b43928d..963e8d3cdc 100644 --- a/git-commit-hash +++ b/git-commit-hash @@ -1 +1 @@ -2aa4c46cfdd726e97360c2734835aa3515e8c858 \ No newline at end of file +6c2484dc3c532c052f159264e970278d8b77cdc9 \ No newline at end of file diff --git a/src/README.md b/src/README.md index 6522891586..14e773286b 100644 --- a/src/README.md +++ b/src/README.md @@ -8,7 +8,6 @@ For more information on how various parts of the compiler work, see the [rustc g There is also useful content in the following READMEs, which are gradually being moved over to the guide: - https://github.com/rust-lang/rust/tree/master/src/librustc/ty/query - https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph -- https://github.com/rust-lang/rust/blob/master/src/librustc/infer/region_constraints - https://github.com/rust-lang/rust/tree/master/src/librustc/infer/higher_ranked - https://github.com/rust-lang/rust/tree/master/src/librustc/infer/lexical_region_resolve diff --git a/src/bootstrap/bin/main.rs b/src/bootstrap/bin/main.rs index 8ddce5c247..0732cb83f3 100644 --- a/src/bootstrap/bin/main.rs +++ b/src/bootstrap/bin/main.rs @@ -7,8 +7,6 @@ #![deny(warnings)] -extern crate bootstrap; - use std::env; use bootstrap::{Config, Build}; diff --git a/src/bootstrap/bin/rustc.rs b/src/bootstrap/bin/rustc.rs index a0c75cd9e9..b6afe317a0 100644 --- a/src/bootstrap/bin/rustc.rs +++ b/src/bootstrap/bin/rustc.rs @@ -17,8 +17,6 @@ #![deny(warnings)] -extern crate bootstrap; - use std::env; use std::ffi::OsString; use std::io; @@ -284,8 +282,8 @@ fn main() { } } - if env::var_os("RUSTC_PARALLEL_QUERIES").is_some() { - cmd.arg("--cfg").arg("parallel_queries"); + if env::var_os("RUSTC_PARALLEL_COMPILER").is_some() { + cmd.arg("--cfg").arg("parallel_compiler"); } if env::var_os("RUSTC_DENY_WARNINGS").is_some() && env::var_os("RUSTC_EXTERNAL_TOOL").is_none() diff --git a/src/bootstrap/bin/rustdoc.rs b/src/bootstrap/bin/rustdoc.rs index dec74e60c7..52b5971f0a 100644 --- a/src/bootstrap/bin/rustdoc.rs +++ b/src/bootstrap/bin/rustdoc.rs @@ -4,8 +4,6 @@ #![deny(warnings)] -extern crate bootstrap; - use std::env; use std::process::Command; use std::path::PathBuf; @@ -16,6 +14,7 @@ fn main() { let libdir = env::var_os("RUSTDOC_LIBDIR").expect("RUSTDOC_LIBDIR was not set"); let stage = env::var("RUSTC_STAGE").expect("RUSTC_STAGE was not set"); let sysroot = env::var_os("RUSTC_SYSROOT").expect("RUSTC_SYSROOT was not set"); + let mut has_unstable = false; use std::str::FromStr; @@ -54,9 +53,33 @@ fn main() { // it up so we can make rustdoc print this into the docs if let Some(version) = env::var_os("RUSTDOC_CRATE_VERSION") { // This "unstable-options" can be removed when `--crate-version` is stabilized - cmd.arg("-Z") - .arg("unstable-options") - .arg("--crate-version").arg(version); + if !has_unstable { + cmd.arg("-Z") + .arg("unstable-options"); + } + cmd.arg("--crate-version").arg(version); + has_unstable = true; + } + + // Needed to be able to run all rustdoc tests. + if let Some(_) = env::var_os("RUSTDOC_GENERATE_REDIRECT_PAGES") { + // This "unstable-options" can be removed when `--generate-redirect-pages` is stabilized + if !has_unstable { + cmd.arg("-Z") + .arg("unstable-options"); + } + cmd.arg("--generate-redirect-pages"); + has_unstable = true; + } + + // Needed to be able to run all rustdoc tests. + if let Some(ref x) = env::var_os("RUSTDOC_RESOURCE_SUFFIX") { + // This "unstable-options" can be removed when `--resource-suffix` is stabilized + if !has_unstable { + cmd.arg("-Z") + .arg("unstable-options"); + } + cmd.arg("--resource-suffix").arg(x); } if verbose > 1 { diff --git a/src/bootstrap/bin/sccache-plus-cl.rs b/src/bootstrap/bin/sccache-plus-cl.rs index f9e14d1ff6..f40eec83dd 100644 --- a/src/bootstrap/bin/sccache-plus-cl.rs +++ b/src/bootstrap/bin/sccache-plus-cl.rs @@ -1,5 +1,3 @@ -extern crate cc; - use std::env; use std::process::{self, Command}; diff --git a/src/bootstrap/bootstrap.py b/src/bootstrap/bootstrap.py index f3dbae6909..119b38bcc9 100644 --- a/src/bootstrap/bootstrap.py +++ b/src/bootstrap/bootstrap.py @@ -230,6 +230,9 @@ def default_build_triple(): err = "unknown OS type: {}".format(ostype) sys.exit(err) + if cputype == 'powerpc' and ostype == 'unknown-freebsd': + cputype = subprocess.check_output( + ['uname', '-p']).strip().decode(default_encoding) cputype_mapper = { 'BePC': 'i686', 'aarch64': 'aarch64', @@ -698,21 +701,13 @@ class RustBuild(object): filtered_submodules = [] submodules_names = [] for module in submodules: - if module.endswith("llvm"): - if self.get_toml('llvm-config'): + if module.endswith("llvm-project"): + if self.get_toml('llvm-config') and self.get_toml('lld') != 'true': continue if module.endswith("llvm-emscripten"): backends = self.get_toml('codegen-backends') if backends is None or not 'emscripten' in backends: continue - if module.endswith("lld"): - config = self.get_toml('lld') - if config is None or config == 'false': - continue - if module.endswith("lldb") or module.endswith("clang"): - config = self.get_toml('lldb') - if config is None or config == 'false': - continue check = self.check_submodule(module, slow_submodules) filtered_submodules.append((module, check)) submodules_names.append(module) diff --git a/src/bootstrap/builder.rs b/src/bootstrap/builder.rs index 9c58f5b179..a471af2576 100644 --- a/src/bootstrap/builder.rs +++ b/src/bootstrap/builder.rs @@ -21,7 +21,7 @@ use crate::install; use crate::native; use crate::test; use crate::tool; -use crate::util::{add_lib_path, exe, libdir}; +use crate::util::{self, add_lib_path, exe, libdir}; use crate::{Build, DocTests, Mode, GitRepo}; pub use crate::Compiler; @@ -60,23 +60,23 @@ pub trait Step: 'static + Clone + Debug + PartialEq + Eq + Hash { /// Run this rule for all hosts without cross compiling. const ONLY_HOSTS: bool = false; - /// Primary function to execute this rule. Can call `builder.ensure(...)` + /// Primary function to execute this rule. Can call `builder.ensure()` /// with other steps to run those. - fn run(self, builder: &Builder) -> Self::Output; + fn run(self, builder: &Builder<'_>) -> Self::Output; /// When bootstrap is passed a set of paths, this controls whether this rule /// will execute. However, it does not get called in a "default" context - /// when we are not passed any paths; in that case, make_run is called + /// when we are not passed any paths; in that case, `make_run` is called /// directly. - fn should_run(run: ShouldRun) -> ShouldRun; + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_>; - /// Build up a "root" rule, either as a default rule or from a path passed + /// Builds up a "root" rule, either as a default rule or from a path passed /// to us. /// /// When path is `None`, we are executing in a context where no paths were /// passed. When `./x.py build` is run, for example, this rule could get /// called if it is in the correct list below with a path of `None`. - fn make_run(_run: RunConfig) { + fn make_run(_run: RunConfig<'_>) { // It is reasonable to not have an implementation of make_run for rules // who do not want to get called from the root context. This means that // they are likely dependencies (e.g., sysroot creation) or similar, and @@ -95,8 +95,8 @@ pub struct RunConfig<'a> { struct StepDescription { default: bool, only_hosts: bool, - should_run: fn(ShouldRun) -> ShouldRun, - make_run: fn(RunConfig), + should_run: fn(ShouldRun<'_>) -> ShouldRun<'_>, + make_run: fn(RunConfig<'_>), name: &'static str, } @@ -124,7 +124,7 @@ impl PathSet { } } - fn path(&self, builder: &Builder) -> PathBuf { + fn path(&self, builder: &Builder<'_>) -> PathBuf { match self { PathSet::Set(set) => set .iter() @@ -147,7 +147,7 @@ impl StepDescription { } } - fn maybe_run(&self, builder: &Builder, pathset: &PathSet) { + fn maybe_run(&self, builder: &Builder<'_>, pathset: &PathSet) { if builder.config.exclude.iter().any(|e| pathset.has(e)) { eprintln!("Skipping {:?} because it is excluded", pathset); return; @@ -183,7 +183,7 @@ impl StepDescription { } } - fn run(v: &[StepDescription], builder: &Builder, paths: &[PathBuf]) { + fn run(v: &[StepDescription], builder: &Builder<'_>, paths: &[PathBuf]) { let should_runs = v .iter() .map(|desc| (desc.should_run)(ShouldRun::new(builder))) @@ -245,7 +245,7 @@ pub struct ShouldRun<'a> { } impl<'a> ShouldRun<'a> { - fn new(builder: &'a Builder) -> ShouldRun<'a> { + fn new(builder: &'a Builder<'_>) -> ShouldRun<'a> { ShouldRun { builder, paths: BTreeSet::new(), @@ -326,7 +326,7 @@ pub enum Kind { impl<'a> Builder<'a> { fn get_step_descriptions(kind: Kind) -> Vec { macro_rules! describe { - ($($rule:ty),+ $(,)*) => {{ + ($($rule:ty),+ $(,)?) => {{ vec![$(StepDescription::from::<$rule>()),+] }}; } @@ -378,14 +378,11 @@ impl<'a> Builder<'a> { test::Debuginfo, test::UiFullDeps, test::RunPassFullDeps, - test::RunFailFullDeps, test::Rustdoc, test::Pretty, test::RunPassPretty, test::RunFailPretty, test::RunPassValgrindPretty, - test::RunPassFullDepsPretty, - test::RunFailFullDepsPretty, test::Crate, test::CrateLibrustc, test::CrateRustdoc, @@ -403,11 +400,13 @@ impl<'a> Builder<'a> { test::TheBook, test::UnstableBook, test::RustcBook, + test::EmbeddedBook, test::Rustfmt, test::Miri, test::Clippy, test::CompiletestTest, - test::RustdocJS, + test::RustdocJSStd, + test::RustdocJSNotStd, test::RustdocTheme, // Run bootstrap close to the end as it's unlikely to fail test::Bootstrap, @@ -433,6 +432,7 @@ impl<'a> Builder<'a> { doc::RustByExample, doc::RustcBook, doc::CargoBook, + doc::EmbeddedBook, doc::EditionGuide, ), Kind::Dist => describe!( @@ -512,7 +512,7 @@ impl<'a> Builder<'a> { Some(help) } - pub fn new(build: &Build) -> Builder { + pub fn new(build: &Build) -> Builder<'_> { let (kind, paths) = match build.config.cmd { Subcommand::Build { ref paths } => (Kind::Build, &paths[..]), Subcommand::Check { ref paths } => (Kind::Check, &paths[..]), @@ -592,11 +592,11 @@ impl<'a> Builder<'a> { impl Step for Libdir { type Output = Interned; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } - fn run(self, builder: &Builder) -> Interned { + fn run(self, builder: &Builder<'_>) -> Interned { let compiler = self.compiler; let config = &builder.build.config; let lib = if compiler.stage >= 1 && config.libdir_relative().is_some() { @@ -649,7 +649,7 @@ impl<'a> Builder<'a> { add_lib_path(vec![self.rustc_libdir(compiler)], cmd); } - /// Get a path to the compiler specified. + /// Gets a path to the compiler specified. pub fn rustc(&self, compiler: Compiler) -> PathBuf { if compiler.is_snapshot(self) { self.initial_rustc.clone() @@ -660,6 +660,15 @@ impl<'a> Builder<'a> { } } + /// Gets the paths to all of the compiler's codegen backends. + fn codegen_backends(&self, compiler: Compiler) -> impl Iterator { + fs::read_dir(self.sysroot_codegen_backends(compiler)) + .into_iter() + .flatten() + .filter_map(Result::ok) + .map(|entry| entry.path()) + } + pub fn rustdoc(&self, host: Interned) -> PathBuf { self.ensure(tool::Rustdoc { host }) } @@ -669,10 +678,9 @@ impl<'a> Builder<'a> { let compiler = self.compiler(self.top_stage, host); cmd.env("RUSTC_STAGE", compiler.stage.to_string()) .env("RUSTC_SYSROOT", self.sysroot(compiler)) - .env( - "RUSTDOC_LIBDIR", - self.sysroot_libdir(compiler, self.config.build), - ) + // Note that this is *not* the sysroot_libdir because rustdoc must be linked + // equivalently to rustc. + .env("RUSTDOC_LIBDIR", self.rustc_libdir(compiler)) .env("CFG_RELEASE_CHANNEL", &self.config.channel) .env("RUSTDOC_REAL", self.rustdoc(host)) .env("RUSTDOC_CRATE_VERSION", self.rust_version()) @@ -750,6 +758,9 @@ impl<'a> Builder<'a> { match mode { Mode::Std => { self.clear_if_dirty(&my_out, &self.rustc(compiler)); + for backend in self.codegen_backends(compiler) { + self.clear_if_dirty(&my_out, &backend); + } }, Mode::Test => { self.clear_if_dirty(&my_out, &libstd_stamp); @@ -782,6 +793,13 @@ impl<'a> Builder<'a> { .env("CARGO_TARGET_DIR", out_dir) .arg(cmd); + // See comment in librustc_llvm/build.rs for why this is necessary, largely llvm-config + // needs to not accidentally link to libLLVM in stage0/lib. + cargo.env("REAL_LIBRARY_PATH_VAR", &util::dylib_path_var()); + if let Some(e) = env::var_os(util::dylib_path_var()) { + cargo.env("REAL_LIBRARY_PATH", e); + } + if cmd != "install" { cargo.arg("--target") .arg(target); @@ -856,7 +874,7 @@ impl<'a> Builder<'a> { } else { &maybe_sysroot }; - let libdir = sysroot.join(libdir(&compiler.host)); + let libdir = self.rustc_libdir(compiler); // Customize the compiler we're running. Specify the compiler to cargo // as our shim and then pass it some various options used to configure @@ -898,7 +916,7 @@ impl<'a> Builder<'a> { cargo.env("RUSTC_ERROR_FORMAT", error_format); } if cmd != "build" && cmd != "check" && cmd != "rustc" && want_rustdoc { - cargo.env("RUSTDOC_LIBDIR", self.sysroot_libdir(compiler, self.config.build)); + cargo.env("RUSTDOC_LIBDIR", self.rustc_libdir(compiler)); } if mode.is_tool() { @@ -982,6 +1000,9 @@ impl<'a> Builder<'a> { if self.config.incremental { cargo.env("CARGO_INCREMENTAL", "1"); + } else { + // Don't rely on any default setting for incr. comp. in Cargo + cargo.env("CARGO_INCREMENTAL", "0"); } if let Some(ref on_fail) = self.config.on_fail { @@ -998,8 +1019,7 @@ impl<'a> Builder<'a> { cargo.env("RUSTC_VERBOSE", self.verbosity.to_string()); - // in std, we want to avoid denying warnings for stage 0 as that makes cfg's painful. - if self.config.deny_warnings && !(mode == Mode::Std && stage == 0) { + if self.config.deny_warnings { cargo.env("RUSTC_DENY_WARNINGS", "1"); } @@ -1032,29 +1052,24 @@ impl<'a> Builder<'a> { } }; let cc = ccacheify(&self.cc(target)); - cargo.env(format!("CC_{}", target), &cc).env("CC", &cc); + cargo.env(format!("CC_{}", target), &cc); let cflags = self.cflags(target, GitRepo::Rustc).join(" "); cargo - .env(format!("CFLAGS_{}", target), cflags.clone()) - .env("CFLAGS", cflags.clone()); + .env(format!("CFLAGS_{}", target), cflags.clone()); if let Some(ar) = self.ar(target) { let ranlib = format!("{} s", ar.display()); cargo .env(format!("AR_{}", target), ar) - .env("AR", ar) - .env(format!("RANLIB_{}", target), ranlib.clone()) - .env("RANLIB", ranlib); + .env(format!("RANLIB_{}", target), ranlib); } if let Ok(cxx) = self.cxx(target) { let cxx = ccacheify(&cxx); cargo .env(format!("CXX_{}", target), &cxx) - .env("CXX", &cxx) - .env(format!("CXXFLAGS_{}", target), cflags.clone()) - .env("CXXFLAGS", cflags); + .env(format!("CXXFLAGS_{}", target), cflags); } } diff --git a/src/bootstrap/cache.rs b/src/bootstrap/cache.rs index ea8bc657a5..239959682c 100644 --- a/src/bootstrap/cache.rs +++ b/src/bootstrap/cache.rs @@ -68,20 +68,20 @@ unsafe impl Send for Interned {} unsafe impl Sync for Interned {} impl fmt::Display for Interned { - fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { + fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let s: &str = &*self; f.write_str(s) } } impl fmt::Debug for Interned { - fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { + fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let s: &str = &*self; f.write_fmt(format_args!("{:?}", s)) } } impl fmt::Debug for Interned { - fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { + fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let s: &Path = &*self; f.write_fmt(format_args!("{:?}", s)) } @@ -227,10 +227,10 @@ lazy_static! { pub static ref INTERNER: Interner = Interner::default(); } -/// This is essentially a HashMap which allows storing any type in its input and +/// This is essentially a `HashMap` which allows storing any type in its input and /// any type in its output. It is a write-once cache; values are never evicted, /// which means that references to the value can safely be returned from the -/// get() method. +/// `get()` method. #[derive(Debug)] pub struct Cache( RefCell return, }; match output[i + 3..].chars().next().unwrap() { - '0' ... '6' => {} + '0' ..= '6' => {} _ => return, } let alternative = format!("e{}", gnu_compiler); diff --git a/src/bootstrap/channel.rs b/src/bootstrap/channel.rs index 63741b9b67..89cc99728c 100644 --- a/src/bootstrap/channel.rs +++ b/src/bootstrap/channel.rs @@ -14,7 +14,7 @@ use crate::Build; use crate::config::Config; // The version number -pub const CFG_RELEASE_NUM: &str = "1.33.0"; +pub const CFG_RELEASE_NUM: &str = "1.34.2"; pub struct GitInfo { inner: Option, diff --git a/src/bootstrap/check.rs b/src/bootstrap/check.rs index cc539d4c89..2037037208 100644 --- a/src/bootstrap/check.rs +++ b/src/bootstrap/check.rs @@ -17,17 +17,17 @@ impl Step for Std { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("std") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Std { target: run.target, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; let compiler = builder.compiler(0, builder.config.build); @@ -56,22 +56,22 @@ impl Step for Rustc { const ONLY_HOSTS: bool = true; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("rustc-main") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustc { target: run.target, }); } - /// Build the compiler. + /// Builds the compiler. /// /// This will build the compiler for a particular stage of the build using /// the `compiler` targeting the `target` architecture. The artifacts /// created will also be linked into the sysroot directory. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = builder.compiler(0, builder.config.build); let target = self.target; @@ -103,11 +103,11 @@ impl Step for CodegenBackend { const ONLY_HOSTS: bool = true; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("rustc_codegen_llvm") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let backend = run.builder.config.rust_codegen_backends.get(0); let backend = backend.cloned().unwrap_or_else(|| { INTERNER.intern_str("llvm") @@ -118,7 +118,7 @@ impl Step for CodegenBackend { }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = builder.compiler(0, builder.config.build); let target = self.target; let backend = self.backend; @@ -148,17 +148,17 @@ impl Step for Test { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("test") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Test { target: run.target, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = builder.compiler(0, builder.config.build); let target = self.target; @@ -189,17 +189,17 @@ impl Step for Rustdoc { const ONLY_HOSTS: bool = true; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rustdoc") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustdoc { target: run.target, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = builder.compiler(0, builder.config.build); let target = self.target; @@ -229,25 +229,37 @@ impl Step for Rustdoc { /// Cargo's output path for the standard library in a given stage, compiled /// by a particular compiler for the specified target. -pub fn libstd_stamp(builder: &Builder, compiler: Compiler, target: Interned) -> PathBuf { +pub fn libstd_stamp( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, +) -> PathBuf { builder.cargo_out(compiler, Mode::Std, target).join(".libstd-check.stamp") } /// Cargo's output path for libtest in a given stage, compiled by a particular /// compiler for the specified target. -pub fn libtest_stamp(builder: &Builder, compiler: Compiler, target: Interned) -> PathBuf { +pub fn libtest_stamp( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, +) -> PathBuf { builder.cargo_out(compiler, Mode::Test, target).join(".libtest-check.stamp") } /// Cargo's output path for librustc in a given stage, compiled by a particular /// compiler for the specified target. -pub fn librustc_stamp(builder: &Builder, compiler: Compiler, target: Interned) -> PathBuf { +pub fn librustc_stamp( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, +) -> PathBuf { builder.cargo_out(compiler, Mode::Rustc, target).join(".librustc-check.stamp") } /// Cargo's output path for librustc_codegen_llvm in a given stage, compiled by a particular /// compiler for the specified target and backend. -fn codegen_backend_stamp(builder: &Builder, +fn codegen_backend_stamp(builder: &Builder<'_>, compiler: Compiler, target: Interned, backend: Interned) -> PathBuf { @@ -257,7 +269,11 @@ fn codegen_backend_stamp(builder: &Builder, /// Cargo's output path for rustdoc in a given stage, compiled by a particular /// compiler for the specified target. -pub fn rustdoc_stamp(builder: &Builder, compiler: Compiler, target: Interned) -> PathBuf { +pub fn rustdoc_stamp( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, +) -> PathBuf { builder.cargo_out(compiler, Mode::ToolRustc, target) .join(".rustdoc-check.stamp") } diff --git a/src/bootstrap/clean.rs b/src/bootstrap/clean.rs index 74a2b7e4aa..b52e1a7b0e 100644 --- a/src/bootstrap/clean.rs +++ b/src/bootstrap/clean.rs @@ -3,7 +3,7 @@ //! Responsible for cleaning out a build directory of all old and stale //! artifacts to prepare for a fresh build. Currently doesn't remove the //! `build/cache` directory (download cache) or the `build/$target/llvm` -//! directory unless the --all flag is present. +//! directory unless the `--all` flag is present. use std::fs; use std::io::{self, ErrorKind}; diff --git a/src/bootstrap/compile.rs b/src/bootstrap/compile.rs index b581271663..249a183189 100644 --- a/src/bootstrap/compile.rs +++ b/src/bootstrap/compile.rs @@ -37,23 +37,23 @@ impl Step for Std { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("std") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Std { compiler: run.builder.compiler(run.builder.top_stage, run.host), target: run.target, }); } - /// Build the standard library. + /// Builds the standard library. /// /// This will build the standard library for a particular stage of the build /// using the `compiler` targeting the `target` architecture. The artifacts /// created will also be linked into the sysroot directory. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; let compiler = self.compiler; @@ -111,7 +111,7 @@ impl Step for Std { } /// Copies third pary objects needed by various targets. -fn copy_third_party_objects(builder: &Builder, compiler: &Compiler, target: Interned) { +fn copy_third_party_objects(builder: &Builder<'_>, compiler: &Compiler, target: Interned) { let libdir = builder.sysroot_libdir(*compiler, target); // Copies the crt(1,i,n).o startup objects @@ -145,7 +145,7 @@ fn copy_third_party_objects(builder: &Builder, compiler: &Compiler, target: Inte /// Configure cargo to compile the standard library, adding appropriate env vars /// and such. -pub fn std_cargo(builder: &Builder, +pub fn std_cargo(builder: &Builder<'_>, compiler: &Compiler, target: Interned, cargo: &mut Command) { @@ -201,7 +201,7 @@ struct StdLink { impl Step for StdLink { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } @@ -213,7 +213,7 @@ impl Step for StdLink { /// Note that this assumes that `compiler` has already generated the libstd /// libraries for `target`, and this method will find them in the relevant /// output directory. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target_compiler = self.target_compiler; let target = self.target; @@ -237,7 +237,12 @@ impl Step for StdLink { } } -fn copy_apple_sanitizer_dylibs(builder: &Builder, native_dir: &Path, platform: &str, into: &Path) { +fn copy_apple_sanitizer_dylibs( + builder: &Builder<'_>, + native_dir: &Path, + platform: &str, + into: &Path, +) { for &sanitizer in &["asan", "tsan"] { let filename = format!("lib__rustc__clang_rt.{}_{}_dynamic.dylib", sanitizer, platform); let mut src_path = native_dir.join(sanitizer); @@ -258,24 +263,24 @@ pub struct StartupObjects { impl Step for StartupObjects { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/rtstartup") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(StartupObjects { compiler: run.builder.compiler(run.builder.top_stage, run.host), target: run.target, }); } - /// Build and prepare startup objects like rsbegin.o and rsend.o + /// Builds and prepare startup objects like rsbegin.o and rsend.o /// /// These are primarily used on Windows right now for linking executables/dlls. /// They don't require any library support as they're just plain old object /// files, so we just use the nightly snapshot compiler to always build them (as /// no other compilers are guaranteed to be available). - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let for_compiler = self.compiler; let target = self.target; if !target.contains("pc-windows-gnu") { @@ -323,23 +328,23 @@ impl Step for Test { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("test") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Test { compiler: run.builder.compiler(run.builder.top_stage, run.host), target: run.target, }); } - /// Build libtest. + /// Builds libtest. /// /// This will build libtest and supporting libraries for a particular stage of /// the build using the `compiler` targeting the `target` architecture. The /// artifacts created will also be linked into the sysroot directory. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; let compiler = self.compiler; @@ -390,7 +395,7 @@ impl Step for Test { } /// Same as `std_cargo`, but for libtest -pub fn test_cargo(builder: &Builder, +pub fn test_cargo(builder: &Builder<'_>, _compiler: &Compiler, _target: Interned, cargo: &mut Command) { @@ -411,12 +416,12 @@ pub struct TestLink { impl Step for TestLink { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } /// Same as `std_link`, only for libtest - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target_compiler = self.target_compiler; let target = self.target; @@ -444,23 +449,23 @@ impl Step for Rustc { const ONLY_HOSTS: bool = true; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("rustc-main") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustc { compiler: run.builder.compiler(run.builder.top_stage, run.host), target: run.target, }); } - /// Build the compiler. + /// Builds the compiler. /// /// This will build the compiler for a particular stage of the build using /// the `compiler` targeting the `target` architecture. The artifacts /// created will also be linked into the sysroot directory. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target = self.target; @@ -516,14 +521,14 @@ impl Step for Rustc { } } -pub fn rustc_cargo(builder: &Builder, cargo: &mut Command) { +pub fn rustc_cargo(builder: &Builder<'_>, cargo: &mut Command) { cargo.arg("--features").arg(builder.rustc_features()) .arg("--manifest-path") .arg(builder.src.join("src/rustc/Cargo.toml")); rustc_cargo_env(builder, cargo); } -pub fn rustc_cargo_env(builder: &Builder, cargo: &mut Command) { +pub fn rustc_cargo_env(builder: &Builder<'_>, cargo: &mut Command) { // Set some configuration variables picked up by build scripts and // the compiler alike cargo.env("CFG_RELEASE", builder.rust_release()) @@ -554,8 +559,8 @@ pub fn rustc_cargo_env(builder: &Builder, cargo: &mut Command) { if let Some(ref s) = builder.config.rustc_default_linker { cargo.env("CFG_DEFAULT_LINKER", s); } - if builder.config.rustc_parallel_queries { - cargo.env("RUSTC_PARALLEL_QUERIES", "1"); + if builder.config.rustc_parallel { + cargo.env("RUSTC_PARALLEL_COMPILER", "1"); } if builder.config.rust_verify_llvm_ir { cargo.env("RUSTC_VERIFY_LLVM_IR", "1"); @@ -572,12 +577,12 @@ struct RustcLink { impl Step for RustcLink { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } /// Same as `std_link`, only for librustc - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target_compiler = self.target_compiler; let target = self.target; @@ -605,11 +610,11 @@ impl Step for CodegenBackend { const ONLY_HOSTS: bool = true; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.all_krates("rustc_codegen_llvm") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let backend = run.builder.config.rust_codegen_backends.get(0); let backend = backend.cloned().unwrap_or_else(|| { INTERNER.intern_str("llvm") @@ -621,7 +626,7 @@ impl Step for CodegenBackend { }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target = self.target; let backend = self.backend; @@ -684,7 +689,7 @@ impl Step for CodegenBackend { } } -pub fn build_codegen_backend(builder: &Builder, +pub fn build_codegen_backend(builder: &Builder<'_>, cargo: &mut Command, compiler: &Compiler, target: Interned, @@ -712,6 +717,7 @@ pub fn build_codegen_backend(builder: &Builder, if builder.is_rust_llvm(target) && backend != "emscripten" { cargo.env("LLVM_RUSTLLVM", "1"); } + cargo.env("LLVM_CONFIG", &llvm_config); if backend != "emscripten" { let target_config = builder.config.target_config.get(&target); @@ -752,7 +758,7 @@ pub fn build_codegen_backend(builder: &Builder, /// This will take the codegen artifacts produced by `compiler` and link them /// into an appropriate location for `target_compiler` to be a functional /// compiler. -fn copy_codegen_backends_to_sysroot(builder: &Builder, +fn copy_codegen_backends_to_sysroot(builder: &Builder<'_>, compiler: Compiler, target_compiler: Compiler) { let target = target_compiler.host; @@ -790,7 +796,7 @@ fn copy_codegen_backends_to_sysroot(builder: &Builder, } } -fn copy_lld_to_sysroot(builder: &Builder, +fn copy_lld_to_sysroot(builder: &Builder<'_>, target_compiler: Compiler, lld_install_root: &Path) { let target = target_compiler.host; @@ -810,25 +816,37 @@ fn copy_lld_to_sysroot(builder: &Builder, /// Cargo's output path for the standard library in a given stage, compiled /// by a particular compiler for the specified target. -pub fn libstd_stamp(builder: &Builder, compiler: Compiler, target: Interned) -> PathBuf { +pub fn libstd_stamp( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, +) -> PathBuf { builder.cargo_out(compiler, Mode::Std, target).join(".libstd.stamp") } /// Cargo's output path for libtest in a given stage, compiled by a particular /// compiler for the specified target. -pub fn libtest_stamp(builder: &Builder, compiler: Compiler, target: Interned) -> PathBuf { +pub fn libtest_stamp( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, +) -> PathBuf { builder.cargo_out(compiler, Mode::Test, target).join(".libtest.stamp") } /// Cargo's output path for librustc in a given stage, compiled by a particular /// compiler for the specified target. -pub fn librustc_stamp(builder: &Builder, compiler: Compiler, target: Interned) -> PathBuf { +pub fn librustc_stamp( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, +) -> PathBuf { builder.cargo_out(compiler, Mode::Rustc, target).join(".librustc.stamp") } /// Cargo's output path for librustc_codegen_llvm in a given stage, compiled by a particular /// compiler for the specified target and backend. -fn codegen_backend_stamp(builder: &Builder, +fn codegen_backend_stamp(builder: &Builder<'_>, compiler: Compiler, target: Interned, backend: Interned) -> PathBuf { @@ -836,10 +854,12 @@ fn codegen_backend_stamp(builder: &Builder, .join(format!(".librustc_codegen_llvm-{}.stamp", backend)) } -pub fn compiler_file(builder: &Builder, - compiler: &Path, - target: Interned, - file: &str) -> PathBuf { +pub fn compiler_file( + builder: &Builder<'_>, + compiler: &Path, + target: Interned, + file: &str, +) -> PathBuf { let mut cmd = Command::new(compiler); cmd.args(builder.cflags(target, GitRepo::Rustc)); cmd.arg(format!("-print-file-name={}", file)); @@ -855,7 +875,7 @@ pub struct Sysroot { impl Step for Sysroot { type Output = Interned; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } @@ -865,7 +885,7 @@ impl Step for Sysroot { /// That is, the sysroot for the stage0 compiler is not what the compiler /// thinks it is by default, but it's the same as the default for stages /// 1-3. - fn run(self, builder: &Builder) -> Interned { + fn run(self, builder: &Builder<'_>) -> Interned { let compiler = self.compiler; let sysroot = if compiler.stage == 0 { builder.out.join(&compiler.host).join("stage0-sysroot") @@ -890,7 +910,7 @@ pub struct Assemble { impl Step for Assemble { type Output = Compiler; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } @@ -899,7 +919,7 @@ impl Step for Assemble { /// This will assemble a compiler in `build/$host/stage$stage`. The compiler /// must have been previously produced by the `stage - 1` builder.build /// compiler. - fn run(self, builder: &Builder) -> Compiler { + fn run(self, builder: &Builder<'_>) -> Compiler { let target_compiler = self.target_compiler; if target_compiler.stage == 0 { @@ -995,14 +1015,14 @@ impl Step for Assemble { /// /// For a particular stage this will link the file listed in `stamp` into the /// `sysroot_dst` provided. -pub fn add_to_sysroot(builder: &Builder, sysroot_dst: &Path, stamp: &Path) { +pub fn add_to_sysroot(builder: &Builder<'_>, sysroot_dst: &Path, stamp: &Path) { t!(fs::create_dir_all(&sysroot_dst)); for path in builder.read_stamp_file(stamp) { builder.copy(&path, &sysroot_dst.join(path.file_name().unwrap())); } } -pub fn run_cargo(builder: &Builder, +pub fn run_cargo(builder: &Builder<'_>, cargo: &mut Command, stamp: &Path, is_check: bool) @@ -1149,9 +1169,9 @@ pub fn run_cargo(builder: &Builder, } pub fn stream_cargo( - builder: &Builder, + builder: &Builder<'_>, cargo: &mut Command, - cb: &mut dyn FnMut(CargoMessage), + cb: &mut dyn FnMut(CargoMessage<'_>), ) -> bool { if builder.config.dry_run { return true; @@ -1173,7 +1193,7 @@ pub fn stream_cargo( let stdout = BufReader::new(child.stdout.take().unwrap()); for line in stdout.lines() { let line = t!(line); - match serde_json::from_str::(&line) { + match serde_json::from_str::>(&line) { Ok(msg) => cb(msg), // If this was informational, just print it out and continue Err(_) => println!("{}", line) diff --git a/src/bootstrap/config.rs b/src/bootstrap/config.rs index 9421817ae6..7d3e584f1a 100644 --- a/src/bootstrap/config.rs +++ b/src/bootstrap/config.rs @@ -77,11 +77,15 @@ pub struct Config { pub llvm_experimental_targets: String, pub llvm_link_jobs: Option, pub llvm_version_suffix: Option, + pub llvm_use_linker: Option, pub lld_enabled: bool, pub lldb_enabled: bool, pub llvm_tools_enabled: bool, + pub llvm_cflags: Option, + pub llvm_cxxflags: Option, + pub llvm_ldflags: Option, pub llvm_use_libcxx: bool, // rust codegen options @@ -94,7 +98,7 @@ pub struct Config { pub rust_debuginfo_only_std: bool, pub rust_debuginfo_tools: bool, pub rust_rpath: bool, - pub rustc_parallel_queries: bool, + pub rustc_parallel: bool, pub rustc_default_linker: Option, pub rust_optimize_tests: bool, pub rust_debuginfo_tests: bool, @@ -254,7 +258,11 @@ struct Llvm { link_shared: Option, version_suffix: Option, clang_cl: Option, + cflags: Option, + cxxflags: Option, + ldflags: Option, use_libcxx: Option, + use_linker: Option, } #[derive(Deserialize, Default, Clone)] @@ -292,7 +300,7 @@ struct Rust { debuginfo_lines: Option, debuginfo_only_std: Option, debuginfo_tools: Option, - experimental_parallel_queries: Option, + parallel_compiler: Option, backtrace: Option, default_linker: Option, channel: Option, @@ -516,7 +524,12 @@ impl Config { config.llvm_link_jobs = llvm.link_jobs; config.llvm_version_suffix = llvm.version_suffix.clone(); config.llvm_clang_cl = llvm.clang_cl.clone(); + + config.llvm_cflags = llvm.cflags.clone(); + config.llvm_cxxflags = llvm.cxxflags.clone(); + config.llvm_ldflags = llvm.ldflags.clone(); set(&mut config.llvm_use_libcxx, llvm.use_libcxx); + config.llvm_use_linker = llvm.use_linker.clone(); } if let Some(ref rust) = toml.rust { @@ -547,7 +560,7 @@ impl Config { set(&mut config.lld_enabled, rust.lld); set(&mut config.lldb_enabled, rust.lldb); set(&mut config.llvm_tools_enabled, rust.llvm_tools); - config.rustc_parallel_queries = rust.experimental_parallel_queries.unwrap_or(false); + config.rustc_parallel = rust.parallel_compiler.unwrap_or(false); config.rustc_default_linker = rust.default_linker.clone(); config.musl_root = rust.musl_root.clone().map(PathBuf::from); config.save_toolstates = rust.save_toolstates.clone().map(PathBuf::from); diff --git a/src/bootstrap/configure.py b/src/bootstrap/configure.py index b0c3c97024..b2d8f2d8eb 100755 --- a/src/bootstrap/configure.py +++ b/src/bootstrap/configure.py @@ -35,7 +35,7 @@ o("debug", "rust.debug", "enables debugging environment; does not affect optimiz o("docs", "build.docs", "build standard library documentation") o("compiler-docs", "build.compiler-docs", "build compiler documentation") o("optimize-tests", "rust.optimize-tests", "build tests with optimizations") -o("experimental-parallel-queries", "rust.experimental-parallel-queries", "build rustc with experimental parallelization") +o("parallel-compiler", "rust.parallel-compiler", "build a multi-threaded rustc") o("test-miri", "rust.test-miri", "run miri's test suite") o("debuginfo-tests", "rust.debuginfo-tests", "build tests with debugger metadata") o("verbose-tests", "rust.verbose-tests", "enable verbose output when running tests") @@ -64,6 +64,10 @@ o("lldb", "rust.lldb", "build lldb") o("missing-tools", "dist.missing-tools", "allow failures when building tools") o("use-libcxx", "llvm.use_libcxx", "build LLVM with libc++") +o("cflags", "llvm.cflags", "build LLVM with these extra compiler flags") +o("cxxflags", "llvm.cxxflags", "build LLVM with these extra compiler flags") +o("ldflags", "llvm.ldflags", "build LLVM with these extra linker flags") + # Optimization and debugging options. These may be overridden by the release # channel, etc. o("optimize", "rust.optimize", "build optimized rust code") diff --git a/src/bootstrap/dist.rs b/src/bootstrap/dist.rs index 0c6e213110..2dae3f9135 100644 --- a/src/bootstrap/dist.rs +++ b/src/bootstrap/dist.rs @@ -23,9 +23,9 @@ use crate::builder::{Builder, RunConfig, ShouldRun, Step}; use crate::compile; use crate::tool::{self, Tool}; use crate::cache::{INTERNER, Interned}; -use time; +use time::{self, Timespec}; -pub fn pkgname(builder: &Builder, component: &str) -> String { +pub fn pkgname(builder: &Builder<'_>, component: &str) -> String { if component == "cargo" { format!("{}-{}", component, builder.cargo_package_vers()) } else if component == "rls" { @@ -46,15 +46,15 @@ pub fn pkgname(builder: &Builder, component: &str) -> String { } } -fn distdir(builder: &Builder) -> PathBuf { +fn distdir(builder: &Builder<'_>) -> PathBuf { builder.out.join("dist") } -pub fn tmpdir(builder: &Builder) -> PathBuf { +pub fn tmpdir(builder: &Builder<'_>) -> PathBuf { builder.out.join("tmp/dist") } -fn rust_installer(builder: &Builder) -> Command { +fn rust_installer(builder: &Builder<'_>) -> Command { builder.tool_cmd(Tool::RustInstaller) } @@ -76,11 +76,11 @@ impl Step for Docs { type Output = PathBuf; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/doc") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Docs { stage: run.builder.top_stage, host: run.target, @@ -88,7 +88,7 @@ impl Step for Docs { } /// Builds the `rust-docs` installer component. - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let host = self.host; let name = pkgname(builder, "rust-docs"); @@ -138,11 +138,11 @@ impl Step for RustcDocs { type Output = PathBuf; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/librustc") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(RustcDocs { stage: run.builder.top_stage, host: run.target, @@ -150,7 +150,7 @@ impl Step for RustcDocs { } /// Builds the `rustc-docs` installer component. - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let host = self.host; let name = pkgname(builder, "rustc-docs"); @@ -210,7 +210,7 @@ fn find_files(files: &[&str], path: &[PathBuf]) -> Vec { } fn make_win_dist( - rust_root: &Path, plat_root: &Path, target_triple: Interned, builder: &Builder + rust_root: &Path, plat_root: &Path, target_triple: Interned, builder: &Builder<'_> ) { //Ask gcc where it keeps its stuff let mut cmd = Command::new(builder.cc(target_triple)); @@ -334,19 +334,19 @@ impl Step for Mingw { type Output = Option; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Mingw { host: run.target }); } - /// Build the `rust-mingw` installer component. + /// Builds the `rust-mingw` installer component. /// /// This contains all the bits and pieces to run the MinGW Windows targets /// without any extra installed software (e.g., we bundle gcc, libraries, etc). - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let host = self.host; if !host.contains("pc-windows-gnu") { @@ -392,18 +392,18 @@ impl Step for Rustc { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/librustc") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustc { compiler: run.builder.compiler(run.builder.top_stage, run.target), }); } /// Creates the `rustc` installer component. - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let compiler = self.compiler; let host = self.compiler.host; @@ -470,7 +470,7 @@ impl Step for Rustc { return distdir(builder).join(format!("{}-{}.tar.gz", name, host)); - fn prepare_image(builder: &Builder, compiler: Compiler, image: &Path) { + fn prepare_image(builder: &Builder<'_>, compiler: Compiler, image: &Path) { let host = compiler.host; let src = builder.sysroot(compiler); let libdir = libdir(&host); @@ -528,7 +528,19 @@ impl Step for Rustc { t!(fs::create_dir_all(image.join("share/man/man1"))); let man_src = builder.src.join("src/doc/man"); let man_dst = image.join("share/man/man1"); - let month_year = t!(time::strftime("%B %Y", &time::now())); + + // Reproducible builds: If SOURCE_DATE_EPOCH is set, use that as the time. + let time = env::var("SOURCE_DATE_EPOCH") + .map(|timestamp| { + let epoch = timestamp.parse().map_err(|err| { + format!("could not parse SOURCE_DATE_EPOCH: {}", err) + }).unwrap(); + + time::at(Timespec::new(epoch, 0)) + }) + .unwrap_or_else(|_| time::now()); + + let month_year = t!(time::strftime("%B %Y", &time)); // don't use our `bootstrap::util::{copy, cp_r}`, because those try // to hardlink, and we don't want to edit the source templates for file_entry in builder.read_dir(&man_src) { @@ -568,11 +580,11 @@ pub struct DebuggerScripts { impl Step for DebuggerScripts { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/lldb_batchmode.py") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(DebuggerScripts { sysroot: run.builder.sysroot(run.builder.compiler(run.builder.top_stage, run.host)), host: run.target, @@ -580,7 +592,7 @@ impl Step for DebuggerScripts { } /// Copies debugger scripts for `target` into the `sysroot` specified. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let host = self.host; let sysroot = self.sysroot; let dst = sysroot.join("lib/rustlib/etc"); @@ -602,6 +614,8 @@ impl Step for DebuggerScripts { // gdb debugger scripts builder.install(&builder.src.join("src/etc/rust-gdb"), &sysroot.join("bin"), 0o755); + builder.install(&builder.src.join("src/etc/rust-gdbgui"), &sysroot.join("bin"), + 0o755); cp_debugger_script("gdb_load_rust_pretty_printers.py"); cp_debugger_script("gdb_rust_pretty_printing.py"); @@ -625,18 +639,18 @@ impl Step for Std { type Output = PathBuf; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/libstd") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Std { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, }); } - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let compiler = self.compiler; let target = self.target; @@ -714,12 +728,12 @@ impl Step for Analysis { type Output = PathBuf; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("analysis").default_condition(builder.config.extended) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Analysis { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, @@ -727,7 +741,7 @@ impl Step for Analysis { } /// Creates a tarball of save-analysis metadata, if available. - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let compiler = self.compiler; let target = self.target; assert!(builder.config.extended); @@ -777,7 +791,7 @@ impl Step for Analysis { } } -fn copy_src_dirs(builder: &Builder, src_dirs: &[&str], exclude_dirs: &[&str], dst_dir: &Path) { +fn copy_src_dirs(builder: &Builder<'_>, src_dirs: &[&str], exclude_dirs: &[&str], dst_dir: &Path) { fn filter_fn(exclude_dirs: &[&str], dir: &str, path: &Path) -> bool { let spath = match path.to_str() { Some(path) => path, @@ -786,7 +800,24 @@ fn copy_src_dirs(builder: &Builder, src_dirs: &[&str], exclude_dirs: &[&str], ds if spath.ends_with("~") || spath.ends_with(".pyc") { return false } - if (spath.contains("llvm/test") || spath.contains("llvm\\test")) && + + const LLVM_PROJECTS: &[&str] = &[ + "llvm-project/clang", "llvm-project\\clang", + "llvm-project/lld", "llvm-project\\lld", + "llvm-project/lldb", "llvm-project\\lldb", + "llvm-project/llvm", "llvm-project\\llvm", + ]; + if spath.contains("llvm-project") && !spath.ends_with("llvm-project") + && !LLVM_PROJECTS.iter().any(|path| spath.contains(path)) + { + return false; + } + + const LLVM_TEST: &[&str] = &[ + "llvm-project/llvm/test", "llvm-project\\llvm\\test", + "llvm-emscripten/test", "llvm-emscripten\\test", + ]; + if LLVM_TEST.iter().any(|path| spath.contains(path)) && (spath.ends_with(".ll") || spath.ends_with(".td") || spath.ends_with(".s")) { @@ -830,16 +861,16 @@ impl Step for Src { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Src); } /// Creates the `rust-src` installer component - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { builder.info("Dist src"); let name = pkgname(builder, "rust-src"); @@ -910,17 +941,17 @@ impl Step for PlainSourceTarball { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src").default_condition(builder.config.rust_dist_src) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(PlainSourceTarball); } /// Creates the plain source tarball - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { builder.info("Create plain source tarball"); // Make sure that the root folder of tarball has the correct name @@ -1038,18 +1069,18 @@ impl Step for Cargo { type Output = PathBuf; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("cargo") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Cargo { stage: run.builder.top_stage, target: run.target, }); } - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let stage = self.stage; let target = self.target; @@ -1124,18 +1155,18 @@ impl Step for Rls { type Output = Option; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("rls") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rls { stage: run.builder.top_stage, target: run.target, }); } - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let stage = self.stage; let target = self.target; assert!(builder.config.extended); @@ -1203,18 +1234,18 @@ impl Step for Clippy { type Output = Option; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("clippy") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Clippy { stage: run.builder.top_stage, target: run.target, }); } - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let stage = self.stage; let target = self.target; assert!(builder.config.extended); @@ -1287,18 +1318,18 @@ impl Step for Miri { type Output = Option; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("miri") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Miri { stage: run.builder.top_stage, target: run.target, }); } - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let stage = self.stage; let target = self.target; assert!(builder.config.extended); @@ -1371,18 +1402,18 @@ impl Step for Rustfmt { type Output = Option; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("rustfmt") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustfmt { stage: run.builder.top_stage, target: run.target, }); } - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let stage = self.stage; let target = self.target; @@ -1454,12 +1485,12 @@ impl Step for Extended { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("extended").default_condition(builder.config.extended) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Extended { stage: run.builder.top_stage, host: run.builder.config.build, @@ -1468,7 +1499,7 @@ impl Step for Extended { } /// Creates a combined installer for the specified target in the provided stage. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; @@ -1918,7 +1949,7 @@ impl Step for Extended { } } -fn add_env(builder: &Builder, cmd: &mut Command, target: Interned) { +fn add_env(builder: &Builder<'_>, cmd: &mut Command, target: Interned) { let mut parts = channel::CFG_RELEASE_NUM.split('.'); cmd.env("CFG_RELEASE_INFO", builder.rust_version()) .env("CFG_RELEASE_NUM", channel::CFG_RELEASE_NUM) @@ -1954,15 +1985,15 @@ impl Step for HashSign { type Output = (); const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("hash-and-sign") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(HashSign); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let mut cmd = builder.tool_cmd(Tool::BuildManifest); if builder.config.dry_run { return; @@ -2006,7 +2037,7 @@ impl Step for HashSign { // LLVM tools are linked dynamically. // Note: This function does no yet support Windows but we also don't support // linking LLVM tools dynamically on Windows yet. -pub fn maybe_install_llvm_dylib(builder: &Builder, +pub fn maybe_install_llvm_dylib(builder: &Builder<'_>, target: Interned, sysroot: &Path) { let src_libdir = builder @@ -2048,18 +2079,18 @@ impl Step for LlvmTools { type Output = Option; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("llvm-tools") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(LlvmTools { stage: run.builder.top_stage, target: run.target, }); } - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let stage = self.stage; let target = self.target; assert!(builder.config.extended); @@ -2074,7 +2105,7 @@ impl Step for LlvmTools { } builder.info(&format!("Dist LlvmTools stage{} ({})", stage, target)); - let src = builder.src.join("src/llvm"); + let src = builder.src.join("src/llvm-project/llvm"); let name = pkgname(builder, "llvm-tools"); let tmp = tmpdir(builder); @@ -2132,17 +2163,17 @@ impl Step for Lldb { const ONLY_HOSTS: bool = true; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { - run.path("src/tools/lldb") + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { + run.path("src/llvm-project/lldb").path("src/tools/lldb") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Lldb { target: run.target, }); } - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let target = self.target; if builder.config.dry_run { @@ -2158,7 +2189,7 @@ impl Step for Lldb { } builder.info(&format!("Dist Lldb ({})", target)); - let src = builder.src.join("src/tools/lldb"); + let src = builder.src.join("src/llvm-project/lldb"); let name = pkgname(builder, "lldb"); let tmp = tmpdir(builder); diff --git a/src/bootstrap/doc.rs b/src/bootstrap/doc.rs index eec193c21f..f81c64076e 100644 --- a/src/bootstrap/doc.rs +++ b/src/bootstrap/doc.rs @@ -23,7 +23,7 @@ use crate::cache::{INTERNER, Interned}; use crate::config::Config; macro_rules! book { - ($($name:ident, $path:expr, $book_name:expr;)+) => { + ($($name:ident, $path:expr, $book_name:expr, $book_ver:expr;)+) => { $( #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] pub struct $name { @@ -34,21 +34,22 @@ macro_rules! book { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path($path).default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure($name { target: run.target, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(Rustbook { target: self.target, name: INTERNER.intern_str($book_name), + version: $book_ver, }) } } @@ -56,19 +57,29 @@ macro_rules! book { } } +// NOTE: When adding a book here, make sure to ALSO build the book by +// adding a build step in `src/bootstrap/builder.rs`! book!( - Nomicon, "src/doc/nomicon", "nomicon"; - Reference, "src/doc/reference", "reference"; - EditionGuide, "src/doc/edition-guide", "edition-guide"; - RustdocBook, "src/doc/rustdoc", "rustdoc"; - RustcBook, "src/doc/rustc", "rustc"; - RustByExample, "src/doc/rust-by-example", "rust-by-example"; + EditionGuide, "src/doc/edition-guide", "edition-guide", RustbookVersion::MdBook1; + EmbeddedBook, "src/doc/embedded-book", "embedded-book", RustbookVersion::MdBook2; + Nomicon, "src/doc/nomicon", "nomicon", RustbookVersion::MdBook1; + Reference, "src/doc/reference", "reference", RustbookVersion::MdBook1; + RustByExample, "src/doc/rust-by-example", "rust-by-example", RustbookVersion::MdBook1; + RustcBook, "src/doc/rustc", "rustc", RustbookVersion::MdBook1; + RustdocBook, "src/doc/rustdoc", "rustdoc", RustbookVersion::MdBook1; ); +#[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] +enum RustbookVersion { + MdBook1, + MdBook2, +} + #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] struct Rustbook { target: Interned, name: Interned, + version: RustbookVersion, } impl Step for Rustbook { @@ -76,7 +87,7 @@ impl Step for Rustbook { // rustbook is never directly called, and only serves as a shim for the nomicon and the // reference. - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } @@ -84,12 +95,13 @@ impl Step for Rustbook { /// /// This will not actually generate any documentation if the documentation has /// already been generated. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let src = builder.src.join("src/doc"); builder.ensure(RustbookSrc { target: self.target, name: self.name, src: INTERNER.intern_path(src), + version: self.version, }); } } @@ -103,18 +115,18 @@ impl Step for UnstableBook { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/doc/unstable-book").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(UnstableBook { target: run.target, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(UnstableBookGen { target: self.target, }); @@ -122,6 +134,7 @@ impl Step for UnstableBook { target: self.target, name: INTERNER.intern_str("unstable-book"), src: builder.md_doc_out(self.target), + version: RustbookVersion::MdBook1, }) } } @@ -136,19 +149,19 @@ impl Step for CargoBook { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/tools/cargo/src/doc/book").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(CargoBook { target: run.target, name: INTERNER.intern_str("cargo"), }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; let name = self.name; let src = builder.src.join("src/tools/cargo/src/doc"); @@ -175,12 +188,13 @@ struct RustbookSrc { target: Interned, name: Interned, src: Interned, + version: RustbookVersion, } impl Step for RustbookSrc { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } @@ -188,7 +202,7 @@ impl Step for RustbookSrc { /// /// This will not actually generate any documentation if the documentation has /// already been generated. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; let name = self.name; let src = self.src; @@ -205,11 +219,19 @@ impl Step for RustbookSrc { } builder.info(&format!("Rustbook ({}) - {}", target, name)); let _ = fs::remove_dir_all(&out); + + let vers = match self.version { + RustbookVersion::MdBook1 => "1", + RustbookVersion::MdBook2 => "2", + }; + builder.run(rustbook_cmd .arg("build") .arg(&src) .arg("-d") - .arg(out)); + .arg(out) + .arg("-m") + .arg(vers)); } } @@ -224,12 +246,12 @@ impl Step for TheBook { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/doc/book").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(TheBook { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, @@ -237,7 +259,7 @@ impl Step for TheBook { }); } - /// Build the book and associated stuff. + /// Builds the book and associated stuff. /// /// We need to build: /// @@ -246,7 +268,7 @@ impl Step for TheBook { /// * Version info and CSS /// * Index page /// * Redirect pages - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target = self.target; let name = self.name; @@ -255,6 +277,7 @@ impl Step for TheBook { builder.ensure(Rustbook { target, name: INTERNER.intern_string(name.to_string()), + version: RustbookVersion::MdBook1, }); // building older edition redirects @@ -263,18 +286,21 @@ impl Step for TheBook { builder.ensure(Rustbook { target, name: INTERNER.intern_string(source_name), + version: RustbookVersion::MdBook1, }); let source_name = format!("{}/second-edition", name); builder.ensure(Rustbook { target, name: INTERNER.intern_string(source_name), + version: RustbookVersion::MdBook1, }); let source_name = format!("{}/2018-edition", name); builder.ensure(Rustbook { target, name: INTERNER.intern_string(source_name), + version: RustbookVersion::MdBook1, }); // build the version info page and CSS @@ -295,7 +321,12 @@ impl Step for TheBook { } } -fn invoke_rustdoc(builder: &Builder, compiler: Compiler, target: Interned, markdown: &str) { +fn invoke_rustdoc( + builder: &Builder<'_>, + compiler: Compiler, + target: Interned, + markdown: &str, +) { let out = builder.doc_out(target); let path = builder.src.join("src/doc").join(markdown); @@ -312,12 +343,9 @@ fn invoke_rustdoc(builder: &Builder, compiler: Compiler, target: Interned ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/doc").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Standalone { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, @@ -352,7 +380,7 @@ impl Step for Standalone { /// `STAMP` along with providing the various header/footer HTML we've customized. /// /// In the end, this is just a glorified wrapper around rustdoc! - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; let compiler = self.compiler; builder.info(&format!("Documenting standalone ({})", target)); @@ -400,8 +428,7 @@ impl Step for Standalone { .arg("--html-in-header").arg(&favicon) .arg("--markdown-no-toc") .arg("--index-page").arg(&builder.src.join("src/doc/index.md")) - .arg("--markdown-playground-url") - .arg("https://play.rust-lang.org/") + .arg("--markdown-playground-url").arg("https://play.rust-lang.org/") .arg("-o").arg(&out) .arg(&path); @@ -426,12 +453,12 @@ impl Step for Std { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.all_krates("std").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Std { stage: run.builder.top_stage, target: run.target @@ -442,7 +469,7 @@ impl Step for Std { /// /// This will generate all documentation for the standard library and its /// dependencies. This is largely just a wrapper around `cargo doc`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; builder.info(&format!("Documenting stage{} std ({})", stage, target)); @@ -491,6 +518,8 @@ impl Step for Std { cargo.arg("--") .arg("--markdown-css").arg("rust.css") .arg("--markdown-no-toc") + .arg("--generate-redirect-pages") + .arg("--resource-suffix").arg(crate::channel::CFG_RELEASE_NUM) .arg("--index-page").arg(&builder.src.join("src/doc/index.md")); builder.run(&mut cargo); @@ -512,12 +541,12 @@ impl Step for Test { type Output = (); const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.krate("test").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Test { stage: run.builder.top_stage, target: run.target, @@ -528,7 +557,7 @@ impl Step for Test { /// /// This will generate all documentation for libtest and its dependencies. This /// is largely just a wrapper around `cargo doc`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; builder.info(&format!("Documenting stage{} test ({})", stage, target)); @@ -555,7 +584,10 @@ impl Step for Test { let mut cargo = builder.cargo(compiler, Mode::Test, target, "doc"); compile::test_cargo(builder, &compiler, target, &mut cargo); - cargo.arg("--no-deps").arg("-p").arg("test"); + cargo.arg("--no-deps") + .arg("-p").arg("test") + .env("RUSTDOC_RESOURCE_SUFFIX", crate::channel::CFG_RELEASE_NUM) + .env("RUSTDOC_GENERATE_REDIRECT_PAGES", "1"); builder.run(&mut cargo); builder.cp_r(&my_out, &out); @@ -573,19 +605,19 @@ impl Step for WhitelistedRustc { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.krate("rustc-main").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(WhitelistedRustc { stage: run.builder.top_stage, target: run.target, }); } - /// Generate whitelisted compiler crate documentation. + /// Generates whitelisted compiler crate documentation. /// /// This will generate all documentation for crates that are whitelisted /// to be included in the standard documentation. This documentation is @@ -594,7 +626,7 @@ impl Step for WhitelistedRustc { /// documentation. We don't build other compiler documentation /// here as we want to be able to keep it separate from the standard /// documentation. This is largely just a wrapper around `cargo doc`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; builder.info(&format!("Documenting stage{} whitelisted compiler ({})", stage, target)); @@ -624,9 +656,10 @@ impl Step for WhitelistedRustc { // We don't want to build docs for internal compiler dependencies in this // step (there is another step for that). Therefore, we whitelist the crates // for which docs must be built. - cargo.arg("--no-deps"); for krate in &["proc_macro"] { - cargo.arg("-p").arg(krate); + cargo.arg("-p").arg(krate) + .env("RUSTDOC_RESOURCE_SUFFIX", crate::channel::CFG_RELEASE_NUM) + .env("RUSTDOC_GENERATE_REDIRECT_PAGES", "1"); } builder.run(&mut cargo); @@ -645,25 +678,25 @@ impl Step for Rustc { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.krate("rustc-main").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustc { stage: run.builder.top_stage, target: run.target, }); } - /// Generate compiler documentation. + /// Generates compiler documentation. /// /// This will generate all documentation for compiler and dependencies. /// Compiler documentation is distributed separately, so we make sure /// we do not merge it with the other documentation from std, test and /// proc_macros. This is largely just a wrapper around `cargo doc`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; builder.info(&format!("Documenting stage{} compiler ({})", stage, target)); @@ -721,7 +754,7 @@ impl Step for Rustc { } fn find_compiler_crates( - builder: &Builder, + builder: &Builder<'_>, name: &Interned, crates: &mut HashSet> ) { @@ -747,24 +780,24 @@ impl Step for Rustdoc { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.krate("rustdoc-tool") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustdoc { stage: run.builder.top_stage, target: run.target, }); } - /// Generate compiler documentation. + /// Generates compiler documentation. /// /// This will generate all documentation for compiler and dependencies. /// Compiler documentation is distributed separately, so we make sure /// we do not merge it with the other documentation from std, test and /// proc_macros. This is largely just a wrapper around `cargo doc`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let target = self.target; builder.info(&format!("Documenting stage{} rustdoc ({})", stage, target)); @@ -830,12 +863,12 @@ impl Step for ErrorIndex { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/tools/error_index_generator").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(ErrorIndex { target: run.target, }); @@ -843,7 +876,7 @@ impl Step for ErrorIndex { /// Generates the HTML rendered error-index by running the /// `error_index_generator` tool. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; builder.info(&format!("Documenting error index ({})", target)); @@ -852,6 +885,7 @@ impl Step for ErrorIndex { let mut index = builder.tool_cmd(Tool::ErrorIndex); index.arg("html"); index.arg(out.join("error-index.html")); + index.arg(crate::channel::CFG_RELEASE_NUM); // FIXME: shouldn't have to pass this env var index.env("CFG_BUILD", &builder.config.build) @@ -871,18 +905,18 @@ impl Step for UnstableBookGen { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/tools/unstable-book-gen").default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(UnstableBookGen { target: run.target, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let target = self.target; builder.ensure(compile::Std { diff --git a/src/bootstrap/install.rs b/src/bootstrap/install.rs index 1265fa9eff..2d040d60e5 100644 --- a/src/bootstrap/install.rs +++ b/src/bootstrap/install.rs @@ -14,45 +14,45 @@ use crate::builder::{Builder, RunConfig, ShouldRun, Step}; use crate::cache::Interned; use crate::config::Config; -pub fn install_docs(builder: &Builder, stage: u32, host: Interned) { +pub fn install_docs(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "docs", "rust-docs", stage, Some(host)); } -pub fn install_std(builder: &Builder, stage: u32, target: Interned) { +pub fn install_std(builder: &Builder<'_>, stage: u32, target: Interned) { install_sh(builder, "std", "rust-std", stage, Some(target)); } -pub fn install_cargo(builder: &Builder, stage: u32, host: Interned) { +pub fn install_cargo(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "cargo", "cargo", stage, Some(host)); } -pub fn install_rls(builder: &Builder, stage: u32, host: Interned) { +pub fn install_rls(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "rls", "rls", stage, Some(host)); } -pub fn install_clippy(builder: &Builder, stage: u32, host: Interned) { +pub fn install_clippy(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "clippy", "clippy", stage, Some(host)); } -pub fn install_miri(builder: &Builder, stage: u32, host: Interned) { +pub fn install_miri(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "miri", "miri", stage, Some(host)); } -pub fn install_rustfmt(builder: &Builder, stage: u32, host: Interned) { +pub fn install_rustfmt(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "rustfmt", "rustfmt", stage, Some(host)); } -pub fn install_analysis(builder: &Builder, stage: u32, host: Interned) { +pub fn install_analysis(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "analysis", "rust-analysis", stage, Some(host)); } -pub fn install_src(builder: &Builder, stage: u32) { +pub fn install_src(builder: &Builder<'_>, stage: u32) { install_sh(builder, "src", "rust-src", stage, None); } -pub fn install_rustc(builder: &Builder, stage: u32, host: Interned) { +pub fn install_rustc(builder: &Builder<'_>, stage: u32, host: Interned) { install_sh(builder, "rustc", "rustc", stage, Some(host)); } fn install_sh( - builder: &Builder, + builder: &Builder<'_>, package: &str, name: &str, stage: u32, @@ -155,7 +155,7 @@ macro_rules! install { } #[allow(dead_code)] - fn should_install(builder: &Builder) -> bool { + fn should_install(builder: &Builder<'_>) -> bool { builder.config.tools.as_ref().map_or(false, |t| t.contains($path)) } } @@ -166,12 +166,12 @@ macro_rules! install { const ONLY_HOSTS: bool = $only_hosts; $(const $c: bool = true;)* - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let $_config = &run.builder.config; run.path($path).default_condition($default_cond) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure($name { stage: run.builder.top_stage, target: run.target, @@ -179,7 +179,7 @@ macro_rules! install { }); } - fn run($sel, $builder: &Builder) { + fn run($sel, $builder: &Builder<'_>) { $run_item } })+ @@ -262,20 +262,20 @@ impl Step for Src { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let config = &run.builder.config; let cond = config.extended && config.tools.as_ref().map_or(true, |t| t.contains("src")); run.path("src").default_condition(cond) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Src { stage: run.builder.top_stage, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(dist::Src); install_src(builder, self.stage); } diff --git a/src/bootstrap/lib.rs b/src/bootstrap/lib.rs index 7491385af7..7e6fbdff12 100644 --- a/src/bootstrap/lib.rs +++ b/src/bootstrap/lib.rs @@ -69,7 +69,7 @@ //! ## Copying stage0 {std,test,rustc} //! //! This copies the build output from Cargo into -//! `build/$HOST/stage0-sysroot/lib/rustlib/$ARCH/lib`. FIXME: This step's +//! `build/$HOST/stage0-sysroot/lib/rustlib/$ARCH/lib`. FIXME: this step's //! documentation should be expanded -- the information already here may be //! incorrect. //! @@ -103,7 +103,7 @@ //! More documentation can be found in each respective module below, and you can //! also check out the `src/bootstrap/README.md` file for more information. -#![deny(bare_trait_objects)] +#![deny(rust_2018_idioms)] #![deny(warnings)] #![feature(core_intrinsics)] #![feature(drain_filter)] @@ -114,28 +114,16 @@ extern crate build_helper; extern crate serde_derive; #[macro_use] extern crate lazy_static; -extern crate serde_json; -extern crate cmake; -extern crate filetime; -extern crate cc; -extern crate getopts; -extern crate num_cpus; -extern crate toml; -extern crate time; -extern crate petgraph; #[cfg(test)] #[macro_use] extern crate pretty_assertions; -#[cfg(unix)] -extern crate libc; - use std::cell::{RefCell, Cell}; use std::collections::{HashSet, HashMap}; use std::env; use std::fs::{self, OpenOptions, File}; -use std::io::{self, Seek, SeekFrom, Write, Read}; +use std::io::{Seek, SeekFrom, Write, Read}; use std::path::{PathBuf, Path}; use std::process::{self, Command}; use std::slice; @@ -176,8 +164,6 @@ mod job; #[cfg(all(unix, not(target_os = "haiku")))] mod job { - use libc; - pub unsafe fn setup(build: &mut crate::Build) { if build.config.low_priority { libc::setpriority(libc::PRIO_PGRP as _, 0, 10); @@ -255,6 +241,8 @@ pub struct Build { clippy_info: channel::GitInfo, miri_info: channel::GitInfo, rustfmt_info: channel::GitInfo, + in_tree_llvm_info: channel::GitInfo, + emscripten_llvm_info: channel::GitInfo, local_rebuild: bool, fail_fast: bool, doc_tests: DocTests, @@ -377,6 +365,8 @@ impl Build { let clippy_info = channel::GitInfo::new(&config, &src.join("src/tools/clippy")); let miri_info = channel::GitInfo::new(&config, &src.join("src/tools/miri")); let rustfmt_info = channel::GitInfo::new(&config, &src.join("src/tools/rustfmt")); + let in_tree_llvm_info = channel::GitInfo::new(&config, &src.join("src/llvm-project")); + let emscripten_llvm_info = channel::GitInfo::new(&config, &src.join("src/llvm-emscripten")); let mut build = Build { initial_rustc: config.initial_rustc.clone(), @@ -400,6 +390,8 @@ impl Build { clippy_info, miri_info, rustfmt_info, + in_tree_llvm_info, + emscripten_llvm_info, cc: HashMap::new(), cxx: HashMap::new(), ar: HashMap::new(), @@ -504,7 +496,7 @@ impl Build { cleared } - /// Get the space-separated set of activated features for the standard + /// Gets the space-separated set of activated features for the standard /// library. fn std_features(&self) -> String { let mut features = "panic-unwind".to_string(); @@ -521,7 +513,7 @@ impl Build { features } - /// Get the space-separated set of activated features for the compiler. + /// Gets the space-separated set of activated features for the compiler. fn rustc_features(&self) -> String { let mut features = String::new(); if self.config.jemalloc { @@ -609,7 +601,7 @@ impl Build { self.out.join(&*target).join("crate-docs") } - /// Returns true if no custom `llvm-config` is set for the specified target. + /// Returns `true` if no custom `llvm-config` is set for the specified target. /// /// If no custom `llvm-config` was specified then Rust's llvm will be used. fn is_rust_llvm(&self, target: Interned) -> bool { @@ -831,6 +823,7 @@ impl Build { !target.contains("msvc") && !target.contains("emscripten") && !target.contains("wasm32") && + !target.contains("nvptx") && !target.contains("fuchsia") { Some(self.cc(target)) } else { @@ -856,13 +849,13 @@ impl Build { .map(|p| &**p) } - /// Returns true if this is a no-std `target`, if defined + /// Returns `true` if this is a no-std `target`, if defined fn no_std(&self, target: Interned) -> Option { self.config.target_config.get(&target) .map(|t| t.no_std) } - /// Returns whether the target will be tested using the `remote-test-client` + /// Returns `true` if the target will be tested using the `remote-test-client` /// and `remote-test-server` binaries. fn remote_tested(&self, target: Interned) -> bool { self.qemu_rootfs(target).is_some() || target.contains("android") || @@ -1058,7 +1051,7 @@ impl Build { self.rust_info.version(self, channel::CFG_RELEASE_NUM) } - /// Return the full commit hash + /// Returns the full commit hash. fn rust_sha(&self) -> Option<&str> { self.rust_info.sha() } @@ -1078,7 +1071,7 @@ impl Build { panic!("failed to find version in {}'s Cargo.toml", package) } - /// Returns whether unstable features should be enabled for the compiler + /// Returns `true` if unstable features should be enabled for the compiler /// we're building. fn unstable_features(&self) -> bool { match &self.config.channel[..] { @@ -1263,9 +1256,15 @@ impl Build { if !src.exists() { panic!("Error: File \"{}\" not found!", src.display()); } - let mut s = t!(fs::File::open(&src)); - let mut d = t!(fs::File::create(&dst)); - io::copy(&mut s, &mut d).expect("failed to copy"); + let metadata = t!(src.symlink_metadata()); + if let Err(e) = fs::copy(&src, &dst) { + panic!("failed to copy `{}` to `{}`: {}", src.display(), + dst.display(), e) + } + t!(fs::set_permissions(&dst, metadata.permissions())); + let atime = FileTime::from_last_access_time(&metadata); + let mtime = FileTime::from_last_modification_time(&metadata); + t!(filetime::set_file_times(&dst, atime, mtime)); } chmod(&dst, perms); } @@ -1320,7 +1319,7 @@ impl<'a> Compiler { self } - /// Returns whether this is a snapshot compiler for `build`'s configuration + /// Returns `true` if this is a snapshot compiler for `build`'s configuration pub fn is_snapshot(&self, build: &Build) -> bool { self.stage == 0 && self.host == build.build } diff --git a/src/bootstrap/mk/Makefile.in b/src/bootstrap/mk/Makefile.in index 8ff1456f0f..1c27cf3909 100644 --- a/src/bootstrap/mk/Makefile.in +++ b/src/bootstrap/mk/Makefile.in @@ -53,7 +53,6 @@ check-aux: src/test/run-fail/pretty \ src/test/run-pass-valgrind/pretty \ src/test/run-pass-fulldeps/pretty \ - src/test/run-fail-fulldeps/pretty \ $(AUX_ARGS) \ $(BOOTSTRAP_ARGS) check-bootstrap: diff --git a/src/bootstrap/native.rs b/src/bootstrap/native.rs index cb9c86df55..c9a017823a 100644 --- a/src/bootstrap/native.rs +++ b/src/bootstrap/native.rs @@ -18,6 +18,7 @@ use build_helper::output; use cmake; use cc; +use crate::channel; use crate::util::{self, exe}; use build_helper::up_to_date; use crate::builder::{Builder, RunConfig, ShouldRun, Step}; @@ -35,11 +36,14 @@ impl Step for Llvm { const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { - run.path("src/llvm").path("src/llvm-emscripten") + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { + run.path("src/llvm-project") + .path("src/llvm-project/llvm") + .path("src/llvm") + .path("src/llvm-emscripten") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let emscripten = run.path.ends_with("llvm-emscripten"); run.builder.ensure(Llvm { target: run.target, @@ -48,7 +52,7 @@ impl Step for Llvm { } /// Compile LLVM for `target`. - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let target = self.target; let emscripten = self.emscripten; @@ -97,7 +101,7 @@ impl Step for Llvm { t!(fs::create_dir_all(&out_dir)); // http://llvm.org/docs/CMake.html - let root = if self.emscripten { "src/llvm-emscripten" } else { "src/llvm" }; + let root = if self.emscripten { "src/llvm-emscripten" } else { "src/llvm-project/llvm" }; let mut cfg = cmake::Config::new(builder.src.join(root)); let profile = match (builder.config.llvm_optimize, builder.config.llvm_release_debuginfo) { @@ -189,10 +193,10 @@ impl Step for Llvm { } if want_lldb { - cfg.define("LLVM_EXTERNAL_CLANG_SOURCE_DIR", builder.src.join("src/tools/clang")); - cfg.define("LLVM_EXTERNAL_LLDB_SOURCE_DIR", builder.src.join("src/tools/lldb")); + cfg.define("LLVM_ENABLE_PROJECTS", "clang;lldb"); // For the time being, disable code signing. cfg.define("LLDB_CODESIGN_IDENTITY", ""); + cfg.define("LLDB_NO_DEBUGSERVER", "ON"); } else { // LLDB requires libxml2; but otherwise we want it to be disabled. // See https://github.com/rust-lang/rust/pull/50104 @@ -228,7 +232,30 @@ impl Step for Llvm { } if let Some(ref suffix) = builder.config.llvm_version_suffix { - cfg.define("LLVM_VERSION_SUFFIX", suffix); + // Allow version-suffix="" to not define a version suffix at all. + if !suffix.is_empty() { + cfg.define("LLVM_VERSION_SUFFIX", suffix); + } + } else { + let mut default_suffix = format!( + "-rust-{}-{}", + channel::CFG_RELEASE_NUM, + builder.config.channel, + ); + let llvm_info = if self.emscripten { + &builder.emscripten_llvm_info + } else { + &builder.in_tree_llvm_info + }; + if let Some(sha) = llvm_info.sha_short() { + default_suffix.push_str("-"); + default_suffix.push_str(sha); + } + cfg.define("LLVM_VERSION_SUFFIX", default_suffix); + } + + if let Some(ref linker) = builder.config.llvm_use_linker { + cfg.define("LLVM_USE_LINKER", linker); } if let Some(ref python) = builder.config.python { @@ -254,7 +281,7 @@ impl Step for Llvm { } } -fn check_llvm_version(builder: &Builder, llvm_config: &Path) { +fn check_llvm_version(builder: &Builder<'_>, llvm_config: &Path) { if !builder.config.llvm_version_check { return } @@ -275,7 +302,7 @@ fn check_llvm_version(builder: &Builder, llvm_config: &Path) { panic!("\n\nbad LLVM version: {}, need >=6.0\n\n", version) } -fn configure_cmake(builder: &Builder, +fn configure_cmake(builder: &Builder<'_>, target: Interned, cfg: &mut cmake::Config) { if builder.config.ninja { @@ -358,7 +385,11 @@ fn configure_cmake(builder: &Builder, } cfg.build_arg("-j").build_arg(builder.jobs().to_string()); - cfg.define("CMAKE_C_FLAGS", builder.cflags(target, GitRepo::Llvm).join(" ")); + let mut cflags = builder.cflags(target, GitRepo::Llvm).join(" "); + if let Some(ref s) = builder.config.llvm_cxxflags { + cflags.push_str(&format!(" {}", s)); + } + cfg.define("CMAKE_C_FLAGS", cflags); let mut cxxflags = builder.cflags(target, GitRepo::Llvm).join(" "); if builder.config.llvm_static_stdcpp && !target.contains("windows") && @@ -366,6 +397,9 @@ fn configure_cmake(builder: &Builder, { cxxflags.push_str(" -static-libstdc++"); } + if let Some(ref s) = builder.config.llvm_cxxflags { + cxxflags.push_str(&format!(" {}", s)); + } cfg.define("CMAKE_CXX_FLAGS", cxxflags); if let Some(ar) = builder.ar(target) { if ar.is_absolute() { @@ -383,6 +417,12 @@ fn configure_cmake(builder: &Builder, } } + if let Some(ref s) = builder.config.llvm_ldflags { + cfg.define("CMAKE_SHARED_LINKER_FLAGS", s); + cfg.define("CMAKE_MODULE_LINKER_FLAGS", s); + cfg.define("CMAKE_EXE_LINKER_FLAGS", s); + } + if env::var_os("SCCACHE_ERROR_LOG").is_some() { cfg.env("RUST_LOG", "sccache=warn"); } @@ -397,16 +437,16 @@ impl Step for Lld { type Output = PathBuf; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { - run.path("src/tools/lld") + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { + run.path("src/llvm-project/lld").path("src/tools/lld") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Lld { target: run.target }); } /// Compile LLVM for `target`. - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { if builder.config.dry_run { return PathBuf::from("lld-out-dir-test-gen"); } @@ -428,7 +468,7 @@ impl Step for Lld { let _time = util::timeit(&builder); t!(fs::create_dir_all(&out_dir)); - let mut cfg = cmake::Config::new(builder.src.join("src/tools/lld")); + let mut cfg = cmake::Config::new(builder.src.join("src/llvm-project/lld")); configure_cmake(builder, target, &mut cfg); // This is an awful, awful hack. Discovered when we migrated to using @@ -469,17 +509,17 @@ pub struct TestHelpers { impl Step for TestHelpers { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/test/auxiliary/rust_test_helpers.c") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(TestHelpers { target: run.target }) } /// Compiles the `rust_test_helpers.c` library which we used in various /// `run-pass` test suites for ABI testing. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { if builder.config.dry_run { return; } diff --git a/src/bootstrap/sanity.rs b/src/bootstrap/sanity.rs index fe547a6b15..ff4fb85bbf 100644 --- a/src/bootstrap/sanity.rs +++ b/src/bootstrap/sanity.rs @@ -156,7 +156,7 @@ pub fn check(build: &mut Build) { panic!("the iOS target is only supported on macOS"); } - if target.contains("-none-") { + if target.contains("-none-") || target.contains("nvptx") { if build.no_std(*target).is_none() { let target = build.config.target_config.entry(target.clone()) .or_default(); @@ -165,7 +165,7 @@ pub fn check(build: &mut Build) { } if build.no_std(*target) == Some(false) { - panic!("All the *-none-* targets are no-std targets") + panic!("All the *-none-* and nvptx* targets are no-std targets") } } diff --git a/src/bootstrap/test.rs b/src/bootstrap/test.rs index 2edc78ebaa..b7323b2ead 100644 --- a/src/bootstrap/test.rs +++ b/src/bootstrap/test.rs @@ -30,9 +30,9 @@ const ADB_TEST_DIR: &str = "/data/tmp/work"; /// The two modes of the test runner; tests or benchmarks. #[derive(Debug, PartialEq, Eq, Hash, Copy, Clone, PartialOrd, Ord)] pub enum TestKind { - /// Run `cargo test` + /// Run `cargo test`. Test, - /// Run `cargo bench` + /// Run `cargo bench`. Bench, } @@ -57,7 +57,7 @@ impl TestKind { } impl fmt::Display for TestKind { - fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { + fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { f.write_str(match *self { TestKind::Test => "Testing", TestKind::Bench => "Benchmarking", @@ -65,7 +65,7 @@ impl fmt::Display for TestKind { } } -fn try_run(builder: &Builder, cmd: &mut Command) -> bool { +fn try_run(builder: &Builder<'_>, cmd: &mut Command) -> bool { if !builder.fail_fast { if !builder.try_run(cmd) { let mut failures = builder.delayed_failures.borrow_mut(); @@ -78,7 +78,7 @@ fn try_run(builder: &Builder, cmd: &mut Command) -> bool { true } -fn try_run_quiet(builder: &Builder, cmd: &mut Command) -> bool { +fn try_run_quiet(builder: &Builder<'_>, cmd: &mut Command) -> bool { if !builder.fail_fast { if !builder.try_run_quiet(cmd) { let mut failures = builder.delayed_failures.borrow_mut(); @@ -105,7 +105,7 @@ impl Step for Linkcheck { /// /// This tool in `src/tools` will verify the validity of all our links in the /// documentation to ensure we don't have a bunch of dead ones. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let host = self.host; builder.info(&format!("Linkcheck ({})", host)); @@ -121,13 +121,13 @@ impl Step for Linkcheck { ); } - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/tools/linkchecker") .default_condition(builder.config.docs) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Linkcheck { host: run.target }); } } @@ -142,11 +142,11 @@ impl Step for Cargotest { type Output = (); const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/cargotest") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Cargotest { stage: run.builder.top_stage, host: run.target, @@ -157,7 +157,7 @@ impl Step for Cargotest { /// /// This tool in `src/tools` will check out a few Rust projects and run `cargo /// test` to ensure that we don't regress the test suites there. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = builder.compiler(self.stage, self.host); builder.ensure(compile::Rustc { compiler, @@ -192,11 +192,11 @@ impl Step for Cargo { type Output = (); const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/cargo") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Cargo { stage: run.builder.top_stage, host: run.target, @@ -204,7 +204,7 @@ impl Step for Cargo { } /// Runs `cargo test` for `cargo` packaged with Rust. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = builder.compiler(self.stage, self.host); builder.ensure(tool::Cargo { @@ -247,11 +247,11 @@ impl Step for Rls { type Output = (); const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rls") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rls { stage: run.builder.top_stage, host: run.target, @@ -259,7 +259,7 @@ impl Step for Rls { } /// Runs `cargo test` for the rls. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let host = self.host; let compiler = builder.compiler(stage, host); @@ -303,11 +303,11 @@ impl Step for Rustfmt { type Output = (); const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rustfmt") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustfmt { stage: run.builder.top_stage, host: run.target, @@ -315,7 +315,7 @@ impl Step for Rustfmt { } /// Runs `cargo test` for rustfmt. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let host = self.host; let compiler = builder.compiler(stage, host); @@ -362,12 +362,12 @@ impl Step for Miri { const ONLY_HOSTS: bool = true; const DEFAULT: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let test_miri = run.builder.config.test_miri; run.path("src/tools/miri").default_condition(test_miri) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Miri { stage: run.builder.top_stage, host: run.target, @@ -375,7 +375,7 @@ impl Step for Miri { } /// Runs `cargo test` for miri. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let host = self.host; let compiler = builder.compiler(stage, host); @@ -421,11 +421,11 @@ pub struct CompiletestTest { impl Step for CompiletestTest { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/compiletest") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(CompiletestTest { stage: run.builder.top_stage, host: run.target, @@ -433,7 +433,7 @@ impl Step for CompiletestTest { } /// Runs `cargo test` for compiletest. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let host = self.host; let compiler = builder.compiler(stage, host); @@ -462,11 +462,11 @@ impl Step for Clippy { const ONLY_HOSTS: bool = true; const DEFAULT: bool = false; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/clippy") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Clippy { stage: run.builder.top_stage, host: run.target, @@ -474,7 +474,7 @@ impl Step for Clippy { } /// Runs `cargo test` for clippy. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let stage = self.stage; let host = self.host; let compiler = builder.compiler(stage, host); @@ -516,7 +516,7 @@ impl Step for Clippy { } } -fn path_for_cargo(builder: &Builder, compiler: Compiler) -> OsString { +fn path_for_cargo(builder: &Builder<'_>, compiler: Compiler) -> OsString { // Configure PATH to find the right rustc. NB. we have to use PATH // and not RUSTC because the Cargo test suite has tests that will // fail if rustc is not spelled `rustc`. @@ -535,17 +535,17 @@ impl Step for RustdocTheme { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rustdoc-themes") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let compiler = run.builder.compiler(run.builder.top_stage, run.host); run.builder.ensure(RustdocTheme { compiler }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let rustdoc = builder.out.join("bootstrap/debug/rustdoc"); let mut cmd = builder.tool_cmd(Tool::RustdocTheme); cmd.arg(rustdoc.to_str().unwrap()) @@ -574,36 +574,79 @@ impl Step for RustdocTheme { } #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] -pub struct RustdocJS { +pub struct RustdocJSStd { pub host: Interned, pub target: Interned, } -impl Step for RustdocJS { +impl Step for RustdocJSStd { type Output = (); const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { - run.path("src/test/rustdoc-js") + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { + run.path("src/test/rustdoc-js-std") } - fn make_run(run: RunConfig) { - run.builder.ensure(RustdocJS { + fn make_run(run: RunConfig<'_>) { + run.builder.ensure(RustdocJSStd { host: run.host, target: run.target, }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { if let Some(ref nodejs) = builder.config.nodejs { let mut command = Command::new(nodejs); - command.args(&["src/tools/rustdoc-js/tester.js", &*self.host]); + command.args(&["src/tools/rustdoc-js-std/tester.js", &*self.host]); builder.ensure(crate::doc::Std { target: self.target, stage: builder.top_stage, }); builder.run(&mut command); + } else { + builder.info( + "No nodejs found, skipping \"src/test/rustdoc-js-std\" tests" + ); + } + } +} + +#[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)] +pub struct RustdocJSNotStd { + pub host: Interned, + pub target: Interned, + pub compiler: Compiler, +} + +impl Step for RustdocJSNotStd { + type Output = (); + const DEFAULT: bool = true; + const ONLY_HOSTS: bool = true; + + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { + run.path("src/test/rustdoc-js") + } + + fn make_run(run: RunConfig<'_>) { + let compiler = run.builder.compiler(run.builder.top_stage, run.host); + run.builder.ensure(RustdocJSNotStd { + host: run.host, + target: run.target, + compiler, + }); + } + + fn run(self, builder: &Builder<'_>) { + if builder.config.nodejs.is_some() { + builder.ensure(Compiletest { + compiler: self.compiler, + target: self.target, + mode: "js-doc-test", + suite: "rustdoc-js", + path: None, + compare_mode: None, + }); } else { builder.info( "No nodejs found, skipping \"src/test/rustdoc-js\" tests" @@ -624,11 +667,11 @@ impl Step for RustdocUi { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/test/rustdoc-ui") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let compiler = run.builder.compiler(run.builder.top_stage, run.host); run.builder.ensure(RustdocUi { host: run.host, @@ -637,7 +680,7 @@ impl Step for RustdocUi { }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(Compiletest { compiler: self.compiler, target: self.target, @@ -662,7 +705,7 @@ impl Step for Tidy { /// This tool in `src/tools` checks up on various bits and pieces of style and /// otherwise just implements a few lint-like checks that are specific to the /// compiler itself. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let mut cmd = builder.tool_cmd(Tool::Tidy); cmd.arg(builder.src.join("src")); cmd.arg(&builder.initial_cargo); @@ -678,16 +721,16 @@ impl Step for Tidy { try_run(builder, &mut cmd); } - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/tidy") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Tidy); } } -fn testdir(builder: &Builder, host: Interned) -> PathBuf { +fn testdir(builder: &Builder<'_>, host: Interned) -> PathBuf { builder.out.join(host).join("test") } @@ -747,11 +790,11 @@ macro_rules! test_definitions { const DEFAULT: bool = $default; const ONLY_HOSTS: bool = $host; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.suite_path($path) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let compiler = run.builder.compiler(run.builder.top_stage, run.host); run.builder.ensure($name { @@ -760,7 +803,7 @@ macro_rules! test_definitions { }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(Compiletest { compiler: self.compiler, target: self.target, @@ -848,12 +891,6 @@ host_test!(RunPassFullDeps { suite: "run-pass-fulldeps" }); -host_test!(RunFailFullDeps { - path: "src/test/run-fail-fulldeps", - mode: "run-fail", - suite: "run-fail-fulldeps" -}); - host_test!(Rustdoc { path: "src/test/rustdoc", mode: "rustdoc", @@ -888,20 +925,6 @@ test!(RunPassValgrindPretty { default: false, host: true }); -test!(RunPassFullDepsPretty { - path: "src/test/run-pass-fulldeps/pretty", - mode: "pretty", - suite: "run-pass-fulldeps", - default: false, - host: true -}); -test!(RunFailFullDepsPretty { - path: "src/test/run-fail-fulldeps/pretty", - mode: "pretty", - suite: "run-fail-fulldeps", - default: false, - host: true -}); default_test!(RunMake { path: "src/test/run-make", @@ -928,7 +951,7 @@ struct Compiletest { impl Step for Compiletest { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } @@ -937,7 +960,7 @@ impl Step for Compiletest { /// Compiles all tests with `compiler` for `target` with the specified /// compiletest `mode` and `suite` arguments. For example `mode` can be /// "run-pass" or `suite` can be something like `debuginfo`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target = self.target; let mode = self.mode; @@ -1010,12 +1033,13 @@ impl Step for Compiletest { .arg(builder.sysroot_libdir(compiler, target)); cmd.arg("--rustc-path").arg(builder.rustc(compiler)); - let is_rustdoc_ui = suite.ends_with("rustdoc-ui"); + let is_rustdoc = suite.ends_with("rustdoc-ui") || suite.ends_with("rustdoc-js"); // Avoid depending on rustdoc when we don't need it. if mode == "rustdoc" || (mode == "run-make" && suite.ends_with("fulldeps")) - || (mode == "ui" && is_rustdoc_ui) + || (mode == "ui" && is_rustdoc) + || mode == "js-doc-test" { cmd.arg("--rustdoc-path") .arg(builder.rustdoc(compiler.host)); @@ -1049,12 +1073,12 @@ impl Step for Compiletest { cmd.arg("--nodejs").arg(nodejs); } - let mut flags = if is_rustdoc_ui { + let mut flags = if is_rustdoc { Vec::new() } else { vec!["-Crpath".to_string()] }; - if !is_rustdoc_ui { + if !is_rustdoc { if builder.config.rust_optimize_tests { flags.push("-O".to_string()); } @@ -1108,9 +1132,7 @@ impl Step for Compiletest { }; let lldb_exe = if builder.config.lldb_enabled && !target.contains("emscripten") { // Test against the lldb that was just built. - builder.llvm_out(target) - .join("bin") - .join("lldb") + builder.llvm_out(target).join("bin").join("lldb") } else { PathBuf::from("lldb") }; @@ -1127,6 +1149,26 @@ impl Step for Compiletest { } } + if let Some(var) = env::var_os("RUSTBUILD_FORCE_CLANG_BASED_TESTS") { + match &var.to_string_lossy().to_lowercase()[..] { + "1" | "yes" | "on" => { + assert!(builder.config.lldb_enabled, + "RUSTBUILD_FORCE_CLANG_BASED_TESTS needs Clang/LLDB to \ + be built."); + let clang_exe = builder.llvm_out(target).join("bin").join("clang"); + cmd.arg("--run-clang-based-tests-with").arg(clang_exe); + } + "0" | "no" | "off" => { + // Nothing to do. + } + other => { + // Let's make sure typos don't get unnoticed + panic!("Unrecognized option '{}' set in \ + RUSTBUILD_FORCE_CLANG_BASED_TESTS", other); + } + } + } + // Get paths from cmd args let paths = match &builder.config.cmd { Subcommand::Test { ref paths, .. } => &paths[..], @@ -1286,16 +1328,16 @@ impl Step for DocTest { type Output = (); const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } - /// Run `rustdoc --test` for all documentation in `src/doc`. + /// Runs `rustdoc --test` for all documentation in `src/doc`. /// /// This will run all tests in our markdown documentation (e.g., the book) /// located in `src/doc`. The `rustdoc` that's run is the one that sits next to /// `compiler`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; builder.ensure(compile::Test { @@ -1356,17 +1398,17 @@ macro_rules! test_book { const DEFAULT: bool = $default; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path($path) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure($name { compiler: run.builder.compiler(run.builder.top_stage, run.host), }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(DocTest { compiler: self.compiler, path: $path, @@ -1385,6 +1427,7 @@ test_book!( RustdocBook, "src/doc/rustdoc", "rustdoc", default=true; RustcBook, "src/doc/rustc", "rustc", default=true; RustByExample, "src/doc/rust-by-example", "rust-by-example", default=false; + EmbeddedBook, "src/doc/embedded-book", "embedded-book", default=false; TheBook, "src/doc/book", "book", default=false; UnstableBook, "src/doc/unstable-book", "unstable-book", default=true; ); @@ -1399,23 +1442,23 @@ impl Step for ErrorIndex { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/error_index_generator") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(ErrorIndex { compiler: run.builder.compiler(run.builder.top_stage, run.host), }); } - /// Run the error index generator tool to execute the tests located in the error + /// Runs the error index generator tool to execute the tests located in the error /// index. /// /// The `error_index_generator` tool lives in `src/tools` and is used to /// generate a markdown file from the error indexes of the code base which is /// then passed to `rustdoc --test`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; builder.ensure(compile::Std { @@ -1441,7 +1484,7 @@ impl Step for ErrorIndex { } } -fn markdown_test(builder: &Builder, compiler: Compiler, markdown: &Path) -> bool { +fn markdown_test(builder: &Builder<'_>, compiler: Compiler, markdown: &Path) -> bool { match fs::read_to_string(markdown) { Ok(contents) => { if !contents.contains("```") { @@ -1481,11 +1524,11 @@ impl Step for CrateLibrustc { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.krate("rustc-main") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let builder = run.builder; let compiler = builder.compiler(builder.top_stage, run.host); @@ -1503,7 +1546,7 @@ impl Step for CrateLibrustc { } } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(Crate { compiler: self.compiler, target: self.target, @@ -1525,14 +1568,14 @@ pub struct CrateNotDefault { impl Step for CrateNotDefault { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/librustc_asan") .path("src/librustc_lsan") .path("src/librustc_msan") .path("src/librustc_tsan") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let builder = run.builder; let compiler = builder.compiler(builder.top_stage, run.host); @@ -1552,7 +1595,7 @@ impl Step for CrateNotDefault { }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { builder.ensure(Crate { compiler: self.compiler, target: self.target, @@ -1576,7 +1619,7 @@ impl Step for Crate { type Output = (); const DEFAULT: bool = true; - fn should_run(mut run: ShouldRun) -> ShouldRun { + fn should_run(mut run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run = run.krate("test"); for krate in run.builder.in_tree_crates("std") { @@ -1587,7 +1630,7 @@ impl Step for Crate { run } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let builder = run.builder; let compiler = builder.compiler(builder.top_stage, run.host); @@ -1615,7 +1658,7 @@ impl Step for Crate { } } - /// Run all unit tests plus documentation tests for a given crate defined + /// Runs all unit tests plus documentation tests for a given crate defined /// by a `Cargo.toml` (single manifest) /// /// This is what runs tests for crates like the standard library, compiler, etc. @@ -1623,7 +1666,7 @@ impl Step for Crate { /// /// Currently this runs all tests for a DAG by passing a bunch of `-p foo` /// arguments, and those arguments are discovered from `cargo metadata`. - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target = self.target; let mode = self.mode; @@ -1764,11 +1807,11 @@ impl Step for CrateRustdoc { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.paths(&["src/librustdoc", "src/tools/rustdoc"]) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { let builder = run.builder; let test_kind = builder.kind.into(); @@ -1779,7 +1822,7 @@ impl Step for CrateRustdoc { }); } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let test_kind = self.test_kind; let compiler = builder.compiler(builder.top_stage, self.host); @@ -1834,7 +1877,7 @@ fn envify(s: &str) -> String { /// the standard library and such to the emulator ahead of time. This step /// represents this and is a dependency of all test suites. /// -/// Most of the time this is a noop. For some steps such as shipping data to +/// Most of the time this is a no-op. For some steps such as shipping data to /// QEMU we have to build our own tools so we've got conditional dependencies /// on those programs as well. Note that the remote test client is built for /// the build target (us) and the server is built for the target. @@ -1847,11 +1890,11 @@ pub struct RemoteCopyLibs { impl Step for RemoteCopyLibs { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } - fn run(self, builder: &Builder) { + fn run(self, builder: &Builder<'_>) { let compiler = self.compiler; let target = self.target; if !builder.remote_tested(target) { @@ -1897,16 +1940,16 @@ pub struct Distcheck; impl Step for Distcheck { type Output = (); - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("distcheck") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Distcheck); } - /// Run "distcheck", a 'make check' from a tarball - fn run(self, builder: &Builder) { + /// Runs "distcheck", a 'make check' from a tarball + fn run(self, builder: &Builder<'_>) { builder.info("Distcheck"); let dir = builder.out.join("tmp").join("distcheck"); let _ = fs::remove_dir_all(&dir); @@ -1966,8 +2009,8 @@ impl Step for Bootstrap { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - /// Test the build system itself - fn run(self, builder: &Builder) { + /// Tests the build system itself. + fn run(self, builder: &Builder<'_>) { let mut cmd = Command::new(&builder.initial_cargo); cmd.arg("test") .current_dir(builder.src.join("src/bootstrap")) @@ -1991,11 +2034,11 @@ impl Step for Bootstrap { try_run(builder, &mut cmd); } - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/bootstrap") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Bootstrap); } } diff --git a/src/bootstrap/tool.rs b/src/bootstrap/tool.rs index 9f6db73e6f..fc1a17d546 100644 --- a/src/bootstrap/tool.rs +++ b/src/bootstrap/tool.rs @@ -1,6 +1,5 @@ use std::fs; use std::env; -use std::iter; use std::path::PathBuf; use std::process::{Command, exit}; use std::collections::HashSet; @@ -37,15 +36,15 @@ struct ToolBuild { impl Step for ToolBuild { type Output = Option; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.never() } - /// Build a tool in `src/tools` + /// Builds a tool in `src/tools` /// /// This will build the specified tool with the specified `host` compiler in /// `stage` into the normal cargo output directory. - fn run(self, builder: &Builder) -> Option { + fn run(self, builder: &Builder<'_>) -> Option { let compiler = self.compiler; let target = self.target; let tool = self.tool; @@ -193,7 +192,7 @@ impl Step for ToolBuild { } pub fn prepare_tool_cargo( - builder: &Builder, + builder: &Builder<'_>, compiler: Compiler, mode: Mode, target: Interned, @@ -316,18 +315,18 @@ macro_rules! tool { impl Step for $name { type Output = PathBuf; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path($path) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure($name { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, }); } - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { builder.ensure(ToolBuild { compiler: self.compiler, target: self.target, @@ -372,18 +371,18 @@ pub struct RemoteTestServer { impl Step for RemoteTestServer { type Output = PathBuf; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/remote-test-server") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(RemoteTestServer { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, }); } - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { builder.ensure(ToolBuild { compiler: self.compiler, target: self.target, @@ -407,37 +406,37 @@ impl Step for Rustdoc { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { run.path("src/tools/rustdoc") } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Rustdoc { host: run.host, }); } - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { let target_compiler = builder.compiler(builder.top_stage, self.host); + if target_compiler.stage == 0 { + if !target_compiler.is_snapshot(builder) { + panic!("rustdoc in stage 0 must be snapshot rustdoc"); + } + return builder.initial_rustc.with_file_name(exe("rustdoc", &target_compiler.host)); + } let target = target_compiler.host; - let build_compiler = if target_compiler.stage == 0 { - builder.compiler(0, builder.config.build) - } else if target_compiler.stage >= 2 { - // Past stage 2, we consider the compiler to be ABI-compatible and hence capable of - // building rustdoc itself. - builder.compiler(target_compiler.stage, builder.config.build) - } else { - // Similar to `compile::Assemble`, build with the previous stage's compiler. Otherwise - // we'd have stageN/bin/rustc and stageN/bin/rustdoc be effectively different stage - // compilers, which isn't what we want. - builder.compiler(target_compiler.stage - 1, builder.config.build) - }; - - builder.ensure(compile::Rustc { compiler: build_compiler, target }); - builder.ensure(compile::Rustc { - compiler: build_compiler, - target: builder.config.build, - }); + // Similar to `compile::Assemble`, build with the previous stage's compiler. Otherwise + // we'd have stageN/bin/rustc and stageN/bin/rustdoc be effectively different stage + // compilers, which isn't what we want. Rustdoc should be linked in the same way as the + // rustc compiler it's paired with, so it must be built with the previous stage compiler. + let build_compiler = builder.compiler(target_compiler.stage - 1, builder.config.build); + + // The presence of `target_compiler` ensures that the necessary libraries (codegen backends, + // compiler libraries, ...) are built. Rustdoc does not require the presence of any + // libraries within sysroot_libdir (i.e., rustlib), though doctests may want it (since + // they'll be linked to those libraries). As such, don't explicitly `ensure` any additional + // libraries here. The intuition here is that If we've built a compiler, we should be able + // to build rustdoc. let mut cargo = prepare_tool_cargo( builder, @@ -491,19 +490,19 @@ impl Step for Cargo { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path("src/tools/cargo").default_condition(builder.config.extended) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure(Cargo { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, }); } - fn run(self, builder: &Builder) -> PathBuf { + fn run(self, builder: &Builder<'_>) -> PathBuf { // Cargo depends on procedural macros, which requires a full host // compiler to be available, so we need to depend on that. builder.ensure(compile::Rustc { @@ -543,12 +542,12 @@ macro_rules! tool_extended { const DEFAULT: bool = true; const ONLY_HOSTS: bool = true; - fn should_run(run: ShouldRun) -> ShouldRun { + fn should_run(run: ShouldRun<'_>) -> ShouldRun<'_> { let builder = run.builder; run.path($path).default_condition(builder.config.extended) } - fn make_run(run: RunConfig) { + fn make_run(run: RunConfig<'_>) { run.builder.ensure($name { compiler: run.builder.compiler(run.builder.top_stage, run.builder.config.build), target: run.target, @@ -557,7 +556,7 @@ macro_rules! tool_extended { } #[allow(unused_mut)] - fn run(mut $sel, $builder: &Builder) -> Option { + fn run(mut $sel, $builder: &Builder<'_>) -> Option { $extra_deps $builder.ensure(ToolBuild { compiler: $sel.compiler, @@ -622,7 +621,7 @@ tool_extended!((self, builder), ); impl<'a> Builder<'a> { - /// Get a `Command` which is ready to run `tool` in `stage` built for + /// Gets a `Command` which is ready to run `tool` in `stage` built for /// `host`. pub fn tool_cmd(&self, tool: Tool) -> Command { let mut cmd = Command::new(self.tool_exe(tool)); @@ -666,19 +665,33 @@ impl<'a> Builder<'a> { // Add the llvm/bin directory to PATH since it contains lots of // useful, platform-independent tools - if tool.uses_llvm_tools() { + if tool.uses_llvm_tools() && !self.config.dry_run { + let mut additional_paths = vec![]; + if let Some(llvm_bin_path) = self.llvm_bin_path() { - if host.contains("windows") { - // On Windows, PATH and the dynamic library path are the same, - // so we just add the LLVM bin path to lib_path - lib_paths.push(llvm_bin_path); - } else { - let old_path = env::var_os("PATH").unwrap_or_default(); - let new_path = env::join_paths(iter::once(llvm_bin_path) - .chain(env::split_paths(&old_path))) - .expect("Could not add LLVM bin path to PATH"); - cmd.env("PATH", new_path); - } + additional_paths.push(llvm_bin_path); + } + + // If LLD is available, add that too. + if self.config.lld_enabled { + let lld_install_root = self.ensure(native::Lld { + target: self.config.build, + }); + + let lld_bin_path = lld_install_root.join("bin"); + additional_paths.push(lld_bin_path); + } + + if host.contains("windows") { + // On Windows, PATH and the dynamic library path are the same, + // so we just add the LLVM bin path to lib_path + lib_paths.extend(additional_paths); + } else { + let old_path = env::var_os("PATH").unwrap_or_default(); + let new_path = env::join_paths(additional_paths.into_iter() + .chain(env::split_paths(&old_path))) + .expect("Could not add LLVM bin path to PATH"); + cmd.env("PATH", new_path); } } @@ -686,7 +699,7 @@ impl<'a> Builder<'a> { } fn llvm_bin_path(&self) -> Option { - if self.config.llvm_enabled && !self.config.dry_run { + if self.config.llvm_enabled { let llvm_config = self.ensure(native::Llvm { target: self.config.build, emscripten: false, diff --git a/src/bootstrap/util.rs b/src/bootstrap/util.rs index 2880f1a084..bda1e56e1e 100644 --- a/src/bootstrap/util.rs +++ b/src/bootstrap/util.rs @@ -33,7 +33,7 @@ pub fn exe(name: &str, target: &str) -> String { } } -/// Returns whether the file name given looks like a dynamic library. +/// Returns `true` if the file name given looks like a dynamic library. pub fn is_dylib(name: &str) -> bool { name.ends_with(".dylib") || name.ends_with(".so") || name.ends_with(".dll") } @@ -70,7 +70,11 @@ pub fn dylib_path_var() -> &'static str { /// Parses the `dylib_path_var()` environment variable, returning a list of /// paths that are members of this lookup path. pub fn dylib_path() -> Vec { - env::split_paths(&env::var_os(dylib_path_var()).unwrap_or_default()).collect() + let var = match env::var_os(dylib_path_var()) { + Some(v) => v, + None => return vec![], + }; + env::split_paths(&var).collect() } /// `push` all components to `buf`. On windows, append `.exe` to the last component. @@ -91,7 +95,7 @@ pub fn push_exe_path(mut buf: PathBuf, components: &[&str]) -> PathBuf { pub struct TimeIt(bool, Instant); /// Returns an RAII structure that prints out how long it took to drop. -pub fn timeit(builder: &Builder) -> TimeIt { +pub fn timeit(builder: &Builder<'_>) -> TimeIt { TimeIt(builder.config.dry_run, Instant::now()) } diff --git a/src/build_helper/Cargo.toml b/src/build_helper/Cargo.toml index 01d704f816..04c7820b45 100644 --- a/src/build_helper/Cargo.toml +++ b/src/build_helper/Cargo.toml @@ -2,6 +2,7 @@ name = "build_helper" version = "0.1.0" authors = ["The Rust Project Developers"] +edition = "2018" [lib] name = "build_helper" diff --git a/src/build_helper/lib.rs b/src/build_helper/lib.rs index 5a704e5577..bd99dc118e 100644 --- a/src/build_helper/lib.rs +++ b/src/build_helper/lib.rs @@ -1,3 +1,5 @@ +#![deny(rust_2018_idioms)] + use std::fs::File; use std::path::{Path, PathBuf}; use std::process::{Command, Stdio}; @@ -23,6 +25,25 @@ macro_rules! t { }; } +// Because Cargo adds the compiler's dylib path to our library search path, llvm-config may +// break: the dylib path for the compiler, as of this writing, contains a copy of the LLVM +// shared library, which means that when our freshly built llvm-config goes to load it's +// associated LLVM, it actually loads the compiler's LLVM. In particular when building the first +// compiler (i.e., in stage 0) that's a problem, as the compiler's LLVM is likely different from +// the one we want to use. As such, we restore the environment to what bootstrap saw. This isn't +// perfect -- we might actually want to see something from Cargo's added library paths -- but +// for now it works. +pub fn restore_library_path() { + println!("cargo:rerun-if-env-changed=REAL_LIBRARY_PATH_VAR"); + println!("cargo:rerun-if-env-changed=REAL_LIBRARY_PATH"); + let key = env::var_os("REAL_LIBRARY_PATH_VAR").expect("REAL_LIBRARY_PATH_VAR"); + if let Some(env) = env::var_os("REAL_LIBRARY_PATH") { + env::set_var(&key, &env); + } else { + env::remove_var(&key); + } +} + pub fn run(cmd: &mut Command) { println!("running: {:?}", cmd); run_silent(cmd); @@ -142,7 +163,7 @@ pub fn mtime(path: &Path) -> SystemTime { .unwrap_or(UNIX_EPOCH) } -/// Returns whether `dst` is up to date given that the file or files in `src` +/// Returns `true` if `dst` is up to date given that the file or files in `src` /// are used to generate it. /// /// Uses last-modified time checks to verify this. @@ -169,12 +190,12 @@ pub struct NativeLibBoilerplate { } impl NativeLibBoilerplate { - /// On OSX we don't want to ship the exact filename that compiler-rt builds. + /// On macOS we don't want to ship the exact filename that compiler-rt builds. /// This conflicts with the system and ours is likely a wildly different /// version, so they can't be substituted. /// /// As a result, we rename it here but we need to also use - /// `install_name_tool` on OSX to rename the commands listed inside of it to + /// `install_name_tool` on macOS to rename the commands listed inside of it to /// ensure it's linked against correctly. pub fn fixup_sanitizer_lib_name(&self, sanitizer_name: &str) { if env::var("TARGET").unwrap() != "x86_64-apple-darwin" { diff --git a/src/ci/docker/README.md b/src/ci/docker/README.md index 8d4dbc3999..34320ab441 100644 --- a/src/ci/docker/README.md +++ b/src/ci/docker/README.md @@ -131,13 +131,15 @@ $category > $option = $value -- $comment For targets: `arm-unknown-linux-gnueabi` - Path and misc options > Prefix directory = /x-tools/${CT\_TARGET} +- Path and misc options > Patches origin = Bundled, then local +- Path and misc options > Local patch directory = /tmp/patches - Target options > Target Architecture = arm - Target options > Architecture level = armv6 -- (+) - Target options > Floating point = software (no FPU) -- (\*) - Operating System > Target OS = linux - Operating System > Linux kernel version = 3.2.72 -- Precise kernel -- C-library > glibc version = 2.14.1 -- C compiler > gcc version = 4.9.3 +- C-library > glibc version = 2.16.0 +- C compiler > gcc version = 5.2.0 - C compiler > C++ = ENABLE -- to cross compile LLVM ### `arm-linux-gnueabihf.config` @@ -145,6 +147,8 @@ For targets: `arm-unknown-linux-gnueabi` For targets: `arm-unknown-linux-gnueabihf` - Path and misc options > Prefix directory = /x-tools/${CT\_TARGET} +- Path and misc options > Patches origin = Bundled, then local +- Path and misc options > Local patch directory = /tmp/patches - Target options > Target Architecture = arm - Target options > Architecture level = armv6 -- (+) - Target options > Use specific FPU = vfp -- (+) @@ -152,8 +156,8 @@ For targets: `arm-unknown-linux-gnueabihf` - Target options > Default instruction set mode = arm -- (+) - Operating System > Target OS = linux - Operating System > Linux kernel version = 3.2.72 -- Precise kernel -- C-library > glibc version = 2.14.1 -- C compiler > gcc version = 4.9.3 +- C-library > glibc version = 2.16.0 +- C compiler > gcc version = 5.2.0 - C compiler > C++ = ENABLE -- to cross compile LLVM ### `armv7-linux-gnueabihf.config` @@ -161,6 +165,8 @@ For targets: `arm-unknown-linux-gnueabihf` For targets: `armv7-unknown-linux-gnueabihf` - Path and misc options > Prefix directory = /x-tools/${CT\_TARGET} +- Path and misc options > Patches origin = Bundled, then local +- Path and misc options > Local patch directory = /tmp/patches - Target options > Target Architecture = arm - Target options > Suffix to the arch-part = v7 - Target options > Architecture level = armv7-a -- (+) @@ -169,8 +175,8 @@ For targets: `armv7-unknown-linux-gnueabihf` - Target options > Default instruction set mode = thumb -- (\*) - Operating System > Target OS = linux - Operating System > Linux kernel version = 3.2.72 -- Precise kernel -- C-library > glibc version = 2.14.1 -- C compiler > gcc version = 4.9.3 +- C-library > glibc version = 2.16.0 +- C compiler > gcc version = 5.2.0 - C compiler > C++ = ENABLE -- to cross compile LLVM (\*) These options have been selected to match the configuration of the arm @@ -204,7 +210,7 @@ For targets: `powerpc-unknown-linux-gnu` - Operating System > Target OS = linux - Operating System > Linux kernel version = 2.6.32.68 -- ~RHEL6 kernel - C-library > glibc version = 2.12.2 -- ~RHEL6 glibc -- C compiler > gcc version = 4.9.3 +- C compiler > gcc version = 5.2.0 - C compiler > C++ = ENABLE -- to cross compile LLVM ### `powerpc64-linux-gnu.config` @@ -221,7 +227,7 @@ For targets: `powerpc64-unknown-linux-gnu` - Operating System > Target OS = linux - Operating System > Linux kernel version = 2.6.32.68 -- ~RHEL6 kernel - C-library > glibc version = 2.12.2 -- ~RHEL6 glibc -- C compiler > gcc version = 4.9.3 +- C compiler > gcc version = 5.2.0 - C compiler > C++ = ENABLE -- to cross compile LLVM (+) These CPU options match the configuration of the toolchains in RHEL6. @@ -232,12 +238,12 @@ For targets: `s390x-unknown-linux-gnu` - Path and misc options > Prefix directory = /x-tools/${CT\_TARGET} - Path and misc options > Patches origin = Bundled, then local -- Path and misc options > Local patch directory = /build/patches +- Path and misc options > Local patch directory = /tmp/patches - Target options > Target Architecture = s390 - Target options > Bitness = 64-bit - Operating System > Target OS = linux - Operating System > Linux kernel version = 2.6.32.68 -- ~RHEL6 kernel - C-library > glibc version = 2.12.2 -- ~RHEL6 glibc -- C compiler > gcc version = 4.9.3 +- C compiler > gcc version = 5.2.0 - C compiler > gcc extra config = --with-arch=z10 -- LLVM's minimum support - C compiler > C++ = ENABLE -- to cross compile LLVM diff --git a/src/ci/docker/arm-android/Dockerfile b/src/ci/docker/arm-android/Dockerfile index e10ccd56a4..bbf700ae23 100644 --- a/src/ci/docker/arm-android/Dockerfile +++ b/src/ci/docker/arm-android/Dockerfile @@ -23,7 +23,7 @@ RUN dpkg --add-architecture i386 && \ COPY scripts/android-sdk.sh /scripts/ RUN . /scripts/android-sdk.sh && \ - download_and_create_avd 4333796 armeabi-v7a 18 + download_and_create_avd 4333796 armeabi-v7a 18 5264690 ENV PATH=$PATH:/android/sdk/emulator ENV PATH=$PATH:/android/sdk/tools diff --git a/src/ci/docker/armhf-gnu/Dockerfile b/src/ci/docker/armhf-gnu/Dockerfile index 2b7624d53e..e4c2097f97 100644 --- a/src/ci/docker/armhf-gnu/Dockerfile +++ b/src/ci/docker/armhf-gnu/Dockerfile @@ -71,7 +71,8 @@ COPY scripts/qemu-bare-bones-addentropy.c /tmp/addentropy.c RUN arm-linux-gnueabihf-gcc addentropy.c -o rootfs/addentropy -static # TODO: What is this?! -RUN curl -O http://ftp.nl.debian.org/debian/dists/jessie/main/installer-armhf/current/images/device-tree/vexpress-v2p-ca15-tc1.dtb +# Source of the file: https://github.com/vfdev-5/qemu-rpi2-vexpress/raw/master/vexpress-v2p-ca15-tc1.dtb +RUN curl -O https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/vexpress-v2p-ca15-tc1.dtb COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh diff --git a/src/ci/docker/disabled/dist-x86_64-redox/Dockerfile b/src/ci/docker/disabled/dist-x86_64-redox/Dockerfile index f4c25f791b..11a3acd68e 100644 --- a/src/ci/docker/disabled/dist-x86_64-redox/Dockerfile +++ b/src/ci/docker/disabled/dist-x86_64-redox/Dockerfile @@ -7,8 +7,8 @@ COPY scripts/crosstool-ng.sh /scripts/ RUN sh /scripts/crosstool-ng.sh WORKDIR /tmp -COPY cross/install-x86_64-redox.sh /tmp/ -RUN ./install-x86_64-redox.sh +COPY dist-various-1/install-x86_64-redox.sh /scripts/ +RUN sh /scripts/install-x86_64-redox.sh COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh diff --git a/src/ci/docker/dist-arm-linux/Dockerfile b/src/ci/docker/dist-arm-linux/Dockerfile index 6ddc5c1e04..48851ae232 100644 --- a/src/ci/docker/dist-arm-linux/Dockerfile +++ b/src/ci/docker/dist-arm-linux/Dockerfile @@ -16,6 +16,7 @@ RUN sh /scripts/rustbuild-setup.sh USER rustbuild WORKDIR /tmp +COPY dist-arm-linux/patches/ /tmp/patches/ COPY dist-arm-linux/arm-linux-gnueabi.config dist-arm-linux/build-toolchains.sh /tmp/ RUN ./build-toolchains.sh diff --git a/src/ci/docker/dist-arm-linux/arm-linux-gnueabi.config b/src/ci/docker/dist-arm-linux/arm-linux-gnueabi.config index f73ad06955..4185112d8b 100644 --- a/src/ci/docker/dist-arm-linux/arm-linux-gnueabi.config +++ b/src/ci/docker/dist-arm-linux/arm-linux-gnueabi.config @@ -3,6 +3,7 @@ # Crosstool-NG Configuration # CT_CONFIGURE_has_make381=y +CT_CONFIGURE_has_xz=y CT_MODULES=y # @@ -44,14 +45,16 @@ CT_CONNECT_TIMEOUT=10 # CT_FORCE_EXTRACT is not set CT_OVERIDE_CONFIG_GUESS_SUB=y # CT_ONLY_EXTRACT is not set -CT_PATCH_BUNDLED=y +# CT_PATCH_BUNDLED is not set # CT_PATCH_LOCAL is not set -# CT_PATCH_BUNDLED_LOCAL is not set +CT_PATCH_BUNDLED_LOCAL=y # CT_PATCH_LOCAL_BUNDLED is not set # CT_PATCH_BUNDLED_FALLBACK_LOCAL is not set # CT_PATCH_LOCAL_FALLBACK_BUNDLED is not set # CT_PATCH_NONE is not set -CT_PATCH_ORDER="bundled" +CT_PATCH_ORDER="bundled,local" +CT_PATCH_USE_LOCAL=y +CT_LOCAL_PATCH_DIR="/tmp/patches" # # Build behavior @@ -391,8 +394,8 @@ CT_CC_CORE_PASS_1_NEEDED=y CT_CC_CORE_PASS_2_NEEDED=y CT_CC_gcc=y # CT_CC_GCC_SHOW_LINARO is not set -# CT_CC_GCC_V_5_2_0 is not set -CT_CC_GCC_V_4_9_3=y +CT_CC_GCC_V_5_2_0=y +# CT_CC_GCC_V_4_9_3 is not set # CT_CC_GCC_V_4_8_5 is not set # CT_CC_GCC_V_4_7_4 is not set # CT_CC_GCC_V_4_6_4 is not set @@ -407,8 +410,9 @@ CT_CC_GCC_4_5_or_later=y CT_CC_GCC_4_6_or_later=y CT_CC_GCC_4_7_or_later=y CT_CC_GCC_4_8_or_later=y -CT_CC_GCC_4_9=y CT_CC_GCC_4_9_or_later=y +CT_CC_GCC_5=y +CT_CC_GCC_5_or_later=y CT_CC_GCC_HAS_GRAPHITE=y CT_CC_GCC_USE_GRAPHITE=y CT_CC_GCC_HAS_LTO=y @@ -420,7 +424,7 @@ CT_CC_GCC_USE_GMP_MPFR=y CT_CC_GCC_USE_MPC=y CT_CC_GCC_HAS_LIBQUADMATH=y CT_CC_GCC_HAS_LIBSANITIZER=y -CT_CC_GCC_VERSION="4.9.3" +CT_CC_GCC_VERSION="5.2.0" # CT_CC_LANG_FORTRAN is not set CT_CC_GCC_ENABLE_CXX_FLAGS="" CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="" @@ -492,7 +496,6 @@ CT_GETTEXT_NEEDED=y CT_GMP_NEEDED=y CT_MPFR_NEEDED=y CT_ISL_NEEDED=y -CT_CLOOG_NEEDED=y CT_MPC_NEEDED=y CT_COMPLIBS=y CT_LIBICONV=y @@ -500,7 +503,6 @@ CT_GETTEXT=y CT_GMP=y CT_MPFR=y CT_ISL=y -CT_CLOOG=y CT_MPC=y CT_LIBICONV_V_1_14=y CT_LIBICONV_VERSION="1.14" @@ -526,15 +528,13 @@ CT_MPFR_V_3_1_3=y # CT_MPFR_V_2_4_0 is not set CT_MPFR_VERSION="3.1.3" CT_ISL_V_0_14=y +# CT_ISL_V_0_12_2 is not set CT_ISL_V_0_14_or_later=y CT_ISL_V_0_12_or_later=y CT_ISL_VERSION="0.14" -CT_CLOOG_V_0_18_4=y +# CT_CLOOG_V_0_18_4 is not set # CT_CLOOG_V_0_18_1 is not set # CT_CLOOG_V_0_18_0 is not set -CT_CLOOG_VERSION="0.18.4" -CT_CLOOG_0_18_4_or_later=y -CT_CLOOG_0_18_or_later=y CT_MPC_V_1_0_3=y # CT_MPC_V_1_0_2 is not set # CT_MPC_V_1_0_1 is not set diff --git a/src/ci/docker/dist-arm-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch b/src/ci/docker/dist-arm-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch new file mode 100644 index 0000000000..871d5225c0 --- /dev/null +++ b/src/ci/docker/dist-arm-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch @@ -0,0 +1,48 @@ +commit bdb24c2851fd5f0ad9b82d7ea1db911d334b02d2 +Author: Joseph Myers +Date: Tue May 20 21:27:13 2014 +0000 + + Fix ARM build with GCC trunk. + + sysdeps/unix/sysv/linux/arm/unwind-resume.c and + sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c have static + variables that are written in C code but only read from toplevel asms. + Current GCC trunk now optimizes away such apparently write-only static + variables, so causing a build failure. This patch marks those + variables with __attribute_used__ to avoid that optimization. + + Tested that this fixes the build for ARM. + + * sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c + (libgcc_s_resume): Use __attribute_used__. + * sysdeps/unix/sysv/linux/arm/unwind-resume.c (libgcc_s_resume): + Likewise. + +diff --git a/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c b/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c +index 29e2c2b00b04..e848bfeffdcb 100644 +--- a/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c ++++ b/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c +@@ -22,7 +22,8 @@ + #include + + static void *libgcc_s_handle; +-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc); ++static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) ++ __attribute_used__; + static _Unwind_Reason_Code (*libgcc_s_personality) + (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *); + static _Unwind_Reason_Code (*libgcc_s_forcedunwind) +diff --git a/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c b/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c +index 285b99b5ed0d..48d00fc83641 100644 +--- a/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c ++++ b/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c +@@ -20,7 +20,8 @@ + #include + #include + +-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc); ++static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) ++ __attribute_used__; + static _Unwind_Reason_Code (*libgcc_s_personality) + (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *); + diff --git a/src/ci/docker/dist-armhf-linux/Dockerfile b/src/ci/docker/dist-armhf-linux/Dockerfile index e4d4b2feee..d1dd9faaa1 100644 --- a/src/ci/docker/dist-armhf-linux/Dockerfile +++ b/src/ci/docker/dist-armhf-linux/Dockerfile @@ -16,6 +16,7 @@ RUN sh /scripts/rustbuild-setup.sh USER rustbuild WORKDIR /tmp +COPY dist-armhf-linux/patches/ /tmp/patches/ COPY dist-armhf-linux/arm-linux-gnueabihf.config dist-armhf-linux/build-toolchains.sh /tmp/ RUN ./build-toolchains.sh diff --git a/src/ci/docker/dist-armhf-linux/arm-linux-gnueabihf.config b/src/ci/docker/dist-armhf-linux/arm-linux-gnueabihf.config index 1feeef1555..bebbcd1670 100644 --- a/src/ci/docker/dist-armhf-linux/arm-linux-gnueabihf.config +++ b/src/ci/docker/dist-armhf-linux/arm-linux-gnueabihf.config @@ -3,6 +3,7 @@ # Crosstool-NG Configuration # CT_CONFIGURE_has_make381=y +CT_CONFIGURE_has_xz=y CT_MODULES=y # @@ -44,14 +45,16 @@ CT_CONNECT_TIMEOUT=10 # CT_FORCE_EXTRACT is not set CT_OVERIDE_CONFIG_GUESS_SUB=y # CT_ONLY_EXTRACT is not set -CT_PATCH_BUNDLED=y +# CT_PATCH_BUNDLED is not set # CT_PATCH_LOCAL is not set -# CT_PATCH_BUNDLED_LOCAL is not set +CT_PATCH_BUNDLED_LOCAL=y # CT_PATCH_LOCAL_BUNDLED is not set # CT_PATCH_BUNDLED_FALLBACK_LOCAL is not set # CT_PATCH_LOCAL_FALLBACK_BUNDLED is not set # CT_PATCH_NONE is not set -CT_PATCH_ORDER="bundled" +CT_PATCH_ORDER="bundled,local" +CT_PATCH_USE_LOCAL=y +CT_LOCAL_PATCH_DIR="/tmp/patches" # # Build behavior @@ -392,8 +395,8 @@ CT_CC_CORE_PASS_1_NEEDED=y CT_CC_CORE_PASS_2_NEEDED=y CT_CC_gcc=y # CT_CC_GCC_SHOW_LINARO is not set -# CT_CC_GCC_V_5_2_0 is not set -CT_CC_GCC_V_4_9_3=y +CT_CC_GCC_V_5_2_0=y +# CT_CC_GCC_V_4_9_3 is not set # CT_CC_GCC_V_4_8_5 is not set # CT_CC_GCC_V_4_7_4 is not set # CT_CC_GCC_V_4_6_4 is not set @@ -408,8 +411,9 @@ CT_CC_GCC_4_5_or_later=y CT_CC_GCC_4_6_or_later=y CT_CC_GCC_4_7_or_later=y CT_CC_GCC_4_8_or_later=y -CT_CC_GCC_4_9=y CT_CC_GCC_4_9_or_later=y +CT_CC_GCC_5=y +CT_CC_GCC_5_or_later=y CT_CC_GCC_HAS_GRAPHITE=y CT_CC_GCC_USE_GRAPHITE=y CT_CC_GCC_HAS_LTO=y @@ -421,7 +425,7 @@ CT_CC_GCC_USE_GMP_MPFR=y CT_CC_GCC_USE_MPC=y CT_CC_GCC_HAS_LIBQUADMATH=y CT_CC_GCC_HAS_LIBSANITIZER=y -CT_CC_GCC_VERSION="4.9.3" +CT_CC_GCC_VERSION="5.2.0" # CT_CC_LANG_FORTRAN is not set CT_CC_GCC_ENABLE_CXX_FLAGS="" CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="" @@ -493,7 +497,6 @@ CT_GETTEXT_NEEDED=y CT_GMP_NEEDED=y CT_MPFR_NEEDED=y CT_ISL_NEEDED=y -CT_CLOOG_NEEDED=y CT_MPC_NEEDED=y CT_COMPLIBS=y CT_LIBICONV=y @@ -501,7 +504,6 @@ CT_GETTEXT=y CT_GMP=y CT_MPFR=y CT_ISL=y -CT_CLOOG=y CT_MPC=y CT_LIBICONV_V_1_14=y CT_LIBICONV_VERSION="1.14" @@ -527,15 +529,13 @@ CT_MPFR_V_3_1_3=y # CT_MPFR_V_2_4_0 is not set CT_MPFR_VERSION="3.1.3" CT_ISL_V_0_14=y +# CT_ISL_V_0_12_2 is not set CT_ISL_V_0_14_or_later=y CT_ISL_V_0_12_or_later=y CT_ISL_VERSION="0.14" -CT_CLOOG_V_0_18_4=y +# CT_CLOOG_V_0_18_4 is not set # CT_CLOOG_V_0_18_1 is not set # CT_CLOOG_V_0_18_0 is not set -CT_CLOOG_VERSION="0.18.4" -CT_CLOOG_0_18_4_or_later=y -CT_CLOOG_0_18_or_later=y CT_MPC_V_1_0_3=y # CT_MPC_V_1_0_2 is not set # CT_MPC_V_1_0_1 is not set diff --git a/src/ci/docker/dist-armhf-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch b/src/ci/docker/dist-armhf-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch new file mode 100644 index 0000000000..871d5225c0 --- /dev/null +++ b/src/ci/docker/dist-armhf-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch @@ -0,0 +1,48 @@ +commit bdb24c2851fd5f0ad9b82d7ea1db911d334b02d2 +Author: Joseph Myers +Date: Tue May 20 21:27:13 2014 +0000 + + Fix ARM build with GCC trunk. + + sysdeps/unix/sysv/linux/arm/unwind-resume.c and + sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c have static + variables that are written in C code but only read from toplevel asms. + Current GCC trunk now optimizes away such apparently write-only static + variables, so causing a build failure. This patch marks those + variables with __attribute_used__ to avoid that optimization. + + Tested that this fixes the build for ARM. + + * sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c + (libgcc_s_resume): Use __attribute_used__. + * sysdeps/unix/sysv/linux/arm/unwind-resume.c (libgcc_s_resume): + Likewise. + +diff --git a/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c b/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c +index 29e2c2b00b04..e848bfeffdcb 100644 +--- a/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c ++++ b/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c +@@ -22,7 +22,8 @@ + #include + + static void *libgcc_s_handle; +-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc); ++static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) ++ __attribute_used__; + static _Unwind_Reason_Code (*libgcc_s_personality) + (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *); + static _Unwind_Reason_Code (*libgcc_s_forcedunwind) +diff --git a/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c b/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c +index 285b99b5ed0d..48d00fc83641 100644 +--- a/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c ++++ b/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c +@@ -20,7 +20,8 @@ + #include + #include + +-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc); ++static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) ++ __attribute_used__; + static _Unwind_Reason_Code (*libgcc_s_personality) + (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *); + diff --git a/src/ci/docker/dist-armv7-linux/Dockerfile b/src/ci/docker/dist-armv7-linux/Dockerfile index 99fe7bd7b8..170b8134d3 100644 --- a/src/ci/docker/dist-armv7-linux/Dockerfile +++ b/src/ci/docker/dist-armv7-linux/Dockerfile @@ -16,6 +16,7 @@ RUN sh /scripts/rustbuild-setup.sh USER rustbuild WORKDIR /tmp +COPY dist-armv7-linux/patches/ /tmp/patches/ COPY dist-armv7-linux/build-toolchains.sh dist-armv7-linux/armv7-linux-gnueabihf.config /tmp/ RUN ./build-toolchains.sh diff --git a/src/ci/docker/dist-armv7-linux/armv7-linux-gnueabihf.config b/src/ci/docker/dist-armv7-linux/armv7-linux-gnueabihf.config index 79d6c77c41..5cccfd8444 100644 --- a/src/ci/docker/dist-armv7-linux/armv7-linux-gnueabihf.config +++ b/src/ci/docker/dist-armv7-linux/armv7-linux-gnueabihf.config @@ -3,6 +3,7 @@ # Crosstool-NG Configuration # CT_CONFIGURE_has_make381=y +CT_CONFIGURE_has_xz=y CT_MODULES=y # @@ -44,14 +45,16 @@ CT_CONNECT_TIMEOUT=10 # CT_FORCE_EXTRACT is not set CT_OVERIDE_CONFIG_GUESS_SUB=y # CT_ONLY_EXTRACT is not set -CT_PATCH_BUNDLED=y +# CT_PATCH_BUNDLED is not set # CT_PATCH_LOCAL is not set -# CT_PATCH_BUNDLED_LOCAL is not set +CT_PATCH_BUNDLED_LOCAL=y # CT_PATCH_LOCAL_BUNDLED is not set # CT_PATCH_BUNDLED_FALLBACK_LOCAL is not set # CT_PATCH_LOCAL_FALLBACK_BUNDLED is not set # CT_PATCH_NONE is not set -CT_PATCH_ORDER="bundled" +CT_PATCH_ORDER="bundled,local" +CT_PATCH_USE_LOCAL=y +CT_LOCAL_PATCH_DIR="/tmp/patches" # # Build behavior @@ -155,12 +158,6 @@ CT_ARCH_EXCLUSIVE_WITH_CPU=y # CT_ARCH_FLOAT_AUTO is not set # CT_ARCH_FLOAT_SOFTFP is not set CT_ARCH_FLOAT="hard" -# CT_ARCH_ALPHA_EV4 is not set -# CT_ARCH_ALPHA_EV45 is not set -# CT_ARCH_ALPHA_EV5 is not set -# CT_ARCH_ALPHA_EV56 is not set -# CT_ARCH_ALPHA_EV6 is not set -# CT_ARCH_ALPHA_EV67 is not set # # arm other options @@ -311,8 +308,6 @@ CT_LIBC="glibc" CT_LIBC_VERSION="2.16.0" CT_LIBC_glibc=y # CT_LIBC_musl is not set -# CT_LIBC_newlib is not set -# CT_LIBC_none is not set # CT_LIBC_uClibc is not set CT_LIBC_avr_libc_AVAILABLE=y CT_LIBC_glibc_AVAILABLE=y @@ -400,8 +395,8 @@ CT_CC_CORE_PASS_1_NEEDED=y CT_CC_CORE_PASS_2_NEEDED=y CT_CC_gcc=y # CT_CC_GCC_SHOW_LINARO is not set -# CT_CC_GCC_V_5_2_0 is not set -CT_CC_GCC_V_4_9_3=y +CT_CC_GCC_V_5_2_0=y +# CT_CC_GCC_V_4_9_3 is not set # CT_CC_GCC_V_4_8_5 is not set # CT_CC_GCC_V_4_7_4 is not set # CT_CC_GCC_V_4_6_4 is not set @@ -416,8 +411,9 @@ CT_CC_GCC_4_5_or_later=y CT_CC_GCC_4_6_or_later=y CT_CC_GCC_4_7_or_later=y CT_CC_GCC_4_8_or_later=y -CT_CC_GCC_4_9=y CT_CC_GCC_4_9_or_later=y +CT_CC_GCC_5=y +CT_CC_GCC_5_or_later=y CT_CC_GCC_HAS_GRAPHITE=y CT_CC_GCC_USE_GRAPHITE=y CT_CC_GCC_HAS_LTO=y @@ -429,7 +425,7 @@ CT_CC_GCC_USE_GMP_MPFR=y CT_CC_GCC_USE_MPC=y CT_CC_GCC_HAS_LIBQUADMATH=y CT_CC_GCC_HAS_LIBSANITIZER=y -CT_CC_GCC_VERSION="4.9.3" +CT_CC_GCC_VERSION="5.2.0" # CT_CC_LANG_FORTRAN is not set CT_CC_GCC_ENABLE_CXX_FLAGS="" CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="" @@ -501,7 +497,6 @@ CT_GETTEXT_NEEDED=y CT_GMP_NEEDED=y CT_MPFR_NEEDED=y CT_ISL_NEEDED=y -CT_CLOOG_NEEDED=y CT_MPC_NEEDED=y CT_COMPLIBS=y CT_LIBICONV=y @@ -509,7 +504,6 @@ CT_GETTEXT=y CT_GMP=y CT_MPFR=y CT_ISL=y -CT_CLOOG=y CT_MPC=y CT_LIBICONV_V_1_14=y CT_LIBICONV_VERSION="1.14" @@ -535,15 +529,13 @@ CT_MPFR_V_3_1_3=y # CT_MPFR_V_2_4_0 is not set CT_MPFR_VERSION="3.1.3" CT_ISL_V_0_14=y +# CT_ISL_V_0_12_2 is not set CT_ISL_V_0_14_or_later=y CT_ISL_V_0_12_or_later=y CT_ISL_VERSION="0.14" -CT_CLOOG_V_0_18_4=y +# CT_CLOOG_V_0_18_4 is not set # CT_CLOOG_V_0_18_1 is not set # CT_CLOOG_V_0_18_0 is not set -CT_CLOOG_VERSION="0.18.4" -CT_CLOOG_0_18_4_or_later=y -CT_CLOOG_0_18_or_later=y CT_MPC_V_1_0_3=y # CT_MPC_V_1_0_2 is not set # CT_MPC_V_1_0_1 is not set diff --git a/src/ci/docker/dist-armv7-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch b/src/ci/docker/dist-armv7-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch new file mode 100644 index 0000000000..871d5225c0 --- /dev/null +++ b/src/ci/docker/dist-armv7-linux/patches/glibc/ports-2.16.0/001-arm-libgcc_s_resume-used.patch @@ -0,0 +1,48 @@ +commit bdb24c2851fd5f0ad9b82d7ea1db911d334b02d2 +Author: Joseph Myers +Date: Tue May 20 21:27:13 2014 +0000 + + Fix ARM build with GCC trunk. + + sysdeps/unix/sysv/linux/arm/unwind-resume.c and + sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c have static + variables that are written in C code but only read from toplevel asms. + Current GCC trunk now optimizes away such apparently write-only static + variables, so causing a build failure. This patch marks those + variables with __attribute_used__ to avoid that optimization. + + Tested that this fixes the build for ARM. + + * sysdeps/unix/sysv/linux/arm/unwind-forcedunwind.c + (libgcc_s_resume): Use __attribute_used__. + * sysdeps/unix/sysv/linux/arm/unwind-resume.c (libgcc_s_resume): + Likewise. + +diff --git a/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c b/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c +index 29e2c2b00b04..e848bfeffdcb 100644 +--- a/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c ++++ b/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-forcedunwind.c +@@ -22,7 +22,8 @@ + #include + + static void *libgcc_s_handle; +-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc); ++static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) ++ __attribute_used__; + static _Unwind_Reason_Code (*libgcc_s_personality) + (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *); + static _Unwind_Reason_Code (*libgcc_s_forcedunwind) +diff --git a/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c b/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c +index 285b99b5ed0d..48d00fc83641 100644 +--- a/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c ++++ b/ports/sysdeps/unix/sysv/linux/arm/nptl/unwind-resume.c +@@ -20,7 +20,8 @@ + #include + #include + +-static void (*libgcc_s_resume) (struct _Unwind_Exception *exc); ++static void (*libgcc_s_resume) (struct _Unwind_Exception *exc) ++ __attribute_used__; + static _Unwind_Reason_Code (*libgcc_s_personality) + (_Unwind_State, struct _Unwind_Exception *, struct _Unwind_Context *); + diff --git a/src/ci/docker/dist-powerpc-linux/patches/glibc/2.12.2/002-newer-gcc.patch b/src/ci/docker/dist-powerpc-linux/patches/glibc/2.12.2/002-newer-gcc.patch new file mode 100644 index 0000000000..a96b4882c2 --- /dev/null +++ b/src/ci/docker/dist-powerpc-linux/patches/glibc/2.12.2/002-newer-gcc.patch @@ -0,0 +1,26 @@ +diff --git a/configure b/configure +index b6752d147c6b..6089a3403410 100755 +--- a/configure ++++ b/configure +@@ -5079,7 +5079,7 @@ $as_echo_n "checking version of $CC... " >&6; } + ac_prog_version=`$CC -v 2>&1 | sed -n 's/^.*version \([egcygnustpi-]*[0-9.]*\).*$/\1/p'` + case $ac_prog_version in + '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; +- 3.4* | 4.[0-9]* ) ++ 3.4* | [4-9].* ) + ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; + *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; + +diff --git a/configure.in b/configure.in +index 56849dfc489a..09677eb3d0c1 100644 +--- a/configure.in ++++ b/configure.in +@@ -960,7 +960,7 @@ fi + # These programs are version sensitive. + AC_CHECK_TOOL_PREFIX + AC_CHECK_PROG_VER(CC, ${ac_tool_prefix}gcc ${ac_tool_prefix}cc, -v, +- [version \([egcygnustpi-]*[0-9.]*\)], [3.4* | 4.[0-9]* ], ++ [version \([egcygnustpi-]*[0-9.]*\)], [3.4* | [4-9].* ], + critic_missing="$critic_missing gcc") + AC_CHECK_PROG_VER(MAKE, gnumake gmake make, --version, + [GNU Make[^0-9]*\([0-9][0-9.]*\)], diff --git a/src/ci/docker/dist-powerpc-linux/powerpc-linux-gnu.config b/src/ci/docker/dist-powerpc-linux/powerpc-linux-gnu.config index 984a0a0304..7df41da2bf 100644 --- a/src/ci/docker/dist-powerpc-linux/powerpc-linux-gnu.config +++ b/src/ci/docker/dist-powerpc-linux/powerpc-linux-gnu.config @@ -359,8 +359,8 @@ CT_CC_CORE_PASS_1_NEEDED=y CT_CC_CORE_PASS_2_NEEDED=y CT_CC_gcc=y # CT_CC_GCC_SHOW_LINARO is not set -# CT_CC_GCC_V_5_2_0 is not set -CT_CC_GCC_V_4_9_3=y +CT_CC_GCC_V_5_2_0=y +# CT_CC_GCC_V_4_9_3 is not set # CT_CC_GCC_V_4_8_5 is not set # CT_CC_GCC_V_4_7_4 is not set # CT_CC_GCC_V_4_6_4 is not set @@ -375,8 +375,9 @@ CT_CC_GCC_4_5_or_later=y CT_CC_GCC_4_6_or_later=y CT_CC_GCC_4_7_or_later=y CT_CC_GCC_4_8_or_later=y -CT_CC_GCC_4_9=y CT_CC_GCC_4_9_or_later=y +CT_CC_GCC_5=y +CT_CC_GCC_5_or_later=y CT_CC_GCC_HAS_GRAPHITE=y CT_CC_GCC_USE_GRAPHITE=y CT_CC_GCC_HAS_LTO=y @@ -388,7 +389,7 @@ CT_CC_GCC_USE_GMP_MPFR=y CT_CC_GCC_USE_MPC=y CT_CC_GCC_HAS_LIBQUADMATH=y CT_CC_GCC_HAS_LIBSANITIZER=y -CT_CC_GCC_VERSION="4.9.3" +CT_CC_GCC_VERSION="5.2.0" # CT_CC_LANG_FORTRAN is not set CT_CC_GCC_ENABLE_CXX_FLAGS="" CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="" @@ -460,7 +461,6 @@ CT_GETTEXT_NEEDED=y CT_GMP_NEEDED=y CT_MPFR_NEEDED=y CT_ISL_NEEDED=y -CT_CLOOG_NEEDED=y CT_MPC_NEEDED=y CT_COMPLIBS=y CT_LIBICONV=y @@ -468,7 +468,6 @@ CT_GETTEXT=y CT_GMP=y CT_MPFR=y CT_ISL=y -CT_CLOOG=y CT_MPC=y CT_LIBICONV_V_1_14=y CT_LIBICONV_VERSION="1.14" @@ -494,15 +493,13 @@ CT_MPFR_V_3_1_3=y # CT_MPFR_V_2_4_0 is not set CT_MPFR_VERSION="3.1.3" CT_ISL_V_0_14=y +# CT_ISL_V_0_12_2 is not set CT_ISL_V_0_14_or_later=y CT_ISL_V_0_12_or_later=y CT_ISL_VERSION="0.14" -CT_CLOOG_V_0_18_4=y +# CT_CLOOG_V_0_18_4 is not set # CT_CLOOG_V_0_18_1 is not set # CT_CLOOG_V_0_18_0 is not set -CT_CLOOG_VERSION="0.18.4" -CT_CLOOG_0_18_4_or_later=y -CT_CLOOG_0_18_or_later=y CT_MPC_V_1_0_3=y # CT_MPC_V_1_0_2 is not set # CT_MPC_V_1_0_1 is not set diff --git a/src/ci/docker/dist-powerpc64-linux/patches/glibc/2.12.2/003-newer-gcc.patch b/src/ci/docker/dist-powerpc64-linux/patches/glibc/2.12.2/003-newer-gcc.patch new file mode 100644 index 0000000000..a96b4882c2 --- /dev/null +++ b/src/ci/docker/dist-powerpc64-linux/patches/glibc/2.12.2/003-newer-gcc.patch @@ -0,0 +1,26 @@ +diff --git a/configure b/configure +index b6752d147c6b..6089a3403410 100755 +--- a/configure ++++ b/configure +@@ -5079,7 +5079,7 @@ $as_echo_n "checking version of $CC... " >&6; } + ac_prog_version=`$CC -v 2>&1 | sed -n 's/^.*version \([egcygnustpi-]*[0-9.]*\).*$/\1/p'` + case $ac_prog_version in + '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; +- 3.4* | 4.[0-9]* ) ++ 3.4* | [4-9].* ) + ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; + *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; + +diff --git a/configure.in b/configure.in +index 56849dfc489a..09677eb3d0c1 100644 +--- a/configure.in ++++ b/configure.in +@@ -960,7 +960,7 @@ fi + # These programs are version sensitive. + AC_CHECK_TOOL_PREFIX + AC_CHECK_PROG_VER(CC, ${ac_tool_prefix}gcc ${ac_tool_prefix}cc, -v, +- [version \([egcygnustpi-]*[0-9.]*\)], [3.4* | 4.[0-9]* ], ++ [version \([egcygnustpi-]*[0-9.]*\)], [3.4* | [4-9].* ], + critic_missing="$critic_missing gcc") + AC_CHECK_PROG_VER(MAKE, gnumake gmake make, --version, + [GNU Make[^0-9]*\([0-9][0-9.]*\)], diff --git a/src/ci/docker/dist-powerpc64-linux/powerpc64-linux-gnu.config b/src/ci/docker/dist-powerpc64-linux/powerpc64-linux-gnu.config index c2d02ee85c..4aab4f4fd4 100644 --- a/src/ci/docker/dist-powerpc64-linux/powerpc64-linux-gnu.config +++ b/src/ci/docker/dist-powerpc64-linux/powerpc64-linux-gnu.config @@ -359,8 +359,8 @@ CT_CC_CORE_PASS_1_NEEDED=y CT_CC_CORE_PASS_2_NEEDED=y CT_CC_gcc=y # CT_CC_GCC_SHOW_LINARO is not set -# CT_CC_GCC_V_5_2_0 is not set -CT_CC_GCC_V_4_9_3=y +CT_CC_GCC_V_5_2_0=y +# CT_CC_GCC_V_4_9_3 is not set # CT_CC_GCC_V_4_8_5 is not set # CT_CC_GCC_V_4_7_4 is not set # CT_CC_GCC_V_4_6_4 is not set @@ -375,8 +375,9 @@ CT_CC_GCC_4_5_or_later=y CT_CC_GCC_4_6_or_later=y CT_CC_GCC_4_7_or_later=y CT_CC_GCC_4_8_or_later=y -CT_CC_GCC_4_9=y CT_CC_GCC_4_9_or_later=y +CT_CC_GCC_5=y +CT_CC_GCC_5_or_later=y CT_CC_GCC_HAS_GRAPHITE=y CT_CC_GCC_USE_GRAPHITE=y CT_CC_GCC_HAS_LTO=y @@ -388,7 +389,7 @@ CT_CC_GCC_USE_GMP_MPFR=y CT_CC_GCC_USE_MPC=y CT_CC_GCC_HAS_LIBQUADMATH=y CT_CC_GCC_HAS_LIBSANITIZER=y -CT_CC_GCC_VERSION="4.9.3" +CT_CC_GCC_VERSION="5.2.0" # CT_CC_LANG_FORTRAN is not set CT_CC_GCC_ENABLE_CXX_FLAGS="" CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="" @@ -460,7 +461,6 @@ CT_GETTEXT_NEEDED=y CT_GMP_NEEDED=y CT_MPFR_NEEDED=y CT_ISL_NEEDED=y -CT_CLOOG_NEEDED=y CT_MPC_NEEDED=y CT_COMPLIBS=y CT_LIBICONV=y @@ -468,7 +468,6 @@ CT_GETTEXT=y CT_GMP=y CT_MPFR=y CT_ISL=y -CT_CLOOG=y CT_MPC=y CT_LIBICONV_V_1_14=y CT_LIBICONV_VERSION="1.14" @@ -494,15 +493,10 @@ CT_MPFR_V_3_1_3=y # CT_MPFR_V_2_4_0 is not set CT_MPFR_VERSION="3.1.3" CT_ISL_V_0_14=y +# CT_ISL_V_0_12_2 is not set CT_ISL_V_0_14_or_later=y CT_ISL_V_0_12_or_later=y CT_ISL_VERSION="0.14" -CT_CLOOG_V_0_18_4=y -# CT_CLOOG_V_0_18_1 is not set -# CT_CLOOG_V_0_18_0 is not set -CT_CLOOG_VERSION="0.18.4" -CT_CLOOG_0_18_4_or_later=y -CT_CLOOG_0_18_or_later=y CT_MPC_V_1_0_3=y # CT_MPC_V_1_0_2 is not set # CT_MPC_V_1_0_1 is not set diff --git a/src/ci/docker/dist-s390x-linux/patches/glibc/2.12.2/002-newer-gcc.patch b/src/ci/docker/dist-s390x-linux/patches/glibc/2.12.2/002-newer-gcc.patch new file mode 100644 index 0000000000..a96b4882c2 --- /dev/null +++ b/src/ci/docker/dist-s390x-linux/patches/glibc/2.12.2/002-newer-gcc.patch @@ -0,0 +1,26 @@ +diff --git a/configure b/configure +index b6752d147c6b..6089a3403410 100755 +--- a/configure ++++ b/configure +@@ -5079,7 +5079,7 @@ $as_echo_n "checking version of $CC... " >&6; } + ac_prog_version=`$CC -v 2>&1 | sed -n 's/^.*version \([egcygnustpi-]*[0-9.]*\).*$/\1/p'` + case $ac_prog_version in + '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; +- 3.4* | 4.[0-9]* ) ++ 3.4* | [4-9].* ) + ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; + *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; + +diff --git a/configure.in b/configure.in +index 56849dfc489a..09677eb3d0c1 100644 +--- a/configure.in ++++ b/configure.in +@@ -960,7 +960,7 @@ fi + # These programs are version sensitive. + AC_CHECK_TOOL_PREFIX + AC_CHECK_PROG_VER(CC, ${ac_tool_prefix}gcc ${ac_tool_prefix}cc, -v, +- [version \([egcygnustpi-]*[0-9.]*\)], [3.4* | 4.[0-9]* ], ++ [version \([egcygnustpi-]*[0-9.]*\)], [3.4* | [4-9].* ], + critic_missing="$critic_missing gcc") + AC_CHECK_PROG_VER(MAKE, gnumake gmake make, --version, + [GNU Make[^0-9]*\([0-9][0-9.]*\)], diff --git a/src/ci/docker/dist-s390x-linux/s390x-linux-gnu.config b/src/ci/docker/dist-s390x-linux/s390x-linux-gnu.config index fa5e451098..cd1c41b02e 100644 --- a/src/ci/docker/dist-s390x-linux/s390x-linux-gnu.config +++ b/src/ci/docker/dist-s390x-linux/s390x-linux-gnu.config @@ -339,8 +339,8 @@ CT_CC_CORE_PASS_1_NEEDED=y CT_CC_CORE_PASS_2_NEEDED=y CT_CC_gcc=y # CT_CC_GCC_SHOW_LINARO is not set -# CT_CC_GCC_V_5_2_0 is not set -CT_CC_GCC_V_4_9_3=y +CT_CC_GCC_V_5_2_0=y +# CT_CC_GCC_V_4_9_3 is not set # CT_CC_GCC_V_4_8_5 is not set # CT_CC_GCC_V_4_7_4 is not set # CT_CC_GCC_V_4_6_4 is not set @@ -355,8 +355,9 @@ CT_CC_GCC_4_5_or_later=y CT_CC_GCC_4_6_or_later=y CT_CC_GCC_4_7_or_later=y CT_CC_GCC_4_8_or_later=y -CT_CC_GCC_4_9=y CT_CC_GCC_4_9_or_later=y +CT_CC_GCC_5=y +CT_CC_GCC_5_or_later=y CT_CC_GCC_HAS_GRAPHITE=y CT_CC_GCC_USE_GRAPHITE=y CT_CC_GCC_HAS_LTO=y @@ -368,7 +369,7 @@ CT_CC_GCC_USE_GMP_MPFR=y CT_CC_GCC_USE_MPC=y CT_CC_GCC_HAS_LIBQUADMATH=y CT_CC_GCC_HAS_LIBSANITIZER=y -CT_CC_GCC_VERSION="4.9.3" +CT_CC_GCC_VERSION="5.2.0" # CT_CC_LANG_FORTRAN is not set CT_CC_GCC_ENABLE_CXX_FLAGS="" CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="" @@ -440,7 +441,6 @@ CT_GETTEXT_NEEDED=y CT_GMP_NEEDED=y CT_MPFR_NEEDED=y CT_ISL_NEEDED=y -CT_CLOOG_NEEDED=y CT_MPC_NEEDED=y CT_COMPLIBS=y CT_LIBICONV=y @@ -448,7 +448,6 @@ CT_GETTEXT=y CT_GMP=y CT_MPFR=y CT_ISL=y -CT_CLOOG=y CT_MPC=y CT_LIBICONV_V_1_14=y CT_LIBICONV_VERSION="1.14" @@ -474,15 +473,13 @@ CT_MPFR_V_3_1_3=y # CT_MPFR_V_2_4_0 is not set CT_MPFR_VERSION="3.1.3" CT_ISL_V_0_14=y +# CT_ISL_V_0_12_2 is not set CT_ISL_V_0_14_or_later=y CT_ISL_V_0_12_or_later=y CT_ISL_VERSION="0.14" -CT_CLOOG_V_0_18_4=y +# CT_CLOOG_V_0_18_4 is not set # CT_CLOOG_V_0_18_1 is not set # CT_CLOOG_V_0_18_0 is not set -CT_CLOOG_VERSION="0.18.4" -CT_CLOOG_0_18_4_or_later=y -CT_CLOOG_0_18_or_later=y CT_MPC_V_1_0_3=y # CT_MPC_V_1_0_2 is not set # CT_MPC_V_1_0_1 is not set diff --git a/src/ci/docker/dist-various-1/Dockerfile b/src/ci/docker/dist-various-1/Dockerfile index ab2dd5a399..f80293b182 100644 --- a/src/ci/docker/dist-various-1/Dockerfile +++ b/src/ci/docker/dist-various-1/Dockerfile @@ -112,6 +112,8 @@ ENV TARGETS=$TARGETS,thumbv7em-none-eabihf ENV TARGETS=$TARGETS,thumbv8m.main-none-eabi ENV TARGETS=$TARGETS,riscv32imc-unknown-none-elf ENV TARGETS=$TARGETS,riscv32imac-unknown-none-elf +ENV TARGETS=$TARGETS,riscv64imac-unknown-none-elf +ENV TARGETS=$TARGETS,riscv64gc-unknown-none-elf ENV TARGETS=$TARGETS,armebv7r-none-eabi ENV TARGETS=$TARGETS,armebv7r-none-eabihf ENV TARGETS=$TARGETS,armv7r-none-eabi diff --git a/src/ci/docker/dist-various-1/install-x86_64-redox.sh b/src/ci/docker/dist-various-1/install-x86_64-redox.sh index 29222ff60f..339042bb67 100755 --- a/src/ci/docker/dist-various-1/install-x86_64-redox.sh +++ b/src/ci/docker/dist-various-1/install-x86_64-redox.sh @@ -3,11 +3,5 @@ set -ex -apt-get update -apt-get install -y --no-install-recommends software-properties-common apt-transport-https - -apt-key adv --batch --yes --keyserver keyserver.ubuntu.com --recv-keys AA12E97F0881517F -add-apt-repository -y 'deb https://static.redox-os.org/toolchain/apt /' - -apt-get update -apt-get install -y x86-64-unknown-redox-gcc +curl https://static.redox-os.org/toolchain/x86_64-unknown-redox/relibc-install.tar.gz | \ +tar --extract --gzip --directory /usr/local diff --git a/src/ci/docker/dist-various-2/Dockerfile b/src/ci/docker/dist-various-2/Dockerfile index 906255533a..e2710a18bd 100644 --- a/src/ci/docker/dist-various-2/Dockerfile +++ b/src/ci/docker/dist-various-2/Dockerfile @@ -32,7 +32,7 @@ RUN /tmp/build-solaris-toolchain.sh sparcv9 sparcv9 solaris-sparc COPY dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh /tmp/ # We pass the commit id of the port of LLVM's libunwind to the build script. # Any update to the commit id here, should cause the container image to be re-built from this point on. -RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh "bbe23902411be88d7388f381becefadd6e3ef819" +RUN /tmp/build-x86_64-fortanix-unknown-sgx-toolchain.sh "53b586346f2c7870e20b170decdc30729d97c42b" COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh @@ -70,6 +70,7 @@ ENV TARGETS=$TARGETS,x86_64-sun-solaris ENV TARGETS=$TARGETS,x86_64-unknown-linux-gnux32 ENV TARGETS=$TARGETS,x86_64-unknown-cloudabi ENV TARGETS=$TARGETS,x86_64-fortanix-unknown-sgx +ENV TARGETS=$TARGETS,nvptx64-nvidia-cuda ENV X86_FORTANIX_SGX_LIBS="/x86_64-fortanix-unknown-sgx/lib/" diff --git a/src/ci/docker/dist-various-2/build-cloudabi-toolchain.sh b/src/ci/docker/dist-various-2/build-cloudabi-toolchain.sh index 391f9b2fff..3354a796c3 100755 --- a/src/ci/docker/dist-various-2/build-cloudabi-toolchain.sh +++ b/src/ci/docker/dist-various-2/build-cloudabi-toolchain.sh @@ -32,9 +32,8 @@ ln -s ../lib/llvm-5.0/bin/lld /usr/bin/${target}-ld ln -s ../../${target} /usr/lib/llvm-5.0/${target} # Install the C++ runtime libraries from CloudABI Ports. -echo deb https://nuxi.nl/distfiles/cloudabi-ports/debian/ cloudabi cloudabi > \ - /etc/apt/sources.list.d/cloudabi.list -curl 'https://pgp.mit.edu/pks/lookup?op=get&search=0x0DA51B8531344B15' | \ - apt-key add - +apt-key adv --batch --yes --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 0DA51B8531344B15 +add-apt-repository -y 'deb https://nuxi.nl/distfiles/cloudabi-ports/debian/ cloudabi cloudabi' + apt-get update -apt-get install -y $(echo ${target} | sed -e s/_/-/g)-cxx-runtime +apt-get install -y "${target//_/-}-cxx-runtime" diff --git a/src/ci/docker/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh b/src/ci/docker/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh index 76921316df..725ec341b9 100755 --- a/src/ci/docker/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh +++ b/src/ci/docker/dist-various-2/build-x86_64-fortanix-unknown-sgx-toolchain.sh @@ -12,8 +12,7 @@ target="x86_64-fortanix-unknown-sgx" url="https://github.com/fortanix/llvm-project/archive/${1}.tar.gz" repo_name="llvm-project" -install_prereq() -{ +install_prereq() { apt-get update apt-get install -y --no-install-recommends \ build-essential \ @@ -22,36 +21,32 @@ install_prereq() git } -# Clone Fortanix's port of llvm-project to build libunwind that would link with this target. -# The below method to download a single commit from llvm-project is based on fetch_submodule -# from init_repo.sh -fetch_llvm_commit() -{ - cached="download-${repo_name}.tar.gz" - curl -f -sSL -o ${cached} ${url} - tar -xvzf ${cached} - mkdir "./${repo_name}" && tar -xf ${cached} -C ${repo_name} --strip-components 1 -} - -build_unwind() -{ +build_unwind() { + set -x dir_name="${target}_temp" - rm -rf "./${dir_name}" + rm -rf ${dir_name} mkdir -p ${dir_name} - cd ${dir_name} + pushd ${dir_name} - retry fetch_llvm_commit + # Clone Fortanix's fork of llvm-project which has a port of libunwind + fetch_github_commit_archive "$repo_name" "$url" cd "${repo_name}/libunwind" # Build libunwind mkdir -p build cd build - cmake -DCMAKE_BUILD_TYPE="RELEASE" -DRUST_SGX=1 -G "Unix Makefiles" -DLLVM_PATH=../../llvm/ ../ + cmake -DCMAKE_BUILD_TYPE="RELEASE" -DRUST_SGX=1 -G "Unix Makefiles" \ + -DLLVM_ENABLE_WARNINGS=1 -DLIBUNWIND_ENABLE_WERROR=1 -DLIBUNWIND_ENABLE_PEDANTIC=0 \ + -DLLVM_PATH=../../llvm/ ../ make unwind_static install -D "lib/libunwind.a" "/${target}/lib/libunwind.a" + + popd rm -rf ${dir_name} + + { set +x; } 2>/dev/null } set -x hide_output install_prereq -hide_output build_unwind +build_unwind diff --git a/src/ci/docker/dist-various-2/shared.sh b/src/ci/docker/dist-various-2/shared.sh index fb917b0510..7abace65b9 100644 --- a/src/ci/docker/dist-various-2/shared.sh +++ b/src/ci/docker/dist-various-2/shared.sh @@ -1,5 +1,5 @@ hide_output() { - set +x + { set +x; } 2>/dev/null on_err=" echo ERROR: An error was encountered with the build. cat /tmp/build.log @@ -14,6 +14,7 @@ exit 1 set -x } +# Copied from ../../shared.sh function retry { echo "Attempting with retry:" "$@" local n=1 @@ -31,3 +32,15 @@ function retry { } done } + +# Copied from ../../init_repo.sh +function fetch_github_commit_archive { + local module=$1 + local cached="download-${module//\//-}.tar.gz" + retry sh -c "rm -f $cached && \ + curl -f -sSL -o $cached $2" + mkdir $module + touch "$module/.git" + tar -C $module --strip-components=1 -xf $cached + rm $cached +} diff --git a/src/ci/docker/dist-x86_64-linux/build-clang.sh b/src/ci/docker/dist-x86_64-linux/build-clang.sh index ff5b50123f..ac681b7168 100755 --- a/src/ci/docker/dist-x86_64-linux/build-clang.sh +++ b/src/ci/docker/dist-x86_64-linux/build-clang.sh @@ -4,26 +4,14 @@ set -ex source shared.sh -# Currently these commits are all tip-of-tree as of 2018-12-16, used to pick up -# a fix for rust-lang/rust#56849 -LLVM=032b00a5404865765cda7db3039f39d54964d8b0 -LLD=3e4aa4e8671523321af51449e0569f455ef3ad43 -CLANG=a6b9739069763243020f4ea6fe586bc135fde1f9 +LLVM=llvmorg-8.0.0-rc2 -mkdir clang -cd clang +mkdir llvm-project +cd llvm-project -curl -L https://github.com/llvm-mirror/llvm/archive/$LLVM.tar.gz | \ +curl -L https://github.com/llvm/llvm-project/archive/$LLVM.tar.gz | \ tar xzf - --strip-components=1 -mkdir -p tools/clang -curl -L https://github.com/llvm-mirror/clang/archive/$CLANG.tar.gz | \ - tar xzf - --strip-components=1 -C tools/clang - -mkdir -p tools/lld -curl -L https://github.com/llvm-mirror/lld/archive/$LLD.tar.gz | \ - tar zxf - --strip-components=1 -C tools/lld - mkdir clang-build cd clang-build @@ -39,20 +27,21 @@ cd clang-build # # [1]: https://sourceware.org/ml/crossgcc/2008-11/msg00028.html INC="/rustroot/include" -INC="$INC:/rustroot/lib/gcc/x86_64-unknown-linux-gnu/4.8.5/include-fixed" +INC="$INC:/rustroot/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/include-fixed" INC="$INC:/usr/include" hide_output \ - cmake .. \ + cmake ../llvm \ -DCMAKE_C_COMPILER=/rustroot/bin/gcc \ -DCMAKE_CXX_COMPILER=/rustroot/bin/g++ \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/rustroot \ -DLLVM_TARGETS_TO_BUILD=X86 \ + -DLLVM_ENABLE_PROJECTS="clang;lld" \ -DC_INCLUDE_DIRS="$INC" hide_output make -j10 hide_output make install cd ../.. -rm -rf clang +rm -rf llvm-project diff --git a/src/ci/docker/dist-x86_64-linux/build-gcc.sh b/src/ci/docker/dist-x86_64-linux/build-gcc.sh index 9f3ae55cb3..7f6e94d326 100755 --- a/src/ci/docker/dist-x86_64-linux/build-gcc.sh +++ b/src/ci/docker/dist-x86_64-linux/build-gcc.sh @@ -3,9 +3,9 @@ set -ex source shared.sh -GCC=4.8.5 +GCC=5.5.0 -curl https://ftp.gnu.org/gnu/gcc/gcc-$GCC/gcc-$GCC.tar.bz2 | tar xjf - +curl https://ftp.gnu.org/gnu/gcc/gcc-$GCC/gcc-$GCC.tar.xz | xzcat | tar xf - cd gcc-$GCC # FIXME(#49246): Remove the `sed` below. diff --git a/src/ci/docker/dist-x86_64-linux/build-perl.sh b/src/ci/docker/dist-x86_64-linux/build-perl.sh index a6c3d5cb68..a678d353d5 100755 --- a/src/ci/docker/dist-x86_64-linux/build-perl.sh +++ b/src/ci/docker/dist-x86_64-linux/build-perl.sh @@ -11,7 +11,8 @@ cd perl-5.28.0 # Gotta do some hackery to tell python about our custom OpenSSL build, but other # than that fairly normal. CC=gcc \ -CFLAGS='-I /rustroot/include' LDFLAGS='-L /rustroot/lib -L /rustroot/lib64' \ +CFLAGS='-I /rustroot/include -fgnu89-inline' \ +LDFLAGS='-L /rustroot/lib -L /rustroot/lib64' \ hide_output ./configure.gnu hide_output make -j10 hide_output make install diff --git a/src/ci/docker/run.sh b/src/ci/docker/run.sh index ad6188568c..b4426bbfb9 100755 --- a/src/ci/docker/run.sh +++ b/src/ci/docker/run.sh @@ -20,9 +20,9 @@ travis_time_start if [ -f "$docker_dir/$image/Dockerfile" ]; then if [ "$CI" != "" ]; then hash_key=/tmp/.docker-hash-key.txt - find $docker_dir/$image $docker_dir/scripts -type f | \ - sort | \ - xargs cat >> $hash_key + rm -f "${hash_key}" + echo $image >> $hash_key + find $docker_dir -type f | sort | xargs cat >> $hash_key docker --version >> $hash_key cksum=$(sha512sum $hash_key | \ awk '{print $1}') @@ -31,7 +31,7 @@ if [ -f "$docker_dir/$image/Dockerfile" ]; then echo "Attempting to download $s3url" rm -f /tmp/rustci_docker_cache set +e - retry curl -f -L -C - -o /tmp/rustci_docker_cache "$url" + retry curl -y 30 -Y 10 --connect-timeout 30 -f -L -C - -o /tmp/rustci_docker_cache "$url" loaded_images=$(docker load -i /tmp/rustci_docker_cache | sed 's/.* sha/sha/') set -e echo "Downloaded containers:\n$loaded_images" diff --git a/src/ci/docker/scripts/android-sdk.sh b/src/ci/docker/scripts/android-sdk.sh index 179f63fc83..e78e3795c0 100644 --- a/src/ci/docker/scripts/android-sdk.sh +++ b/src/ci/docker/scripts/android-sdk.sh @@ -20,11 +20,19 @@ download_sysimage() { # The output from sdkmanager is so noisy that it will occupy all of the 4 MB # log extremely quickly. Thus we must silence all output. yes | sdkmanager --licenses > /dev/null - yes | sdkmanager platform-tools emulator \ + yes | sdkmanager platform-tools \ "platforms;android-$api" \ "system-images;android-$api;default;$abi" > /dev/null } +download_emulator() { + # Download a pinned version of the emulator since upgrades can cause issues + curl -fo emulator.zip "https://dl.google.com/android/repository/emulator-linux-$1.zip" + rm -rf "${ANDROID_HOME}/emulator" + unzip -q emulator.zip -d "${ANDROID_HOME}" + rm -f emulator.zip +} + create_avd() { abi=$1 api=$2 @@ -40,11 +48,12 @@ download_and_create_avd() { download_sdk $1 download_sysimage $2 $3 create_avd $2 $3 + download_emulator $4 } # Usage: # -# setup_android_sdk 4333796 armeabi-v7a 18 +# download_and_create_avd 4333796 armeabi-v7a 18 5264690 # # 4333796 => # SDK tool version. @@ -53,3 +62,6 @@ download_and_create_avd() { # System image ABI # 18 => # Android API Level (18 = Android 4.3 = Jelly Bean MR2) +# 5264690 => +# Android Emulator version. +# Copy from the "build_id" in the `/android/sdk/emulator/emulator -version` output diff --git a/src/ci/docker/scripts/freebsd-toolchain.sh b/src/ci/docker/scripts/freebsd-toolchain.sh index 04483e2492..b1ac490a87 100755 --- a/src/ci/docker/scripts/freebsd-toolchain.sh +++ b/src/ci/docker/scripts/freebsd-toolchain.sh @@ -1,4 +1,6 @@ #!/bin/bash +# ignore-tidy-linelength + set -eux arch=$1 @@ -55,7 +57,9 @@ for lib in c++ c_nonshared compiler_rt execinfo gcc pthread rt ssp_nonshared; do files_to_extract=("${files_to_extract[@]}" "./usr/lib/lib${lib}.*") done -URL=https://download.freebsd.org/ftp/releases/${freebsd_arch}/${freebsd_version}-RELEASE/base.txz +# Originally downloaded from: +# https://download.freebsd.org/ftp/releases/${freebsd_arch}/${freebsd_version}-RELEASE/base.txz +URL=https://s3-us-west-1.amazonaws.com/rust-lang-ci2/rust-ci-mirror/2019-04-04-freebsd-${freebsd_arch}-${freebsd_version}-RELEASE-base.txz curl "$URL" | tar xJf - -C "$sysroot" --wildcards "${files_to_extract[@]}" # Fix up absolute symlinks from the system image. This can be removed diff --git a/src/ci/docker/wasm32-unknown/Dockerfile b/src/ci/docker/test-various/Dockerfile similarity index 63% rename from src/ci/docker/wasm32-unknown/Dockerfile rename to src/ci/docker/test-various/Dockerfile index 161f0c0062..6c419e13c9 100644 --- a/src/ci/docker/wasm32-unknown/Dockerfile +++ b/src/ci/docker/test-various/Dockerfile @@ -13,14 +13,16 @@ RUN apt-get update && apt-get install -y --no-install-recommends \ gdb \ xz-utils +# FIXME: build the `ptx-linker` instead. +RUN curl -sL https://github.com/denzp/rust-ptx-linker/releases/download/v0.9.0-alpha.2/rust-ptx-linker.linux64.tar.gz | \ + tar -xzvC /usr/bin + RUN curl -sL https://nodejs.org/dist/v9.2.0/node-v9.2.0-linux-x64.tar.xz | \ - tar -xJ + tar -xJ COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh -ENV TARGETS=wasm32-unknown-unknown - ENV RUST_CONFIGURE_ARGS \ --set build.nodejs=/node-v9.2.0-linux-x64/bin/node \ --set rust.lld @@ -31,11 +33,18 @@ ENV RUST_CONFIGURE_ARGS \ # other contexts as well ENV NO_DEBUG_ASSERTIONS=1 -ENV SCRIPT python2.7 /checkout/x.py test --target $TARGETS \ +ENV WASM_TARGETS=wasm32-unknown-unknown +ENV WASM_SCRIPT python2.7 /checkout/x.py test --target $WASM_TARGETS \ src/test/run-make \ src/test/ui \ src/test/run-pass \ src/test/compile-fail \ src/test/mir-opt \ src/test/codegen-units \ - src/libcore \ + src/libcore + +ENV NVPTX_TARGETS=nvptx64-nvidia-cuda +ENV NVPTX_SCRIPT python2.7 /checkout/x.py test --target $NVPTX_TARGETS \ + src/test/run-make + +ENV SCRIPT $WASM_SCRIPT && $NVPTX_SCRIPT diff --git a/src/ci/docker/x86_64-gnu-debug/Dockerfile b/src/ci/docker/x86_64-gnu-debug/Dockerfile index bdde7ad7fe..1c7eff68ad 100644 --- a/src/ci/docker/x86_64-gnu-debug/Dockerfile +++ b/src/ci/docker/x86_64-gnu-debug/Dockerfile @@ -1,4 +1,4 @@ -FROM ubuntu:16.04 +FROM ubuntu:18.10 RUN apt-get update && apt-get install -y --no-install-recommends \ g++ \ @@ -7,18 +7,37 @@ RUN apt-get update && apt-get install -y --no-install-recommends \ curl \ ca-certificates \ python2.7 \ + python2.7-dev \ + libxml2-dev \ + libncurses-dev \ + libedit-dev \ + swig \ + doxygen \ git \ cmake \ sudo \ gdb \ - xz-utils + xz-utils \ + lld \ + clang COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh +ENV RUSTBUILD_FORCE_CLANG_BASED_TESTS 1 ENV RUN_CHECK_WITH_PARALLEL_QUERIES 1 + ENV RUST_CONFIGURE_ARGS \ --build=x86_64-unknown-linux-gnu \ --enable-debug \ - --enable-optimize -ENV SCRIPT python2.7 ../x.py build + --enable-lld \ + --enable-lldb \ + --enable-optimize \ + --set llvm.use-linker=lld \ + --set target.x86_64-unknown-linux-gnu.linker=clang \ + --set target.x86_64-unknown-linux-gnu.cc=clang \ + --set target.x86_64-unknown-linux-gnu.cxx=clang++ + +ENV SCRIPT \ + python2.7 ../x.py build && \ + python2.7 ../x.py test src/test/run-make-fulldeps --test-args clang diff --git a/src/ci/docker/x86_64-gnu-tools/checktools.sh b/src/ci/docker/x86_64-gnu-tools/checktools.sh index 2e5b335950..3343716419 100755 --- a/src/ci/docker/x86_64-gnu-tools/checktools.sh +++ b/src/ci/docker/x86_64-gnu-tools/checktools.sh @@ -23,6 +23,7 @@ python2.7 "$X_PY" test --no-fail-fast \ src/doc/nomicon \ src/doc/reference \ src/doc/rust-by-example \ + src/doc/embedded-book \ src/tools/clippy \ src/tools/rls \ src/tools/rustfmt \ diff --git a/src/ci/init_repo.sh b/src/ci/init_repo.sh index be2cadbbe6..3dfd338157 100755 --- a/src/ci/init_repo.sh +++ b/src/ci/init_repo.sh @@ -34,19 +34,19 @@ if grep -q RUST_RELEASE_CHANNEL=beta src/ci/run.sh; then git fetch origin --unshallow beta master fi -function fetch_submodule { +# Duplicated in docker/dist-various-2/shared.sh +function fetch_github_commit_archive { local module=$1 local cached="download-${module//\//-}.tar.gz" retry sh -c "rm -f $cached && \ - curl -sSL -o $cached $2" + curl -f -sSL -o $cached $2" mkdir $module touch "$module/.git" tar -C $module --strip-components=1 -xf $cached rm $cached } -included="src/llvm src/llvm-emscripten src/doc/book src/doc/rust-by-example" -included="$included src/tools/lld src/tools/clang src/tools/lldb" +included="src/llvm-project src/llvm-emscripten src/doc/book src/doc/rust-by-example" modules="$(git config --file .gitmodules --get-regexp '\.path$' | cut -d' ' -f2)" modules=($modules) use_git="" @@ -59,7 +59,7 @@ for i in ${!modules[@]}; do git rm $module url=${urls[$i]} url=${url/\.git/} - fetch_submodule $module "$url/archive/$commit.tar.gz" & + fetch_github_commit_archive $module "$url/archive/$commit.tar.gz" & continue else use_git="$use_git $module" diff --git a/src/ci/run.sh b/src/ci/run.sh index 8051a21ccf..3606f54720 100755 --- a/src/ci/run.sh +++ b/src/ci/run.sh @@ -82,7 +82,7 @@ fi SCCACHE_IDLE_TIMEOUT=10800 sccache --start-server || true if [ "$RUN_CHECK_WITH_PARALLEL_QUERIES" != "" ]; then - $SRC/configure --enable-experimental-parallel-queries + $SRC/configure --enable-parallel-compiler CARGO_INCREMENTAL=0 python2.7 ../x.py check rm -f config.toml rm -rf build diff --git a/src/ci/shared.sh b/src/ci/shared.sh index 4a49f3441a..3ba64ad412 100644 --- a/src/ci/shared.sh +++ b/src/ci/shared.sh @@ -5,6 +5,7 @@ # marked as an executable file in git. # See http://unix.stackexchange.com/questions/82598 +# Duplicated in docker/dist-various-2/shared.sh function retry { echo "Attempting with retry:" "$@" local n=1 diff --git a/src/doc/book/.github/ISSUE_TEMPLATE.md b/src/doc/book/.github/ISSUE_TEMPLATE.md deleted file mode 100644 index dcd59a807d..0000000000 --- a/src/doc/book/.github/ISSUE_TEMPLATE.md +++ /dev/null @@ -1,22 +0,0 @@ -## What to expect when you file an issue here - -Thank you for caring about the quality of the book! Each edition has -different types of issues we can accept, please read on for details. - -### 2018 edition - -This version of the book is under development, please file issues liberally! - -### Second edition - -No Starch Press has brought the second edition to print. Bugs containing -factual errors will be documented as errata; bugs for wording changes or -other small corrections should be filed against the 2018 edition. - -### First edition - -The first edition of the book is frozen, and bugs filed against it will -be closed. - - -Thank you for reading, you may now delete this text! diff --git a/src/doc/book/.github/PULL_REQUEST_TEMPLATE.md b/src/doc/book/.github/PULL_REQUEST_TEMPLATE.md deleted file mode 100644 index bda1589336..0000000000 --- a/src/doc/book/.github/PULL_REQUEST_TEMPLATE.md +++ /dev/null @@ -1,24 +0,0 @@ -## What to expect when you open a pull request here - -### 2018 Edition - -The 2018 is a "living" edition; it's not scheduled for in-print publication at -this time, and so is able to be updated at any time. We'd love pull requests to -fix issues with this edition, but we're not interested in extremely large -changes without discussing them first. If you'd like to make a big change, -please open an issue first! We'd hate for you to do some hard work that we -ultimately wouldn't accept. - -### Second edition - -No Starch Press has brought the second edition to print. Pull requests fixing -factual errors will be accepted and documented as errata; pull requests changing -wording or other small corrections should be made against the 2018 edition instead. - -### First edition - -The first edition is frozen, and no longer accepting changes. Pull requests -made against it will be closed. - - -Thank you for reading, you may now delete this text! diff --git a/src/doc/book/.travis.yml b/src/doc/book/.travis.yml index 97687a2d7f..095308b443 100644 --- a/src/doc/book/.travis.yml +++ b/src/doc/book/.travis.yml @@ -3,7 +3,7 @@ dist: trusty language: rust cache: cargo rust: - - beta # Change this to stable when Rust 1.31.0 is out + - stable branches: only: - master diff --git a/src/doc/book/2018-edition/convert-quotes.sh b/src/doc/book/2018-edition/convert-quotes.sh index 229be88921..aa51dcbddf 100755 --- a/src/doc/book/2018-edition/convert-quotes.sh +++ b/src/doc/book/2018-edition/convert-quotes.sh @@ -1,13 +1,4 @@ #!/bin/bash -# Copyright 2017 The Rust Project Developers. See the COPYRIGHT -# file at the top-level directory of this distribution and at -# http://rust-lang.org/COPYRIGHT. -# -# Licensed under the Apache License, Version 2.0 or the MIT license -# , at your -# option. This file may not be copied, modified, or distributed -# except according to those terms. set -eu diff --git a/src/doc/book/2018-edition/nostarch.sh b/src/doc/book/2018-edition/nostarch.sh index 432add597c..6c4173a01c 100755 --- a/src/doc/book/2018-edition/nostarch.sh +++ b/src/doc/book/2018-edition/nostarch.sh @@ -1,13 +1,4 @@ #!/bin/bash -# Copyright 2016 The Rust Project Developers. See the COPYRIGHT -# file at the top-level directory of this distribution and at -# http://rust-lang.org/COPYRIGHT. -# -# Licensed under the Apache License, Version 2.0 or the MIT license -# , at your -# option. This file may not be copied, modified, or distributed -# except according to those terms. set -eu @@ -16,18 +7,18 @@ cargo build --release mkdir -p tmp rm -rf tmp/*.md -# Get all the markdown files in the src dir, +# Get all the Markdown files in the src dir, ls src/${1:-""}*.md | \ -# except for SUMMARY.md. +# except for `SUMMARY.md`. grep -v SUMMARY.md | \ # Extract just the filename so we can reuse it easily. xargs -n 1 basename | \ -# Remove all links followed by , then -# Change all remaining links from markdown to italicized inline text. +# Remove all links followed by ```, then +# Change all remaining links from Markdown to italicized inline text. while IFS= read -r filename; do < "src/$filename" ./target/release/remove_links \ | ./target/release/link2print \ | ./target/release/remove_markup > "tmp/$filename" done -# Concat the files into the nostarch dir. +# Concatenate the files into the `nostarch` dir. ./target/release/concat_chapters tmp nostarch diff --git a/src/doc/book/2018-edition/nostarch/chapter07.md b/src/doc/book/2018-edition/nostarch/chapter07.md index 21aa3b0c77..f44156d6e5 100644 --- a/src/doc/book/2018-edition/nostarch/chapter07.md +++ b/src/doc/book/2018-edition/nostarch/chapter07.md @@ -139,12 +139,12 @@ called crate roots because the contents of either of these two files form a module named `crate` at the root of the crate’s module tree. So in Listing 7-2, we have a module tree that looks like Listing 7-3: -``` +```text crate - └── sound - └── instrument - └── woodwind - └── voice +└── sound + ├── instrument + │ └── woodwind + └── voice ``` Listing 7-3: The module tree for the code in Listing 7-2 diff --git a/src/doc/book/2018-edition/tools/src/bin/concat_chapters.rs b/src/doc/book/2018-edition/tools/src/bin/concat_chapters.rs index accb2d3d1b..da02dd34b4 100644 --- a/src/doc/book/2018-edition/tools/src/bin/concat_chapters.rs +++ b/src/doc/book/2018-edition/tools/src/bin/concat_chapters.rs @@ -1,13 +1,3 @@ -// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT -// file at the top-level directory of this distribution and at -// http://rust-lang.org/COPYRIGHT. -// -// Licensed under the Apache License, Version 2.0 or the MIT license -// , at your -// option. This file may not be copied, modified, or distributed -// except according to those terms. - #[macro_use] extern crate lazy_static; extern crate regex; diff --git a/src/doc/book/2018-edition/tools/src/bin/convert_quotes.rs b/src/doc/book/2018-edition/tools/src/bin/convert_quotes.rs index 2d8e5e927e..b151ae7e9f 100644 --- a/src/doc/book/2018-edition/tools/src/bin/convert_quotes.rs +++ b/src/doc/book/2018-edition/tools/src/bin/convert_quotes.rs @@ -1,13 +1,3 @@ -// Copyright 2017 The Rust Project Developers. See the COPYRIGHT -// file at the top-level directory of this distribution and at -// http://rust-lang.org/COPYRIGHT. -// -// Licensed under the Apache License, Version 2.0 or the MIT license -// , at your -// option. This file may not be copied, modified, or distributed -// except according to those terms. - use std::io; use std::io::{Read, Write}; @@ -22,7 +12,6 @@ fn main() { } for line in buffer.lines() { - if line.is_empty() { is_in_inline_code = false; } diff --git a/src/doc/book/2018-edition/tools/src/bin/lfp.rs b/src/doc/book/2018-edition/tools/src/bin/lfp.rs index c7d9e54eb3..f475df0883 100644 --- a/src/doc/book/2018-edition/tools/src/bin/lfp.rs +++ b/src/doc/book/2018-edition/tools/src/bin/lfp.rs @@ -1,20 +1,11 @@ -// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT -// file at the top-level directory of this distribution and at -// http://rust-lang.org/COPYRIGHT. -// -// Licensed under the Apache License, Version 2.0 or the MIT license -// , at your -// option. This file may not be copied, modified, or distributed -// except according to those terms. - // We have some long regex literals, so: // ignore-tidy-linelength -extern crate rustc_serialize; extern crate docopt; -use docopt::Docopt; +extern crate rustc_serialize; extern crate walkdir; + +use docopt::Docopt; use std::{path, fs, io}; use std::io::{BufRead, Write}; diff --git a/src/doc/book/2018-edition/tools/src/bin/link2print.rs b/src/doc/book/2018-edition/tools/src/bin/link2print.rs index 071c7802c0..4fe4477b10 100644 --- a/src/doc/book/2018-edition/tools/src/bin/link2print.rs +++ b/src/doc/book/2018-edition/tools/src/bin/link2print.rs @@ -1,15 +1,4 @@ -// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT -// file at the top-level directory of this distribution and at -// http://rust-lang.org/COPYRIGHT. -// -// Licensed under the Apache License, Version 2.0 or the MIT license -// , at your -// option. This file may not be copied, modified, or distributed -// except according to those terms. - - -// FIXME: We have some long lines that could be refactored, but it's not a big deal. +// FIXME: we have some long lines that could be refactored, but it's not a big deal. // ignore-tidy-linelength extern crate regex; @@ -20,7 +9,6 @@ use std::io::{Read, Write}; use regex::{Regex, Captures}; fn main() { - write_md(parse_links(parse_references(read_md()))); } @@ -38,7 +26,7 @@ fn write_md(output: String) { fn parse_references(buffer: String) -> (String, HashMap) { let mut ref_map = HashMap::new(); - // FIXME: Currently doesn't handle "title" in following line + // FIXME: currently doesn't handle "title" in following line. let re = Regex::new(r###"(?m)\n?^ {0,3}\[([^]]+)\]:[[:blank:]]*(.*)$"###).unwrap(); let output = re.replace_all(&buffer, |caps: &Captures| { let key = caps.at(1).unwrap().to_owned().to_uppercase(); @@ -52,7 +40,7 @@ fn parse_references(buffer: String) -> (String, HashMap) { } fn parse_links((buffer, ref_map): (String, HashMap)) -> String { - // FIXME: check which punctuation is allowed by spec + // FIXME: check which punctuation is allowed by spec. let re = Regex::new(r###"(?:(?P
(?:```(?:[^`]|`[^`])*`?\n```\n)|(?:[^[]`[^`\n]+[\n]?[^`\n]*`))|(?:\[(?P[^]]+)\](?:(?:\([[:blank:]]*(?P[^")]*[^ ])(?:[[:blank:]]*"[^"]*")?\))|(?:\[(?P[^]]*)\]))?))"###).expect("could not create regex");
     let error_code = Regex::new(r###"^E\d{4}$"###).expect("could not create regex");
     let output = re.replace_all(&buffer, |caps: &Captures| {
@@ -62,7 +50,7 @@ fn parse_links((buffer, ref_map): (String, HashMap)) -> String {
                 let name = caps.name("name").expect("could not get name").to_owned();
                 // Really we should ignore text inside code blocks,
                 // this is a hack to not try to treat `#[derive()]`,
-                // `[profile]`, `[test]`, or `[E\d\d\d\d]` like a link
+                // `[profile]`, `[test]`, or `[E\d\d\d\d]` like a link.
                 if name.starts_with("derive(") ||
                    name.starts_with("profile") ||
                    name.starts_with("test") ||
@@ -71,19 +59,19 @@ fn parse_links((buffer, ref_map): (String, HashMap)) -> String {
                 }
 
                 let val = match caps.name("val") {
-                    // [name](link)
+                    // `[name](link)`
                     Some(value) => value.to_owned(),
                     None => {
                         match caps.name("key") {
                             Some(key) => {
                                 match key {
-                                    // [name][]
+                                    // `[name][]`
                                     "" => format!("{}", ref_map.get(&name.to_uppercase()).expect(&format!("could not find url for the link text `{}`", name))),
-                                    // [name][reference]
+                                    // `[name][reference]`
                                     _ => format!("{}", ref_map.get(&key.to_uppercase()).expect(&format!("could not find url for the link text `{}`", key))),
                                 }
                             }
-                            // [name] as reference
+                            // `[name]` as reference
                             None => format!("{}", ref_map.get(&name.to_uppercase()).expect(&format!("could not find url for the link text `{}`", name))),
                         }
                     }
@@ -415,7 +403,4 @@ Some text to show that the reference links can follow later.
             .to_string();
         assert_eq!(parse(source), target);
     }
-
-
-
 }
diff --git a/src/doc/book/2018-edition/tools/src/bin/remove_links.rs b/src/doc/book/2018-edition/tools/src/bin/remove_links.rs
index 9add24ece3..71c386106f 100644
--- a/src/doc/book/2018-edition/tools/src/bin/remove_links.rs
+++ b/src/doc/book/2018-edition/tools/src/bin/remove_links.rs
@@ -1,19 +1,9 @@
-// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
-// file at the top-level directory of this distribution and at
-// http://rust-lang.org/COPYRIGHT.
-//
-// Licensed under the Apache License, Version 2.0  or the MIT license
-// , at your
-// option. This file may not be copied, modified, or distributed
-// except according to those terms.
-
 extern crate regex;
 
+use std::collections::HashSet;
 use std::io;
 use std::io::{Read, Write};
 use regex::{Regex, Captures};
-use std::collections::HashSet;
 
 fn main () {
     let mut buffer = String::new();
@@ -23,31 +13,31 @@ fn main () {
 
     let mut refs = HashSet::new();
 
-    // capture all links and link references
+    // Capture all links and link references.
     let regex = r"\[([^\]]+)\](?:(?:\[([^\]]+)\])|(?:\([^\)]+\)))(?i)";
     let link_regex = Regex::new(regex).unwrap();
     let first_pass = link_regex.replace_all(&buffer, |caps: &Captures| {
 
-        // save the link reference we want to delete
+        // Save the link reference we want to delete.
         if let Some(reference) = caps.at(2) {
             refs.insert(reference.to_owned());
         }
 
-        // put the link title back
+        // Put the link title back.
         caps.at(1).unwrap().to_owned()
     });
 
-    // search for the references we need to delete
+    // Search for the references we need to delete.
     let ref_regex = Regex::new(r"\n\[([^\]]+)\]:\s.*\n").unwrap();
     let out = ref_regex.replace_all(&first_pass, |caps: &Captures| {
         let capture = caps.at(1).unwrap().to_owned();
 
-        // check if we've marked this reference for deletion...
+        // Check if we've marked this reference for deletion ...
         if refs.contains(capture.as_str()) {
             return "".to_string();
         }
 
-        //... else we put back everything we captured
+        // ... else we put back everything we captured.
         caps.at(0).unwrap().to_owned()
     });
 
diff --git a/src/doc/book/2018-edition/tools/src/bin/remove_markup.rs b/src/doc/book/2018-edition/tools/src/bin/remove_markup.rs
index c8cbc1c18f..be444bfd9a 100644
--- a/src/doc/book/2018-edition/tools/src/bin/remove_markup.rs
+++ b/src/doc/book/2018-edition/tools/src/bin/remove_markup.rs
@@ -1,14 +1,5 @@
-// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
-// file at the top-level directory of this distribution and at
-// http://rust-lang.org/COPYRIGHT.
-//
-// Licensed under the Apache License, Version 2.0  or the MIT license
-// , at your
-// option. This file may not be copied, modified, or distributed
-// except according to those terms.
-
 extern crate regex;
+
 use std::io;
 use std::io::{Read, Write};
 use regex::{Regex, Captures};
@@ -31,23 +22,23 @@ fn write_md(output: String) {
 
 fn remove_markup(input: String) -> String {
     let filename_regex = Regex::new(r#"\A(.*)\z"#).unwrap();
-    // Captions sometimes take up multiple lines
+    // Captions sometimes take up multiple lines.
     let caption_start_regex = Regex::new(r#"\A(.*)\z"#).unwrap();
     let caption_end_regex = Regex::new(r#"(.*)\z"#).unwrap();
     let regexen = vec![filename_regex, caption_start_regex, caption_end_regex];
 
     let lines: Vec<_> = input.lines().flat_map(|line| {
-        // Remove our figure and caption markup
+        // Remove our figure and caption markup.
         if line == "
" ||
             line == "
" ||
             line == "
" ||
             line == "
"
         {
             None
-        // Remove our syntax highlighting and rustdoc markers
+        // Remove our syntax highlighting and rustdoc markers.
         } else if line.starts_with("```") {
             Some(String::from("```"))
-        // Remove the span around filenames and captions
+        // Remove the span around filenames and captions.
         } else {
             let result = regexen.iter().fold(line.to_string(), |result, regex| {
                 regex.replace_all(&result, |caps: &Captures| {
diff --git a/src/doc/book/CONTRIBUTING.md b/src/doc/book/CONTRIBUTING.md
index 324dff6fc9..d1d1088619 100644
--- a/src/doc/book/CONTRIBUTING.md
+++ b/src/doc/book/CONTRIBUTING.md
@@ -10,7 +10,7 @@ repository.
 
 ## Code of Conduct
 
-The Rust project has [a code of conduct](http://rust-lang.org/conduct.html)
+The Rust project has [a code of conduct](http://rust-lang.org/policies/code-of-conduct)
 that governs all sub-projects, including this one. Please respect it!
 
 ## Review
@@ -33,37 +33,10 @@ enhance the book in some way!
 
 ## Translations
 
-We'd especially love help translating the second edition of the book! See the
-[Translations] label to join in efforts that are currently in progress. Open
-a new issue to start working on a new language! We're waiting on [mdbook
-support] for multiple languages before we merge any in, but feel free to
-start! The second edition is frozen and won't see major changes, so if 
-you start with that, you won't have to redo work :)
+We'd love help translating the book! See the [Translations] label to join in
+efforts that are currently in progress. Open a new issue to start working on
+a new language! We're waiting on [mdbook support] for multiple languages
+before we merge any in, but feel free to start!
 
 [Translations]: https://github.com/rust-lang/book/issues?q=is%3Aopen+is%3Aissue+label%3ATranslations
-[mdbook support]: https://github.com/azerupi/mdBook/issues/5
-
-## Edition specific details
-
-Each edition of the book may be taking contributions, but only of certain
-kinds depending on the edition. Read on to learn the details!
-
-### Contributing to the 2018 Edition
-
-The 2018 is a "living" edition; it's not scheduled for in-print publication
-at this time, and so is able to be updated at any time. We'd love pull
-requests to fix issues with this edition, but we're not interested in
-extremely large changes without discussing them first. If you'd like to make
-a big change, please open an issue first! We'd hate for you to do some hard work
-that we ultimately wouldn't accept.
-
-## Contributing to the Second Edition
-
-The second edition is completely frozen, and not accepting changes. It's
-meant to be in sync with the print version available from No Starch
-Press.
-
-## Contributing to the First Edition
-
-The first edition is completely frozen, and not accepting changes. It's
-mostly kept around for history's sake.
+[mdbook support]: https://github.com/azerupi/mdBook/issues/5
\ No newline at end of file
diff --git a/src/doc/book/Cargo.toml b/src/doc/book/Cargo.toml
index bb6763509f..b86be477ca 100644
--- a/src/doc/book/Cargo.toml
+++ b/src/doc/book/Cargo.toml
@@ -3,6 +3,7 @@ name = "rust-book"
 version = "0.0.1"
 authors = ["Steve Klabnik "]
 description = "The Rust Book"
+edition = "2018"
 
 [[bin]]
 name = "concat_chapters"
diff --git a/src/doc/book/README.md b/src/doc/book/README.md
index 54e9fff690..c52ab6719a 100644
--- a/src/doc/book/README.md
+++ b/src/doc/book/README.md
@@ -2,19 +2,16 @@
 
 [![Build Status](https://travis-ci.org/rust-lang/book.svg?branch=master)](https://travis-ci.org/rust-lang/book)
 
-This repository contains the source of all editions of "the Rust Programming
-Language".
+This repository contains the source of "The Rust Programming Language" book.
 
-The second edition will also be available in dead-tree form by No Starch
-Press, available around June 2018. Check [the No Starch Page][nostarch] for
-the latest information on the release date and how to order.
+[The book is available in dead-tree form from No Starch Press][nostarch]
 
 [nostarch]: https://nostarch.com/rust
 
-You can read all editions of the book for free online! Please see the book as
-shipped with the latest [stable], [beta], or [nightly] Rust releases. Be
-aware that issues in those versions may have been fixed in this repository
-already, as those releases are updated less frequently.
+You can also read the book for free online. Please see the book as shipped with
+the latest [stable], [beta], or [nightly] Rust releases. Be aware that issues
+in those versions may have been fixed in this repository already, as those
+releases are updated less frequently.
 
 [stable]: https://doc.rust-lang.org/stable/book/
 [beta]: https://doc.rust-lang.org/beta/book/
@@ -34,9 +31,7 @@ $ cargo install mdbook --vers [version-num]
 
 ## Building
 
-To build the book, first `cd` into the directory of the edition of the
-book you'd like to build. For example, the `first-edition` or
-`second-edition` directory. Then type:
+To build the book, type:
 
 ```bash
 $ mdbook build
@@ -72,57 +67,18 @@ $ mdbook test
 We'd love your help! Please see [CONTRIBUTING.md][contrib] to learn about the
 kinds of contributions we're looking for.
 
-### 2018 Edition
-
-The "2018" Edition is in the process of being updated with the language changes 
-that will be available with the 2018 Edition of the Rust language. All new 
-contributions should be to this edition.
-
-### Second Edition
-
-No Starch Press has brought the second edition to print. Pull requests fixing
-factual errors will be accepted and documented as errata; pull requests changing
-wording or other small corrections should be made against the 2018 edition instead.
-
-### First Edition
-
-The first edition is frozen, and is not accepting any changes at this time.
-
-
 [contrib]: https://github.com/rust-lang/book/blob/master/CONTRIBUTING.md
 
 ### Translations
 
-We'd especially love help translating the second edition or 2018 edition of the book! See the
-[Translations] label to join in efforts that are currently in progress. Open
-a new issue to start working on a new language! We're waiting on [mdbook
-support] for multiple languages before we merge any in, but feel free to
-start! The second edition is frozen and won't see major
-changes, so if you start with that, you won't have to redo work :)
+We'd love help translating the book! See the [Translations] label to join in
+efforts that are currently in progress. Open a new issue to start working on
+a new language! We're waiting on [mdbook support] for multiple languages
+before we merge any in, but feel free to start!
 
 [Translations]: https://github.com/rust-lang/book/issues?q=is%3Aopen+is%3Aissue+label%3ATranslations
 [mdbook support]: https://github.com/azerupi/mdBook/issues/5
 
-## No Starch
-
-As the second edition of the book will be published by No Starch, we first
-iterate here, then ship the text off to No Starch. Then they do editing, and we
-fold it back in.
-
-As such, there’s a directory, *nostarch*, which corresponds to the text in No
-Starch’s system.
-
-When we've started working with No Starch in a word doc, we will also check
-those into the repo in the *nostarch/odt* directory. To extract the text from
-the word doc as markdown in order to backport changes to the online book:
-
-1. Open the doc file in LibreOffice
-1. Accept all tracked changes
-1. Save as Microsoft Word 2007-2013 XML (.docx) in the *tmp* directory
-1. Run `./doc-to-md.sh`
-1. Inspect changes made to the markdown file in the *nostarch* directory and
-   copy the changes to the *src* directory as appropriate.
-
 ## Graphviz dot
 
 We're using [Graphviz](http://graphviz.org/) for some of the diagrams in the
diff --git a/src/doc/book/ci/build.sh b/src/doc/book/ci/build.sh
index ef3dadbd77..9ad1781381 100644
--- a/src/doc/book/ci/build.sh
+++ b/src/doc/book/ci/build.sh
@@ -1,18 +1,10 @@
-# Copyright 2016 The Rust Project Developers. See the COPYRIGHT
-# file at the top-level directory of this distribution and at
-# http://rust-lang.org/COPYRIGHT.
-#
-# Licensed under the Apache License, Version 2.0  or the MIT license
-# , at your
-# option. This file may not be copied, modified, or distributed
-# except according to those terms.
+#!/bin/bash
 
 set -e
 
 export PATH=$PATH:/home/travis/.cargo/bin;
 
-# feature check
+# Feature check
 cd ci/stable-check
 
 cargo run -- ../../src
diff --git a/src/doc/book/ci/dictionary.txt b/src/doc/book/ci/dictionary.txt
index e8d2d1f3d6..b4a4407c19 100644
--- a/src/doc/book/ci/dictionary.txt
+++ b/src/doc/book/ci/dictionary.txt
@@ -21,6 +21,8 @@ args
 associativity
 async
 atomics
+attr
+autocompletion
 AveragedCollection
 backend
 backported
@@ -28,7 +30,7 @@ backtrace
 backtraces
 BACKTRACE
 Backtraces
-Baz’s
+Baz's
 benchmarking
 bioinformatics
 bitand
@@ -49,6 +51,7 @@ Boolean
 Booleans
 Bors
 BorrowMutError
+BoxMeUp
 BTreeSet
 BuildHasher
 Cacher
@@ -62,12 +65,15 @@ charset
 choo
 chXX
 chYY
+clippy
+clippy's
 coercions
 combinator
 ConcreteType
 config
 Config
 const
+consts
 constant's
 copyeditor
 couldn
@@ -84,13 +90,16 @@ Ctrl
 customizable
 CustomSmartPointer
 CustomSmartPointers
-data’s
+data's
+DataStruct
 deallocate
 deallocated
 deallocating
 deallocation
 debuginfo
 decrementing
+deduplicate
+deduplicating
 deps
 deref
 Deref
@@ -134,10 +143,11 @@ Enums
 eprintln
 Erlang
 ErrorKind
-Executables
+executables
 expr
 extern
 favicon
+ferris
 FFFD
 FFFF
 figcaption
@@ -198,6 +208,7 @@ IndexMut
 indices
 init
 initializer
+initializers
 inline
 instantiation
 internet
@@ -207,6 +218,7 @@ invariants
 ioerror
 iokind
 ioresult
+IoResult
 iostdin
 IpAddr
 IpAddrKind
@@ -219,6 +231,7 @@ JoinHandle
 Kay's
 kinded
 lang
+LastWriteTime
 latin
 liballoc
 libc
@@ -271,7 +284,9 @@ Mutex
 mutexes
 Mutexes
 MutexGuard
+mutext
 MyBox
+myprogram
 namespace
 namespaced
 namespaces
@@ -306,6 +321,7 @@ other's
 OutlinePrint
 overloadable
 overread
+PanicPayload
 param
 parameterize
 ParseIntError
@@ -349,7 +365,9 @@ refactor
 refactoring
 refcell
 RefCell
+refcellt
 RefMut
+reformats
 refutability
 reimplement
 RemAssign
@@ -371,8 +389,10 @@ rUsT
 rustc
 rustdoc
 Rustonomicon
+rustfix
 rustfmt
 rustup
+sampleproject
 screenshot
 searchstring
 SecondaryColor
@@ -384,8 +404,10 @@ ShlAssign
 ShrAssign
 shouldn
 Simula
+siphash
 situps
 sizeof
+SliceIndex
 Smalltalk
 snuck
 someproject
@@ -411,6 +433,7 @@ Struct
 structs
 struct's
 Structs
+StrWrap
 SubAssign
 subclasses
 subcommand
@@ -425,6 +448,7 @@ substring
 subteams
 subtree
 subtyping
+summarizable
 supertrait
 supertraits
 TcpListener
@@ -463,6 +487,7 @@ unary
 Unary
 uncomment
 Uncomment
+uncommenting
 unevaluated
 Uninstalling
 uninstall
@@ -488,8 +513,10 @@ versa
 Versioning
 visualstudio
 Vlissides
+vscode
 vtable
 wasn
+weakt
 WeatherForecast
 WebSocket
 whitespace
diff --git a/src/doc/book/ci/spellcheck.sh b/src/doc/book/ci/spellcheck.sh
old mode 100644
new mode 100755
index fd3aa04e1d..f1c84a5f08
--- a/src/doc/book/ci/spellcheck.sh
+++ b/src/doc/book/ci/spellcheck.sh
@@ -1,17 +1,8 @@
 #!/bin/bash
-# Copyright 2016 The Rust Project Developers. See the COPYRIGHT
-# file at the top-level directory of this distribution and at
-# http://rust-lang.org/COPYRIGHT.
-#
-# Licensed under the Apache License, Version 2.0  or the MIT license
-# , at your
-# option. This file may not be copied, modified, or distributed
-# except according to those terms.
 
 aspell --version
 
-# Checks project markdown files for spell errors
+# Checks project Markdown files for spelling mistakes.
 
 # Notes:
 
@@ -41,18 +32,25 @@ aspell --version
 
 shopt -s nullglob
 
-dict_filename=./dictionary.txt
+dict_filename=./ci/dictionary.txt
 markdown_sources=(./src/*.md)
 mode="check"
 
-# aspell repeatedly modifies personal dictionary for some purpose,
-# so we should use a copy of our dictionary
-dict_path="/tmp/$dict_filename"
+# aspell repeatedly modifies the personal dictionary for some reason,
+# so we should use a copy of our dictionary.
+dict_path="/tmp/dictionary.txt"
 
 if [[ "$1" == "list" ]]; then
     mode="list"
 fi
 
+# Error if running in list (CI) mode and there isn't a dictionary file;
+# creating one in CI won't do any good :(
+if [[ "$mode" == "list" && ! -f "$dict_filename" ]]; then
+    echo "No dictionary file found! A dictionary file is required in CI!"
+    exit 1
+fi
+
 if [[ ! -f "$dict_filename" ]]; then
     # Pre-check mode: generates dictionary of words aspell consider typos.
     # After user validates that this file contains only valid words, we can
@@ -63,7 +61,7 @@ if [[ ! -f "$dict_filename" ]]; then
     echo "personal_ws-1.1 en 0 utf-8" > "$dict_filename"
     cat "${markdown_sources[@]}" | aspell --ignore 3 list | sort -u >> "$dict_filename"
 elif [[ "$mode" == "list" ]]; then
-    # List (default) mode: scan all files, report errors
+    # List (default) mode: scan all files, report errors.
     declare -i retval=0
 
     cp "$dict_filename" "$dict_path"
@@ -77,9 +75,9 @@ elif [[ "$mode" == "list" ]]; then
         command=$(aspell --ignore 3 --personal="$dict_path" "$mode" < "$fname")
         if [[ -n "$command" ]]; then
             for error in $command; do
-                # FIXME: Find more correct way to get line number
+                # FIXME: find more correct way to get line number
                 # (ideally from aspell). Now it can make some false positives,
-                # because it is just a grep
+                # because it is just a grep.
                 grep --with-filename --line-number --color=always "$error" "$fname"
             done
             retval=1
@@ -87,7 +85,7 @@ elif [[ "$mode" == "list" ]]; then
     done
     exit "$retval"
 elif [[ "$mode" == "check" ]]; then
-    # Interactive mode: fix typos
+    # Interactive mode: fix typos.
     cp "$dict_filename" "$dict_path"
 
     if [ ! -f $dict_path ]; then
diff --git a/src/doc/book/ci/stable-check/src/main.rs b/src/doc/book/ci/stable-check/src/main.rs
index fafc1015fd..167f1f883a 100644
--- a/src/doc/book/ci/stable-check/src/main.rs
+++ b/src/doc/book/ci/stable-check/src/main.rs
@@ -1,13 +1,3 @@
-// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
-// file at the top-level directory of this distribution and at
-// http://rust-lang.org/COPYRIGHT.
-//
-// Licensed under the Apache License, Version 2.0  or the MIT license
-// , at your
-// option. This file may not be copied, modified, or distributed
-// except according to those terms.
-
 use std::error::Error;
 use std::env;
 use std::fs;
diff --git a/src/doc/book/convert-quotes.sh b/src/doc/book/convert-quotes.sh
index 229be88921..aa51dcbddf 100755
--- a/src/doc/book/convert-quotes.sh
+++ b/src/doc/book/convert-quotes.sh
@@ -1,13 +1,4 @@
 #!/bin/bash
-# Copyright 2017 The Rust Project Developers. See the COPYRIGHT
-# file at the top-level directory of this distribution and at
-# http://rust-lang.org/COPYRIGHT.
-#
-# Licensed under the Apache License, Version 2.0  or the MIT license
-# , at your
-# option. This file may not be copied, modified, or distributed
-# except according to those terms.
 
 set -eu
 
diff --git a/src/doc/book/nostarch.sh b/src/doc/book/nostarch.sh
index 432add597c..6c4173a01c 100755
--- a/src/doc/book/nostarch.sh
+++ b/src/doc/book/nostarch.sh
@@ -1,13 +1,4 @@
 #!/bin/bash
-# Copyright 2016 The Rust Project Developers. See the COPYRIGHT
-# file at the top-level directory of this distribution and at
-# http://rust-lang.org/COPYRIGHT.
-#
-# Licensed under the Apache License, Version 2.0  or the MIT license
-# , at your
-# option. This file may not be copied, modified, or distributed
-# except according to those terms.
 
 set -eu
 
@@ -16,18 +7,18 @@ cargo build --release
 mkdir -p tmp
 rm -rf tmp/*.md
 
-# Get all the markdown files in the src dir,
+# Get all the Markdown files in the src dir,
 ls src/${1:-""}*.md | \
-# except for SUMMARY.md.
+# except for `SUMMARY.md`.
 grep -v SUMMARY.md | \
 # Extract just the filename so we can reuse it easily.
 xargs -n 1 basename | \
-# Remove all links followed by , then
-# Change all remaining links from markdown to italicized inline text.
+# Remove all links followed by ```, then
+# Change all remaining links from Markdown to italicized inline text.
 while IFS= read -r filename; do
   < "src/$filename" ./target/release/remove_links \
     | ./target/release/link2print \
     | ./target/release/remove_markup > "tmp/$filename"
 done
-# Concat the files into the nostarch dir.
+# Concatenate the files into the `nostarch` dir.
 ./target/release/concat_chapters tmp nostarch
diff --git a/src/doc/book/nostarch/appendix-a-new-section.md b/src/doc/book/nostarch/appendix-a-new-section.md
new file mode 100644
index 0000000000..9ec0c02665
--- /dev/null
+++ b/src/doc/book/nostarch/appendix-a-new-section.md
@@ -0,0 +1,55 @@
+This is a new section to appear at the end of Appendix A, after the "Keywords Reserved for Future Use" section.
+
+### Raw Identifiers
+
+*Raw identifiers* let you use keywords where they would not normally be allowed
+by prefixing them with `r#`.
+
+For example, `match` is a keyword. If you try to compile this function that
+uses `match` as its name:
+
+Filename: src/main.rs
+
+```
+fn match(needle: &str, haystack: &str) -> bool {
+    haystack.contains(needle)
+}
+```
+
+you’ll get this error:
+
+```
+error: expected identifier, found keyword `match`
+ --> src/main.rs:4:4
+  |
+4 | fn match(needle: &str, haystack: &str) -> bool {
+  |    ^^^^^ expected identifier, found keyword
+```
+
+The error says that you can't use the keyword `match` as the function
+identifier. You can use `match` as a function name by using a raw identifier:
+
+Filename: src/main.rs
+
+```
+fn r#match(needle: &str, haystack: &str) -> bool {
+    haystack.contains(needle)
+}
+
+fn main() {
+    assert!(r#match("foo", "foobar"));
+}
+```
+
+This code will compile without any errors. Note the `r#` prefix on both the
+function name in its definition as well as where the function is called in
+`main`.
+
+Raw identifiers allow you to use any word you choose as an identifier, even if
+that word happens to be a reserved keyword. In addition, raw identifiers allow
+you to use libraries written in a different Rust edition than your crate uses.
+For example, `try` is not a keyword in the 2015 edition but is in the 2018
+edition. If you depend on a library that is written using the 2015 edition and
+has a `try` function, to call that function from your 2018 edition code, you’ll
+need to use the raw identifier syntax, `r#try` in this case. See Appendix
+E for more information on editions.
diff --git a/src/doc/book/nostarch/chapter-03-integer-overflow-box.md b/src/doc/book/nostarch/chapter-03-integer-overflow-box.md
new file mode 100644
index 0000000000..07ba2483d0
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-03-integer-overflow-box.md
@@ -0,0 +1,21 @@
+Please place this text in a box after the "Integer Types" section ends and before the "Floating-Point Types" section begins on page 38.
+
+##### Integer Overflow
+
+Let’s say that you have a variable of type `u8`, which can hold values
+between 0 and 255. What happens if you try to change the variable's value to
+256? This is called *integer overflow*, and Rust has some interesting rules
+around this behavior. When compiling in debug mode, Rust includes checks for
+integer overflow that will cause your program to *panic* at runtime if integer
+overflow occurs. Panicking is the term Rust uses when a program exits with an
+error; we’ll discuss panics more in the "Unrecoverable Errors with `panic!`
+section" of Chapter 9 on page XX.
+
+When compiling in release mode with the `--release` flag, Rust does not
+include checks for integer overflow that cause panics. Instead, if overflow
+occurs, Rust will perform something called *two’s complement wrapping*. In
+short, values greater than the maximum value the type can hold "wrap around"
+to the minimum of the values the type can hold. In the case of a `u8`, 256
+becomes 0, 257 becomes 1, etc. Relying on the wrapping behavior of integer
+overflow is considered an error. If you want to wrap explicitly, the standard
+library has a type named `Wrapping` that provides this behavior.
diff --git a/src/doc/book/nostarch/chapter-03-new-array-text.md b/src/doc/book/nostarch/chapter-03-new-array-text.md
new file mode 100644
index 0000000000..b0dd4fc3ea
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-03-new-array-text.md
@@ -0,0 +1,25 @@
+Please add this text at the end of The Array Type section, just before the Accessing Array Elements subsection starts on page 41.
+
+Writing an array's type is done with square brackets containing the type of
+each element in the array followed by a semicolon and the number of elements in
+the array, like so:
+
+```rust
+let a: [i32; 5] = [1, 2, 3, 4, 5];
+```
+
+Here, `i32` is the type of each element. After the semicolon, the number `5`
+indicates the element contains five items.
+
+The way an array's type is written looks similar to an alternative syntax for
+initializing an array: if you want to create an array that contains the same
+value for each element, you can specify the initial value, then a semicolon,
+then the length of the array in square brackets as shown here:
+
+```rust
+let a = [3; 5];
+```
+
+The array named `a` will contain 5 elements that will all be set to the value
+`3` initially. This is the same as writing `let a = [3, 3, 3, 3, 3];` but in a
+more concise way.
diff --git a/src/doc/book/nostarch/chapter-03-returning-values-from-loops.md b/src/doc/book/nostarch/chapter-03-returning-values-from-loops.md
new file mode 100644
index 0000000000..8fa65a8538
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-03-returning-values-from-loops.md
@@ -0,0 +1,33 @@
+Please insert this new section after the "Repeating Code with loop" section ends and before the "Conditional Loops with while" section starts, on page 53.
+
+#### Returning Values From Loops
+
+One of the uses of a `loop` is to retry an operation you know can fail, such as
+checking if a thread completed its job. However, you might need to pass the
+result of that operation to the rest of your code. If you add the value you
+want to return after the `break` expression you use to stop the loop, it will
+be returned out of the loop so you can use the value, as shown here:
+
+```rust
+fn main() {
+    let mut counter = 0;
+
+    let result = loop {
+        counter += 1;
+
+        if counter == 10 {
+            break counter * 2;
+        }
+    };
+
+    println!("The result is {}", result);
+}
+```
+
+Before the loop, we declare a variable named `counter` and initialize it to
+zero. Then we declare a variable named `result` to hold the value returned from
+the loop. On every iteration of the loop, we add one to the counter variable,
+and then check if the counter is equal to ten. When it is, we use the `break`
+keyword with the value `counter * 2`. After the loop, we place a semicolon to
+end the statement assigning the value to `result`. Finally, we print out the
+value in `result`, which in this case will be twenty.
diff --git a/src/doc/book/nostarch/chapter-04-error-message-updates.md b/src/doc/book/nostarch/chapter-04-error-message-updates.md
new file mode 100644
index 0000000000..9b6292cb0b
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-04-error-message-updates.md
@@ -0,0 +1,49 @@
+Please view this file in monospace to see how the error messages should line up vertically.
+
+Here is the new error message for page 70, I've included the whole message for clarity:
+
+```
+error[E0499]: cannot borrow `s` as mutable more than once at a time
+ --> src/main.rs:5:14
+  |
+4 |     let r1 = &mut s;
+  |              ------ first mutable borrow occurs here
+5 |     let r2 = &mut s;
+  |              ^^^^^^ second mutable borrow occurs here
+6 |
+7 |     println!("{}, {}", r1, r2);
+  |                        -- first borrow later used here
+```
+
+For page 71:
+
+```
+error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
+ --> src/main.rs:6:14
+  |
+4 |     let r1 = &s; // no problem
+  |              -- immutable borrow occurs here
+5 |     let r2 = &s; // no problem
+6 |     let r3 = &mut s; // BIG PROBLEM
+  |              ^^^^^^ mutable borrow occurs here
+7 |
+8 |     println!("{}, {}, and {}", r1, r2, r3);
+  |                                -- immutable borrow later used here
+```
+
+For page 77:
+
+```
+error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
+  --> src/main.rs:18:5
+   |
+16 |     let word = first_word(&s);
+   |                           -- immutable borrow occurs here
+17 |
+18 |     s.clear(); // error!
+   |     ^^^^^^^^^ mutable borrow occurs here
+19 |
+20 |     println!("the first word is: {}", word);
+   |                                       ---- immutable borrow later used here
+```
+
diff --git a/src/doc/book/nostarch/chapter-04-stack-heap-box-edits.md b/src/doc/book/nostarch/chapter-04-stack-heap-box-edits.md
new file mode 100644
index 0000000000..91b77892f6
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-04-stack-heap-box-edits.md
@@ -0,0 +1,28 @@
+Please replace the paragraphs that start with "The stack is fast" and "Data with a size unknown" in the box on page 58 with this paragraph:
+
+---
+
+All data stored on the stack must have a known, fixed size. Data with a size
+that is unknown at compile time or a size that might change must be stored on
+the heap instead. The heap is less organized: when you put data on the heap,
+you ask for some amount of space. The operating system finds an empty spot
+somewhere in the heap that is big enough, marks it as being in use, and
+returns a *pointer*, which is the address of that location. This process is
+called *allocating on the heap*, sometimes abbreviated as just “allocating.”
+Pushing values onto the stack is not considered allocating. Because the
+pointer is a known, fixed size, you can store the pointer on the stack, but
+when you want the actual data, you have to follow the pointer.
+
+---
+
+Then please add this paragraph between the paragraph that starts with "Think of being seated at a restaurant" and the paragraph that starts with "Accessing data in the heap" on page 59:
+
+---
+
+Pushing to the stack is faster than allocating on the heap because it never
+has to search for a place to put new data; that place is always at the top
+of the stack. Comparatively, allocating space on the heap requires more work,
+because the operating system must first find a space big enough to hold the
+data and then perform bookkeeping to prepare for the next allocation.
+
+---
diff --git a/src/doc/book/nostarch/chapter-08-error-message-updates.md b/src/doc/book/nostarch/chapter-08-error-message-updates.md
new file mode 100644
index 0000000000..8a7e3b9943
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-08-error-message-updates.md
@@ -0,0 +1,15 @@
+Please replace the error message on page 133 with this one:
+
+```
+error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
+ --> src/main.rs:6:5
+  |
+4 |     let first = &v[0];
+  |                  - immutable borrow occurs here
+5 |
+6 |     v.push(6);
+  |     ^^^^^^^^^ mutable borrow occurs here
+7 |
+8 |     println!("The first element is: {}", first);
+  |                                          ----- immutable borrow later used here
+```
diff --git a/src/doc/book/nostarch/chapter-08-listing-8-5.md b/src/doc/book/nostarch/chapter-08-listing-8-5.md
new file mode 100644
index 0000000000..7af3c6acf4
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-08-listing-8-5.md
@@ -0,0 +1,13 @@
+Please replace the code in Listing 8-5 with this code:
+
+```
+let v = vec![1, 2, 3, 4, 5];
+
+let third: &i32 = &v[2];
+println!("The third element is {}", third);
+
+match v.get(2) {
+    Some(third) => println!("The third element is {}", third),
+    None => println!("There is no third element."),
+}
+```
\ No newline at end of file
diff --git a/src/doc/book/nostarch/chapter-09-error-message-updates.md b/src/doc/book/nostarch/chapter-09-error-message-updates.md
new file mode 100644
index 0000000000..51023b6996
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-09-error-message-updates.md
@@ -0,0 +1,43 @@
+Please use the following message instead of the error message on page 161.
+
+```
+error[E0277]: the `?` operator can only be used in a function that returns
+`Result` or `Option` (or another type that implements `std::ops::Try`)
+ --> src/main.rs:4:13
+  |
+4 |     let f = File::open("hello.txt")?;
+  |             ^^^^^^^^^^^^^^^^^^^^^^^^ cannot use the `?` operator in a
+  function that returns `()`
+  |
+  = help: the trait `std::ops::Try` is not implemented for `()`
+  = note: required by `std::ops::Try::from_error`
+```
+
+---
+
+Then, please replace the highlighted paragraph on page 161 with this text:
+
+This error points out that we’re only allowed to use the `?` operator in a
+function that returns `Result`. In functions that don’t return `Result`, when you call other functions that return `Result`, you’ll need to
+use a `match` or one of the `Result` methods to handle the `Result`
+instead of using the `?` operator to potentially propagate the error to the
+calling code.
+
+However, we can change how we write the `main` function so that it does return
+a `Result`:
+
+```
+use std::error::Error;
+use std::fs::File;
+
+fn main() -> Result<(), Box> {
+    let f = File::open("hello.txt")?;
+
+    Ok(())
+}
+```
+
+The `Box` type is called a “trait object,” which we’ll talk about in
+the “Using Trait Objects that Allow for Values of Different Types” section of
+Chapter 17. For now, you can read `Box` to mean “any kind of error.”
diff --git a/src/doc/book/nostarch/chapter-09-listing-9-2-update.md b/src/doc/book/nostarch/chapter-09-listing-9-2-update.md
new file mode 100644
index 0000000000..bef9dcde70
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-09-listing-9-2-update.md
@@ -0,0 +1,50 @@
+Please replace the text of Listing 9-2 on page 152-153 with this text:
+
+```
+$ RUST_BACKTRACE=1 cargo run
+    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
+     Running `target/debug/panic`
+thread 'main' panicked at 'index out of bounds: the len is 3 but the index is 99', libcore/slice/mod.rs:2448:10
+stack backtrace:
+   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
+             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
+   1: std::sys_common::backtrace::print
+             at libstd/sys_common/backtrace.rs:71
+             at libstd/sys_common/backtrace.rs:59
+   2: std::panicking::default_hook::{{closure}}
+             at libstd/panicking.rs:211
+   3: std::panicking::default_hook
+             at libstd/panicking.rs:227
+   4:  as core::panic::BoxMeUp>::get
+             at libstd/panicking.rs:476
+   5: std::panicking::continue_panic_fmt
+             at libstd/panicking.rs:390
+   6: std::panicking::try::do_call
+             at libstd/panicking.rs:325
+   7: core::ptr::drop_in_place
+             at libcore/panicking.rs:77
+   8: core::ptr::drop_in_place
+             at libcore/panicking.rs:59
+   9: >::index
+             at libcore/slice/mod.rs:2448
+  10: core::slice:: for [T]>::index
+             at libcore/slice/mod.rs:2316
+  11:  as core::ops::index::Index>::index
+             at liballoc/vec.rs:1653
+  12: panic::main
+             at src/main.rs:4
+  13: std::rt::lang_start::{{closure}}
+             at libstd/rt.rs:74
+  14: std::panicking::try::do_call
+             at libstd/rt.rs:59
+             at libstd/panicking.rs:310
+  15: macho_symbol_search
+             at libpanic_unwind/lib.rs:102
+  16: std::alloc::default_alloc_error_hook
+             at libstd/panicking.rs:289
+             at libstd/panic.rs:392
+             at libstd/rt.rs:58
+  17: std::rt::lang_start
+             at libstd/rt.rs:74
+  18: panic::main
+```
diff --git a/src/doc/book/nostarch/chapter-09-listing-9-5-update.md b/src/doc/book/nostarch/chapter-09-listing-9-5-update.md
new file mode 100644
index 0000000000..c5163cd632
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-09-listing-9-5-update.md
@@ -0,0 +1,21 @@
+Please replace the text of Listing 9-5 on page 156 with this text:
+
+```
+use std::fs::File;
+use std::io::ErrorKind;
+
+fn main() {
+    let f = File::open("hello.txt");
+
+    let f = match f {
+        Ok(file) => file,
+        Err(error) => match error.kind() {
+            ErrorKind::NotFound => match File::create("hello.txt") {
+                Ok(fc) => fc,
+                Err(e) => panic!("Tried to create file but there was a problem: {:?}", e),
+            },
+            other_error => panic!("There was a problem opening the file: {:?}", other_error),
+        },
+    };
+}
+```
\ No newline at end of file
diff --git a/src/doc/book/nostarch/chapter-09-match-update.md b/src/doc/book/nostarch/chapter-09-match-update.md
new file mode 100644
index 0000000000..f179ba9a47
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-09-match-update.md
@@ -0,0 +1,37 @@
+Please enter this text to replace the highlighted text that starts with "However," at the bottom of page 156 and top of page 157.
+
+---
+
+However, because `File::create` could also fail, we need a second arm in the
+inner `match` expression. When the file can’t be created, a different error
+message will be printed. The second arm of the outer `match` stays the same so
+the program panics on any error besides the missing file error.
+
+That’s a lot of `match`! The `match` expression is very useful, but also very
+much a primitive. In Chapter 13, we’ll learn about closures. The `Result`
+type has many methods that accept a closure and are implemented using `match`
+expressions, and using those methods will make your code more concise. A more
+seasoned Rustacean might write this code instead of Listing 9-5:
+
+```
+use std::fs::File;
+use std::io::ErrorKind;
+
+fn main() {
+    let f = File::open("hello.txt").unwrap_or_else(|error| {
+        if error.kind() == ErrorKind::NotFound {
+            File::create("hello.txt").unwrap_or_else(|error| {
+                panic!("Tried to create file but there was a problem: {:?}", error);
+            })
+        } else {
+            panic!("There was a problem opening the file: {:?}", error);
+        }
+    });
+}
+```
+
+This code has the same behavior as that of Listing 9-5 but doesn't contain any
+`match` expressions and is a bit cleaner to read. Come back to this example
+after you’ve read Chapter 13, and look up the `unwrap_or_else` method in the
+standard library documentation. There’s many more of these methods that can
+clean up huge nested `match` expressions when dealing with errors.
diff --git a/src/doc/book/nostarch/chapter-09-read-to-string-update.md b/src/doc/book/nostarch/chapter-09-read-to-string-update.md
new file mode 100644
index 0000000000..5e1f003b01
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-09-read-to-string-update.md
@@ -0,0 +1,25 @@
+Please insert this text after the paragraph ending in "ergonomic way to write it" on page 160.
+
+---
+
+Speaking of different ways to write this function, there’s a way to make this
+even shorter, shown in Listing 9-9.
+
+Filename: src/main.rs
+
+```
+use std::io;
+use std::fs;
+
+fn read_username_from_file() -> Result {
+    fs::read_to_string("hello.txt")
+}
+```
+
+Listing 9-9: Using `fs::read_to_string` instead of opening then reading the file
+
+Reading a file into a string is a fairly common operation, so Rust provides a
+convenience function called `fs::read_to_string` that will open the file,
+create a new `String`, read the contents of the file, put the contents into
+that `String`, and return it. Of course, this doesn’t give us the opportunity
+to explain all the error handling, so we did it the longer way first.
\ No newline at end of file
diff --git a/src/doc/book/nostarch/chapter-12-error-message-updates.md b/src/doc/book/nostarch/chapter-12-error-message-updates.md
new file mode 100644
index 0000000000..d6e2138485
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-12-error-message-updates.md
@@ -0,0 +1,12 @@
+Please change the error output on page 242 to this:
+
+```
+warning: unused `std::result::Result` that must be used
+  --> src/main.rs:17:5
+   |
+17 |     run(config);
+   |     ^^^^^^^^^^^^
+   |
+   = note: #[warn(unused_must_use)] on by default
+   = note: this `Result` may be an `Err` variant, which should be handled
+```
diff --git a/src/doc/book/nostarch/chapter-15-code-updates.md b/src/doc/book/nostarch/chapter-15-code-updates.md
new file mode 100644
index 0000000000..14227da19f
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-15-code-updates.md
@@ -0,0 +1,11 @@
+Please replace the "if... else if... else if" block highlighted on page 326 with this code, indented the same way as the old code was:
+
+```
+        if percentage_of_max >= 1.0 {
+            self.messenger.send("Error: You are over your quota!");
+        } else if percentage_of_max >= 0.9 {
+             self.messenger.send("Urgent warning: You've used up over 90% of your quota!");
+        } else if percentage_of_max >= 0.75 {
+            self.messenger.send("Warning: You've used up over 75% of your quota!");
+        }
+```
\ No newline at end of file
diff --git a/src/doc/book/nostarch/chapter-15-error-message-updates.md b/src/doc/book/nostarch/chapter-15-error-message-updates.md
new file mode 100644
index 0000000000..d9cb2fe552
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-15-error-message-updates.md
@@ -0,0 +1,12 @@
+Please change the output on page 312 to this output:
+
+```
+error[E0277]: can't compare `{integer}` with `&{integer}`
+ --> src/main.rs:6:5
+  |
+6 |     assert_eq!(5, y);
+  |     ^^^^^^^^^^^^^^^^^ no implementation for `{integer} == &{integer}`
+  |
+  = help: the trait `std::cmp::PartialEq<&{integer}>` is not implemented for
+  `{integer}`
+```
\ No newline at end of file
diff --git a/src/doc/book/nostarch/chapter-18-destructuring-nested-structs-and-enums.md b/src/doc/book/nostarch/chapter-18-destructuring-nested-structs-and-enums.md
new file mode 100644
index 0000000000..054cf4e2e9
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-18-destructuring-nested-structs-and-enums.md
@@ -0,0 +1,54 @@
+#### Destructuring Nested Structs and Enums
+
+Up until now, all of our examples have been matching structs or enums that were
+one level deep. Matching can work on nested items too!
+
+For example, we can refactor the code in Listing 18-15 to support both RGB and
+HSV colors in the `ChangeColor` message, as shown in Listing 18-16.
+
+```rust
+enum Color {
+   Rgb(i32, i32, i32),
+   Hsv(i32, i32, i32)
+}
+
+enum Message {
+    Quit,
+    Move { x: i32, y: i32 },
+    Write(String),
+    ChangeColor(Color),
+}
+
+fn main() {
+    let msg = Message::ChangeColor(Color::Hsv(0, 160, 255));
+
+    match msg {
+        Message::ChangeColor(Color::Rgb(r, g, b)) => {
+            println!(
+                "Change the color to red {}, green {}, and blue {}",
+                r,
+                g,
+                b
+            )
+        },
+        Message::ChangeColor(Color::Hsv(h, s, v)) => {
+            println!(
+                "Change the color to hue {}, saturation {}, and value {}",
+                h,
+                s,
+                v
+            )
+        }
+        _ => ()
+    }
+}
+```
+
+Listing 18-16: Matching on nested enums
+
+The pattern of the first arm in the `match` expression matches a
+`Message::ChangeColor` enum variant that contains a `Color::Rgb` variant, and
+then the pattern binds to the three inner `i32` values. The pattern of the
+second arm also matches a `Message::ChangeColor` enum variant, but the inner
+enum matches the `Color::Hsv` variant instead. We can specify these complex
+conditions in one `match` expression even though two enums are involved.
\ No newline at end of file
diff --git a/src/doc/book/nostarch/chapter-19-new-function-pointer-text.md b/src/doc/book/nostarch/chapter-19-new-function-pointer-text.md
new file mode 100644
index 0000000000..6791ae5c09
--- /dev/null
+++ b/src/doc/book/nostarch/chapter-19-new-function-pointer-text.md
@@ -0,0 +1,30 @@
+Please add this text at the end of the Function Pointers section, just before
+the Returning Closures section starts, so at the end of page 447 and before
+page 448.
+
+---
+
+Another useful pattern exploits an implementation detail of tuple structs and
+tuple-struct enum variants. These items use `()` as initializer syntax, which
+looks like a function call. The initializers are actually implemented as
+functions returning an instance constructed from their arguments. These
+initializer functions can also be used as a function pointer that implements
+the closure traits, so they can also be specified as arguments for methods that
+take closures:
+
+```
+enum Status {
+    Value(u32),
+    Stop,
+}
+
+let list_of_statuses: Vec =
+    (0u32..20)
+    .map(Status::Value)
+    .collect();
+```
+
+This code creates `Status::Value` instances using each `u32` value in the range
+that `map` is called on by using the initializer function of `Status::Value`.
+Some people prefer this style, and some people prefer to use closures. They end
+up compiling to the same code, so use whichever style is clearer to you.
diff --git a/src/doc/book/nostarch/chapter07.md b/src/doc/book/nostarch/chapter07.md
index 21aa3b0c77..f44156d6e5 100644
--- a/src/doc/book/nostarch/chapter07.md
+++ b/src/doc/book/nostarch/chapter07.md
@@ -139,12 +139,12 @@ called crate roots because the contents of either of these two files form a
 module named `crate` at the root of the crate’s module tree. So in Listing 7-2,
 we have a module tree that looks like Listing 7-3:
 
-```
+```text
 crate
- └── sound
-     └── instrument
-        └── woodwind
-     └── voice
+└── sound
+    ├── instrument
+    │   └── woodwind
+    └── voice
 ```
 
 Listing 7-3: The module tree for the code in Listing 7-2
diff --git a/src/doc/book/nostarch/chapter10-traits-as-parameters.md b/src/doc/book/nostarch/chapter10-traits-as-parameters.md
new file mode 100644
index 0000000000..7ecccea66a
--- /dev/null
+++ b/src/doc/book/nostarch/chapter10-traits-as-parameters.md
@@ -0,0 +1,171 @@
+Please replace the "Trait Bounds" section on page 182-183 with this text, which should then be followed by the existing "Fixing the largest Function with Trait Bounds" section.
+
+---
+
+### Traits as Parameters
+
+Now that you know how to define traits and implement those traits on types, we
+can explore how to use traits to define functions that accept many different
+types.
+
+For example, in Listing 10-13, we implemented the `Summary` trait on the types
+`NewsArticle` and `Tweet`. We can define a function `notify` that calls the
+`summarize` method on its parameter `item`, which is of some type that
+implements the `Summary` trait. To do this, we can use the `impl Trait` syntax,
+like this:
+
+```
+pub fn notify(item: impl Summary) {
+    println!("Breaking news! {}", item.summarize());
+}
+```
+
+Instead of a concrete type for the `item` parameter, we specify the `impl`
+keyword and the trait that the type passed as an argument must implement. In
+the body of `notify`, we can call any methods on `item` that come from the
+`Summary` trait, like `summarize`. We can call `notify` and pass in any
+instance of `NewsArticle` or `Tweet`. Code that calls the function with any
+other type, like a `String` or an `i32`, won’t compile, because those types
+don’t implement `Summary`.
+
+#### Trait Bound Syntax
+
+The `impl Trait` syntax works for straightforward cases, but is syntax sugar
+for a longer form. The longer syntax is called a *trait bound*, and it looks
+like this:
+
+```
+pub fn notify(item: T) {
+    println!("Breaking news! {}", item.summarize());
+}
+```
+
+This is equivalent to the example above, but is a bit more verbose. We place
+trait bounds with the declaration of the generic type parameter, after a
+colon and inside angle brackets.
+
+The `impl Trait` syntax is convenient and makes for more concise code in
+straightforward cases. The trait bound syntax is able to express more
+complexity in other cases. For example, to have two parameters that implement
+`Summary`, the `impl Trait` syntax would look like this:
+
+```
+pub fn notify(item1: impl Summary, item2: impl Summary) {
+```
+
+Defining this function using `impl Trait` would be appropriate if `item1` and
+`item2` were allowed to have different types (as long as both types implement
+`Summary`). If you wanted to force both parameters to have the exact same type,
+that is only possible to express with a trait bound:
+
+```
+pub fn notify(item1: T, item2: T) {
+```
+
+The generic type `T` specified as the type of the `item1` and `item2`
+parameters constrains the function such that the concrete type of the value
+passed as an argument for `item1` and `item2` must be the same.
+
+#### Specifying Multiple Trait Bounds with the `+` Syntax
+
+If `notify` needed to use display formatting on `item` as well as the
+`summarize` method, then the `notify` definition specifies that `item` must
+implement two traits: `Display` and `Summary`. This can be done using the `+`
+syntax:
+
+```
+pub fn notify(item: impl Summary + Display) {
+```
+
+The `+` syntax is also valid with trait bounds on generic types:
+
+```
+pub fn notify(item: T) {
+```
+
+With the two trait bounds specified, the body of `notify` can call `summarize`
+and use `{}` to format `item`.
+
+#### Clearer Trait Bounds with `where` Clauses
+
+There are downsides to using too many trait bounds. Each generic has its own
+trait bounds, so functions with multiple generic type parameters can have lots
+of trait bound information between a function’s name and its parameter list,
+making the function signature hard to read. For this reason, Rust has alternate
+syntax for specifying trait bounds inside a `where` clause after the function
+signature. So instead of writing this:
+
+```
+fn some_function(t: T, u: U) -> i32 {
+```
+
+we can use a `where` clause, like this:
+
+```
+fn some_function(t: T, u: U) -> i32
+    where T: Display + Clone,
+          U: Clone + Debug
+{
+```
+
+This function’s signature is less cluttered in that the function name,
+parameter list, and return type are close together, similar to a function
+without lots of trait bounds.
+
+### Returning Types that Implement Traits
+
+We can use the `impl Trait` syntax in return position as well, to return
+a value of some type that implements a trait:
+
+```
+fn returns_summarizable() -> impl Summary {
+    Tweet {
+        username: String::from("horse_ebooks"),
+        content: String::from("of course, as you probably already know, people"),
+        reply: false,
+        retweet: false,
+    }
+}
+```
+
+The `impl Summary` return type means that the `returns_summarizable` function
+returns some type that implements the `Summary` trait, but doesn't specify the
+concrete type. In this case, `returns_summarizable` returns a `Tweet`, but the
+code calling this function doesn’t know that.
+
+Returning a type that is only specified by the trait it implements is
+especially useful in the context of closures and iterators, which we'll be
+covering in Chapter 13. Closures and iterators create types that only the
+compiler knows or types that are very long to specify. `impl Trait` lets you
+concisely specify that a function returns some type that implements the
+`Iterator` trait without needing to write out a really long type.
+
+However, using `impl Trait` is only allowed if you have a single type that
+you’re returning. For example, this code returning either a `NewsArticle` or a
+`Tweet` with the return type specified as `impl Summary` would *not* work:
+
+```
+fn returns_summarizable(switch: bool) -> impl Summary {
+    if switch {
+        NewsArticle {
+            headline: String::from("Penguins win the Stanley Cup Championship!"),
+            location: String::from("Pittsburgh, PA, USA"),
+            author: String::from("Iceburgh"),
+            content: String::from("The Pittsburgh Penguins once again are the best
+            hockey team in the NHL."),
+        }
+    } else {
+        Tweet {
+            username: String::from("horse_ebooks"),
+            content: String::from("of course, as you probably already know, people"),
+            reply: false,
+            retweet: false,
+        }
+    }
+}
+```
+
+Returning either a `NewsArticle` or a `Tweet` isn't allowed due to restrictions
+around how `impl Trait` is implemented. We'll cover how to write a function
+with this behavior in the “Using Trait Objects That Allow for Values of
+Different Types” section on page XX [chapter 17].
diff --git a/src/doc/book/nostarch/chapter11-using-result-in-tests.md b/src/doc/book/nostarch/chapter11-using-result-in-tests.md
new file mode 100644
index 0000000000..a4a18c3c4c
--- /dev/null
+++ b/src/doc/book/nostarch/chapter11-using-result-in-tests.md
@@ -0,0 +1,35 @@
+Please insert this text on page 215 between the last two paragraphs before the "Controlling how tests are run" section.
+
+---
+
+### Using `Result` in Tests
+
+So far, we’ve written tests that panic when they fail. We can also write tests
+that use `Result`! Here’s the test from Listing 11-1, rewritten to use
+`Result` instead of panicking:
+
+```rust
+#[cfg(test)]
+mod tests {
+    #[test]
+    fn it_works() -> Result<(), String> {
+        if 2 + 2 == 4 {
+            Ok(())
+        } else {
+            Err(String::from("two plus two does not equal four"))
+        }
+    }
+}
+```
+
+The `it_works` function now has a return type, `Result<(), String>`. In the
+body of the function, rather than call the `assert_eq!` macro, we return
+`Ok(())` when the test passes and an `Err` with a `String` inside when the test
+fails. Writing tests that return a `Result` enables you to use the
+question mark operator in the body of tests, which can be a convenient way to
+write tests that should fail if any operation within them returns an `Err`
+variant.
+
+You can't use the `#[should_panic]` annotation on tests that use `Result`. Instead, you should return an `Err` value directly when the test should
+fail.
\ No newline at end of file
diff --git a/src/doc/book/nostarch/version-note.md b/src/doc/book/nostarch/version-note.md
new file mode 100644
index 0000000000..60538cea55
--- /dev/null
+++ b/src/doc/book/nostarch/version-note.md
@@ -0,0 +1,9 @@
+Somewhere in the frontmatter, possibly just before the introduction? we'd like the following note about the version and edition of Rust used for this printing of the book. We're open to other locations if you think somewhere else would be best.
+
+## Note on Rust Version and Edition
+
+This version of the text assumes you are using Rust 1.31.0 or later, with
+`edition="2018"` in *Cargo.toml* of all projects to use Rust 2018 Edition
+idioms. See the "Installation" section of Chapter 1 on page XX to install or
+update Rust, and see Appendix E on page XX for information on what editions of
+Rust are.
diff --git a/src/doc/book/redirects/attributes.md b/src/doc/book/redirects/attributes.md
index ee6b23038a..812cbbcd33 100644
--- a/src/doc/book/redirects/attributes.md
+++ b/src/doc/book/redirects/attributes.md
@@ -16,7 +16,7 @@ fn test_foo() {
 
 Here are the relevant sections in the new and old books:
 
-* **[In the Rust Reference: Ch 5.3 — Attributes][2]**
+* **[In the Rust Reference: Ch 6.5 — Attributes][2]**
 * [In the first edition: Ch 3.27 — Attributes][1]
 
 
diff --git a/src/doc/book/redirects/release-channels.md b/src/doc/book/redirects/release-channels.md
index c38ac413c9..6e01e227fe 100644
--- a/src/doc/book/redirects/release-channels.md
+++ b/src/doc/book/redirects/release-channels.md
@@ -24,5 +24,5 @@ You can check out other resources that describe release channels.
 [2]: appendix-07-nightly-rust.html
 [3]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
 [4]: https://github.com/rust-lang-nursery/rustup.rs/blob/master/README.md#keeping-rust-up-to-date
-[5]: https://www.rust-lang.org/en-US/install.html
+[5]: https://www.rust-lang.org/en-US/tools/install
 
diff --git a/src/doc/book/second-edition/convert-quotes.sh b/src/doc/book/second-edition/convert-quotes.sh
index 229be88921..aa51dcbddf 100644
--- a/src/doc/book/second-edition/convert-quotes.sh
+++ b/src/doc/book/second-edition/convert-quotes.sh
@@ -1,13 +1,4 @@
 #!/bin/bash
-# Copyright 2017 The Rust Project Developers. See the COPYRIGHT
-# file at the top-level directory of this distribution and at
-# http://rust-lang.org/COPYRIGHT.
-#
-# Licensed under the Apache License, Version 2.0  or the MIT license
-# , at your
-# option. This file may not be copied, modified, or distributed
-# except according to those terms.
 
 set -eu
 
diff --git a/src/doc/book/second-edition/doc-to-md.sh b/src/doc/book/second-edition/doc-to-md.sh
index 259d6f02f0..170727db9f 100644
--- a/src/doc/book/second-edition/doc-to-md.sh
+++ b/src/doc/book/second-edition/doc-to-md.sh
@@ -1,29 +1,20 @@
 #!/bin/bash
-# Copyright 2016 The Rust Project Developers. See the COPYRIGHT
-# file at the top-level directory of this distribution and at
-# http://rust-lang.org/COPYRIGHT.
-#
-# Licensed under the Apache License, Version 2.0  or the MIT license
-# , at your
-# option. This file may not be copied, modified, or distributed
-# except according to those terms.
 
 set -eu
 
-# Get all the docx files in the tmp dir,
+# Get all the docx files in the tmp dir.
 ls tmp/*.docx | \
 # Extract just the filename so we can reuse it easily.
 xargs -n 1 basename -s .docx | \
 while IFS= read -r filename; do
-  # Make a directory to put the XML in
-  mkdir -p "tmp/$filename"
-  # Unzip the docx to get at the xml
-  unzip -o "tmp/$filename.docx" -d "tmp/$filename"
-  # Convert to markdown with XSL
-  xsltproc tools/docx-to-md.xsl "tmp/$filename/word/document.xml" | \
-  # Hard wrap at 80 chars at word bourdaries
-  fold -w 80 -s | \
-  # Remove trailing whitespace & save in the nostarch dir for comparison
-  sed -e "s/ *$//" > "nostarch/$filename.md"
+    # Make a directory to put the XML in.
+    mkdir -p "tmp/$filename"
+    # Unzip the docx to get at the XML.
+    unzip -o "tmp/$filename.docx" -d "tmp/$filename"
+    # Convert to markdown with XSL.
+    xsltproc tools/docx-to-md.xsl "tmp/$filename/word/document.xml" | \
+    # Hard wrap at 80 chars at word bourdaries.
+    fold -w 80 -s | \
+    # Remove trailing whitespace and save in the `nostarch` dir for comparison.
+    sed -e "s/ *$//" > "nostarch/$filename.md"
 done
diff --git a/src/doc/book/second-edition/nostarch.sh b/src/doc/book/second-edition/nostarch.sh
index 432add597c..6c4173a01c 100644
--- a/src/doc/book/second-edition/nostarch.sh
+++ b/src/doc/book/second-edition/nostarch.sh
@@ -1,13 +1,4 @@
 #!/bin/bash
-# Copyright 2016 The Rust Project Developers. See the COPYRIGHT
-# file at the top-level directory of this distribution and at
-# http://rust-lang.org/COPYRIGHT.
-#
-# Licensed under the Apache License, Version 2.0  or the MIT license
-# , at your
-# option. This file may not be copied, modified, or distributed
-# except according to those terms.
 
 set -eu
 
@@ -16,18 +7,18 @@ cargo build --release
 mkdir -p tmp
 rm -rf tmp/*.md
 
-# Get all the markdown files in the src dir,
+# Get all the Markdown files in the src dir,
 ls src/${1:-""}*.md | \
-# except for SUMMARY.md.
+# except for `SUMMARY.md`.
 grep -v SUMMARY.md | \
 # Extract just the filename so we can reuse it easily.
 xargs -n 1 basename | \
-# Remove all links followed by , then
-# Change all remaining links from markdown to italicized inline text.
+# Remove all links followed by ```, then
+# Change all remaining links from Markdown to italicized inline text.
 while IFS= read -r filename; do
   < "src/$filename" ./target/release/remove_links \
     | ./target/release/link2print \
     | ./target/release/remove_markup > "tmp/$filename"
 done
-# Concat the files into the nostarch dir.
+# Concatenate the files into the `nostarch` dir.
 ./target/release/concat_chapters tmp nostarch
diff --git a/src/doc/book/second-edition/nostarch/appendix.md b/src/doc/book/second-edition/nostarch/appendix.md
deleted file mode 100644
index c682b83179..0000000000
--- a/src/doc/book/second-edition/nostarch/appendix.md
+++ /dev/null
@@ -1,927 +0,0 @@
-
-[TOC]
-
-## Appendix A: Keywords
-
-The following list contains keywords that are reserved for current or future
-use by the Rust language. As such, they cannot be used as identifiers, such as
-names of functions, variables, parameters, struct fields, modules, crates,
-constants, macros, static values, attributes, types, traits, or lifetimes.
-
-### Keywords Currently in Use
-
-* `as` - perform primitive casting, disambiguate the specific trait containing
-  an item, or rename items in `use` and `extern crate` statements
-* `break` - exit a loop immediately
-* `const` - define constant items or constant raw pointers
-* `continue` - continue to the next loop iteration
-* `crate` - link an external crate or a macro variable representing the crate in
-  which the macro is defined
-* `else` - fallback for `if` and `if let` control flow constructs
-* `enum` - define an enumeration
-* `extern` - link an external crate, function, or variable
-* `false` - Boolean false literal
-* `fn` - define a function or the function pointer type
-* `for` - loop over items from an iterator, implement a trait, or specify a
-  higher-ranked lifetime
-* `if` - branch based on the result of a conditional expression
-* `impl` - implement inherent or trait functionality
-* `in` - part of `for` loop syntax
-* `let` - bind a variable
-* `loop` - loop unconditionally
-* `match` - match a value to patterns
-* `mod` - define a module
-* `move` - make a closure take ownership of all its captures
-* `mut` - denote mutability in references, raw pointers, or pattern bindings
-* `pub` - denote public visibility in struct fields, `impl` blocks, or modules
-* `ref` - bind by reference
-* `return` - return from function
-* `Self` - a type alias for the type implementing a trait
-* `self` - method subject or current module
-* `static` - global variable or lifetime lasting the entire program execution
-* `struct` - define a structure
-* `super` - parent module of the current module
-* `trait` - define a trait
-* `true` - Boolean true literal
-* `type` - define a type alias or associated type
-* `unsafe` - denote unsafe code, functions, traits, or implementations
-* `use` - import symbols into scope
-* `where` - denote clauses that constrain a type
-* `while` - loop conditionally based on the result of an expression
-
-### Keywords Reserved for Future Use
-
-The following keywords do not have any functionality but are reserved by Rust
-for potential future use.
-
-* `abstract`
-* `alignof`
-* `become`
-* `box`
-* `do`
-* `final`
-* `macro`
-* `offsetof`
-* `override`
-* `priv`
-* `proc`
-* `pure`
-* `sizeof`
-* `typeof`
-* `unsized`
-* `virtual`
-* `yield`
-
-## Appendix B: Operators and Symbols
-
-This appendix contains a glossary of Rust’s syntax, including operators and
-other symbols that appear by themselves or in the context of paths, generics,
-trait bounds, macros, attributes, comments, tuples, and brackets.
-
-### Operators
-
-The following list contains the operators in Rust, an example of how the
-operator would appear in context, a short explanation, and whether that
-operator is overloadable. If an operator is overloadable, the relevant trait to
-use to overload that operator is listed.
-
-
-* `!` (`ident!(...)`, `ident!{...}`, `ident![...]`): denotes macro
-expansion.
-* `!` (`!expr`): bitwise or logical complement. Overloadable (`Not`).
-* `!=` (`var != expr`): nonequality comparison. Overloadable (`PartialEq`).
-* `%` (`expr % expr`): arithmetic remainder. Overloadable (`Rem`).
-* `%=` (`var %= expr`): arithmetic remainder and assignment. Overloadable
-(`RemAssign`).
-* `&` (`&expr`, `&mut expr`): borrow.
-* `&` (`&type`, `&mut type`, `&'a type`, `&'a mut type`): borrowed pointer type.
-* `&` (`expr & expr`): bitwise AND. Overloadable (`BitAnd`).
-* `&=` (`var &= expr`): bitwise AND and assignment. Overloadable
-(`BitAndAssign`).
-* `&&` (`expr && expr`): logical AND.
-* `*` (`expr * expr`): arithmetic multiplication. Overloadable (`Mul`).
-* `*` (`*expr`): dereference.
-* `*` (`*const type`, `*mut type`): raw pointer.
-* `*=` (`var *= expr`): arithmetic multiplication and assignment. Overloadable
-(`MulAssign`).
-* `+` (`trait + trait`, `'a + trait`): compound type constraint.
-* `+` (`expr + expr`): arithmetic addition. Overloadable (`Add`).
-* `+=` (`var += expr`): arithmetic addition and assignment. Overloadable
-(`AddAssign`).
-* `,`: argument and element separator.
-* `-` (`- expr`): arithmetic negation. Overloadable (`Neg`).
-* `-` (`expr - expr`): arithmetic subtraction. Overloadable (`Sub`).
-* `-=` (`var -= expr`): arithmetic subtraction and assignment. Overloadable
-(`SubAssign`).
-* `->` (`fn(...) -> type`, `|...| -> type`): function and closure
-return type.
-* `.` (`expr.ident`): member access.
-* `..` (`..`, `expr..`, `..expr`, `expr..expr`): right-exclusive range literal.
-* `..` (`..expr`): struct literal update syntax.
-* `..` (`variant(x, ..)`, `struct_type { x, .. }`): “and the rest” pattern
-binding.
-* `...` (`expr...expr`) *in a pattern*: inclusive range pattern.
-* `/` (`expr / expr`): arithmetic division. Overloadable (`Div`).
-* `/=` (`var /= expr`): arithmetic division and assignment. Overloadable
-(`DivAssign`).
-* `:` (`pat: type`, `ident: type`): constraints.
-* `:` (`ident: expr`): struct field initializer.
-* `:` (`'a: loop {...}`): loop label.
-* `;`: statement and item terminator.
-* `;` (`[...; len]`): part of fixed-size array syntax
-* `<<` (`expr << expr`): left-shift. Overloadable (`Shl`).
-* `<<=` (`var <<= expr`): left-shift and assignment. Overloadable (`ShlAssign`).
-* `<` (`expr < expr`): less-than comparison. Overloadable (`PartialOrd`).
-* `<=` (`expr <= expr`): less-than or equal-to comparison. Overloadable
-(`PartialOrd`).
-* `=` (`var = expr`, `ident = type`): assignment/equivalence.
-* `==` (`expr == expr`): equality comparison. Overloadable (`PartialEq`).
-* `=>` (`pat => expr`): part of match arm syntax.
-* `>` (`expr > expr`): greater-than comparison. Overloadable (`PartialOrd`).
-* `>=` (`expr >= expr`): greater-than or equal-to comparison. Overloadable
-(`PartialOrd`).
-* `>>` (`expr >> expr`): right-shift. Overloadable (`Shr`).
-* `>>=` (`var >>= expr`): right-shift and assignment. Overloadable
-(`ShrAssign`).
-* `@` (`ident @ pat`): pattern binding.
-* `^` (`expr ^ expr`): bitwise exclusive OR. Overloadable (`BitXor`).
-* `^=` (`var ^= expr`): bitwise exclusive OR and assignment. Overloadable
-(`BitXorAssign`).
-* `|` (`pat | pat`): pattern alternatives.
-* `|` (`|…| expr`): closures.
-* `|` (`expr | expr`): bitwise OR. Overloadable (`BitOr`).
-* `|=` (`var |= expr`): bitwise OR and assignment. Overloadable (`BitOrAssign`).
-* `||` (`expr || expr`): logical OR.
-* `_`: “ignored” pattern binding. Also used to make integer literals readable.
-* `?` (`expr?`): error propagation.
-
-### Non-operator Symbols
-
-The following list contains all non-letters that don’t function as operators;
-that is, they don’t behave like a function or method call.
-
-#### Stand-Alone Syntax
-
-* `'ident`: named lifetime or loop label.
-* `...u8`, `...i32`, `...f64`, `...usize`, *etc.*: numeric literal of
-specific type.
-* `"..."`: string literal.
-* `r"..."`, `r#"..."#`, `r##"..."##`, *etc.*: raw string literal,
-escape characters are not processed.
-* `b"..."`: byte string literal, constructs a `[u8]` instead of a string.
-* `br"..."`, `br#"..."#`, `br##"..."##`, *etc.*: raw byte string
-literal, combination of raw and byte string literal.
-* `'...'`: character literal.
-* `b'...'`: ASCII byte literal.
-* `|...| expr`: closure.
-* `!`: always empty bottom type for diverging functions.
-
-#### Path-Related Syntax
-
-* `ident::ident`: namespace path.
-* `::path`: path relative to the crate root (*i.e.*, an explicitly absolute
-path).
-* `self::path`: path relative to the current module (*i.e.*, an explicitly
-relative path).
-* `super::path`: path relative to the parent of the current module.
-* `type::ident`, `::ident`: associated constants, functions, and
-types.
-* `::...`: associated item for a type that cannot be directly named
-(*e.g.*, `<&T>::...`, `<[T]>::...`, *etc.*).
-* `trait::method(...)`: disambiguating a method call by naming the trait
-that defines it.
-* `type::method(...)`: disambiguating a method call by naming the type for
-which it’s defined.
-* `::method(...)`: disambiguating a method call by naming
-the trait *and* type.
-
-#### Generics
-
-* `path<...>` (*e.g.*, `Vec`): specifies parameters to generic type *in
-a type*.
-* `path::<...>`, `method::<...>` (*e.g.*, `"42".parse::()`):
-specifies parameters to generic type, function, or method *in an expression*.
-Often referred to as *turbofish*.
-* `fn ident<...> ...`: define generic function.
-* `struct ident<...> ...`: define generic structure.
-* `enum ident<...> ...`: define generic enumeration.
-* `impl<...> ...`: define generic implementation.
-* `for<...> type`: higher-ranked lifetime bounds.
-* `type` (*e.g.*, `Iterator`): a generic type where one or
-more associated types have specific assignments.
-
-#### Trait Bound Constraints
-
-* `T: U`: generic parameter `T` constrained to types that implement `U`.
-* `T: 'a`: generic type `T` must outlive lifetime `'a`. When we say that a type
-“outlives” the lifetime, we mean it cannot transitively contain any references
-with lifetimes shorter than `'a`.
-* `T : 'static`: the generic type `T` contains no borrowed references other
-than `'static` ones.
-* `'b: 'a`: generic lifetime `'b` must outlive lifetime `'a`.
-* `T: ?Sized`: allow generic type parameter to be a dynamically sized type.
-* `'a + trait`, `trait + trait`: compound type constraint.
-
-#### Macros and Attributes
-
-* `#[meta]`: outer attribute.
-* `#![meta]`: inner attribute.
-* `$ident`: macro substitution.
-* `$ident:kind`: macro capture.
-* `$(…)…`: macro repetition.
-
-#### Comments
-
-* `//`: line comment.
-* `//!`: inner line doc comment.
-* `///`: outer line doc comment.
-* `/*...*/`: block comment.
-* `/*!...*/`: inner block doc comment.
-* `/**...*/`: outer block doc comment.
-
-#### Tuples
-
-* `()`: empty tuple (*aka* unit), both literal and type.
-* `(expr)`: parenthesized expression.
-* `(expr,)`: single-element tuple expression.
-* `(type,)`: single-element tuple type.
-* `(expr, ...)`: tuple expression.
-* `(type, ...)`: tuple type.
-* `expr(expr, ...)`: function call expression. Also used to initialize
-tuple `struct`s and tuple `enum` variants.
-* `ident!(...)`, `ident!{...}`, `ident![...]`: macro invocation.
-* `expr.0`, `expr.1`, *etc.*: tuple indexing.
-
-#### Curly Brackets
-
-* `{...}`: block expression.
-* `Type {...}`: `struct` literal.
-
-#### Square Brackets
-
-* `[...]`: array literal.
-* `[expr; len]`: array literal containing `len` copies of `expr`.
-* `[type; len]`: array type containing `len` instances of `type`.
-* `expr[expr]`: collection indexing. Overloadable (`Index`, `IndexMut`).
-* `expr[..]`, `expr[a..]`, `expr[..b]`, `expr[a..b]`: collection indexing
-pretending to be collection slicing, using `Range`, `RangeFrom`, `RangeTo`, or
-`RangeFull` as the “index.”
-
-## Appendix C: Derivable Traits
-
-In various places in the book, we’ve discussed the `derive` attribute that you
-can apply to a struct or enum definition.
-
-The `derive` attribute generates code that will implement a trait with its own
-default implementation on the type you’ve annotated with the `derive` syntax.
-In this appendix, we provide a reference of all the traits in the standard
-library that you can use with `derive`. Each section covers:
-
-* What operators and methods deriving this trait will enable
-* What the implementation of the trait provided by `derive` does
-* What implementing the trait signifies about the type
-* The conditions in which you’re allowed or not allowed to implement the trait
-* Examples of operations that require the trait
-
-If you want different behavior than that provided by the `derive` attribute,
-consult the standard library documentation for each trait for details on how to
-manually implement them.
-
-The rest of the traits defined in the standard library can’t be implemented on
-your types using `derive`. These traits don’t have sensible default behavior,
-so it’s up to you to implement them in the way that makes sense for what you’re
-trying to accomplish.
-
-An example of a trait that can’t be derived is `Display`, which handles
-formatting for end users. You should always consider the appropriate way to
-display a type to an end user: for example, what parts of the type should an
-end user be allowed to see? What parts would they find relevant? What format of
-the data would be most relevant to them? The Rust compiler doesn’t have this
-insight, so it can’t provide appropriate default behavior for you.
-
-The list of derivable traits provided in this appendix is not comprehensive:
-libraries can implement `derive` for their own traits, making the list of
-traits you can use `derive` with truly open-ended. Implementing `derive`
-involves using a procedural macro, which is covered in Appendix D, “Macros.”
-
-### `Debug` for Programmer Output
-
-The `Debug` trait enables debug formatting in format strings, which you
-indicate by adding `:?` within `{}` placeholders.
-
-The `Debug` trait allows you to print instances of a type for debugging
-purposes, so you and other programmers using your type can inspect an instance
-at a particular point in a program’s execution.
-
-The `Debug` trait is required, for example, in use of the `assert_eq!` macro.
-This macro prints the values of instances given as arguments if the equality
-assertion fails so programmers can see why the two instances weren’t equal.
-
-### `PartialEq` and `Eq` for Equality Comparisons
-
-The `PartialEq` trait allows you to compare instances of a type to check for
-equality and enables use of the `==` and `!=` operators.
-
-Deriving `PartialEq` implements the `eq` method. When `PartialEq` is derived on
-structs, two instances are equal only if *all* fields are equal and not equal
-if any fields are not equal. When derived on enums, each variant is equal to
-itself and not equal to the other variants.
-
-The `PartialEq` trait is required, for example, with the use of the
-`assert_eq!` macro, which needs to be able to compare two instances of a type
-for equality.
-
-The `Eq` trait has no methods. Its purpose is to signal that for every value of
-the annotated type, the value is equal to itself. The `Eq` trait can only be
-applied to types that also implement `PartialEq`, although not all types that
-implement `PartialEq` can implement `Eq`. One example of this is floating point
-number types: the implementation of floating point numbers states that two
-instances of the not-a-number (`NaN`) value are not equal to each other.
-
-An example of when `Eq` is required is for keys in a `HashMap` so the `HashMap`
-can tell whether two keys are the same.
-
-### `PartialOrd` and `Ord` for Ordering Comparisons
-
-The `PartialOrd` trait allows you to compare instances of a type for sorting
-purposes. A type that implements `PartialOrd` can be used with the `<`, `>`,
-`<=`, and `>=` operators. You can only apply the `PartialOrd` trait to types
-that also implement `PartialEq`.
-
-Deriving `PartialOrd` implements the `partial_cmp` method, which returns an
-`Option` that will be `None` when the values given don’t produce an
-ordering. An example of a value that doesn’t produce an ordering, even though
-most values of that type can be compared, is the not-a-number (`NaN`) floating
-point value. Calling `partial_cmp` with any floating point number and the `NaN`
-floating point value will return `None`.
-
-When derived on structs, `PartialOrd` compares two instances by comparing the
-value in each field in the order in which the fields appear in the struct
-definition. When derived on enums, variants of the enum declared earlier in the
-enum definition are considered less than the variants listed later.
-
-The `PartialOrd` trait is required, for example, for the `gen_range` method
-from the `rand` crate that generates a random value in the range specified by a
-low value and a high value.
-
-The `Ord` trait allows you to know that for any two values of the annotated
-type, a valid ordering will exist. The `Ord` trait implements the `cmp` method,
-which returns an `Ordering` rather than an `Option` because a valid
-ordering will always be possible. You can only apply the `Ord` trait to types
-that also implement `PartialOrd` and `Eq` (and `Eq` requires `PartialEq`). When
-derived on structs and enums, `cmp` behaves the same way as the derived
-implementation for `partial_cmp` does with `PartialOrd`.
-
-An example of when `Ord` is required is when storing values in a `BTreeSet`,
-a data structure that stores data based on the sort order of the values.
-
-### `Clone` and `Copy` for Duplicating Values
-
-The `Clone` trait allows you to explicitly create a deep copy of a value, and
-the duplication process might involve running arbitrary code and copying heap
-data. See the “Ways Variables and Data Interact: Clone” section in Chapter 4
-for more information on `Clone`.
-
-Deriving `Clone` implements the `clone` method, which when implemented for the
-whole type, calls `clone` on each of the parts of the type. This means all the
-fields or values in the type must also implement `Clone` to derive `Clone`.
-
-An example of when `Clone` is required is when calling the `to_vec` method on a
-slice. The slice doesn’t own the type instances it contains, but the vector
-returned from `to_vec` will need to own its instances, so `to_vec` calls
-`clone` on each item. Thus, the type stored in the slice must implement `Clone`.
-
-The `Copy` trait allows you to duplicate a value by only copying bits stored on
-the stack; no arbitrary code is necessary. See the “Stack-Only Data: Copy”
-section in Chapter 4 for more information on `Copy`.
-
-The `Copy` trait doesn’t define any methods to prevent programmers from
-overloading those methods and violating the assumption that no arbitrary code
-is being run. That way, all programmers can assume that copying a value will be
-very fast.
-
-You can derive `Copy` on any type whose parts all implement `Copy`. You can
-only apply the `Copy` trait to types that also implement `Clone`, because a
-type that implements `Copy` has a trivial implementation of `Clone` that
-performs the same task as `Copy`.
-
-The `Copy` trait is rarely required; types that implement `Copy` have
-optimizations available, meaning you don’t have to call `clone`, which makes
-the code more concise.
-
-Everything possible with `Copy` you can also accomplish with `Clone`, but the
-code might be slower or have to use `clone` in places.
-
-### `Hash` for Mapping a Value to a Value of Fixed Size
-
-The `Hash` trait allows you to take an instance of a type of arbitrary size and
-map that instance to a value of fixed size, using a hash function. Deriving
-`Hash` implements the `hash` method. The derived implementation of the `hash`
-method combines the result of calling `hash` on each of the parts of the type,
-meaning all fields or values must also implement `Hash` to derive `Hash`.
-
-An example of when `Hash` is required is in storing keys in a `HashMap` to
-store data efficiently.
-
-### `Default` for Default Values
-
-The `Default` trait allows you to create a default value for a type. Deriving
-`Default` implements the `default` function. The derived implementation of the
-`default` function calls the `default` function on each part of the type,
-meaning all fields or values in the type must also implement `Default` to
-derive `Default.`
-
-The `Default::default` function is commonly used in combination with the struct
-update syntax discussed in the “Creating Instances From Other Instances With
-Struct Update Syntax” section in Chapter 5. You can customize a few fields of a
-struct and then set and use a default value for the rest of the fields by using
-`..Default::default()`.
-
-The `Default` trait is required when, for example, you use the
-`unwrap_or_default` method on `Option` instances. If the `Option` is
-`None`, the `unwrap_or_default` method will return the result of
-`Default::default` for the type `T` stored in the `Option`.
-
-## Appendix D: Macros
-
-We’ve used macros like `println!` throughout this book but haven’t fully
-explored what a macro is and how it works. This appendix explains macros as
-follows:
-
-* What macros are and how they differ from functions
-* How to define a declarative macro to do metaprogramming
-* How to define a procedural macro to create custom `derive` traits
-
-We’re covering the details of macros in an appendix because they’re still
-evolving in Rust. Macros have changed and, in the near future, will change at a
-quicker rate than the rest of the language and standard library since Rust 1.0,
-so this section is more likely to date than the rest of the book. Due to Rust’s
-stability guarantees, the code shown here will continue to work with future
-versions. But there may be additional capabilities or easier ways to write
-macros that weren’t available at the time of this publication. Bear that in
-mind when you try to implement anything from this appendix.
-
-### The Difference Between Macros and Functions
-
-Fundamentally, macros are a way of writing code that writes other code, which
-is known as *metaprogramming*. In Appendix C, we discussed the `derive`
-attribute, which generates an implementation of various traits for you. We’ve
-also used the `println!` and `vec!` macros throughout the book. All of these
-macros *expand* to produce more code than the code you’ve written manually.
-
-Metaprogramming is useful for reducing the amount of code you have to write and
-maintain, which is also one of the roles of functions. However, macros have
-some additional powers that functions don’t have.
-
-A function signature must declare the number and type of parameters the
-function has. Macros, on the other hand, can take a variable number of
-parameters: we can call `println!("hello")` with one argument or
-`println!("hello {}", name)` with two arguments. Also, macros are expanded
-before the compiler interprets the meaning of the code, so a macro can, for
-example, implement a trait on a given type. A function can’t, because it gets
-called at runtime and a trait needs to be implemented at compile time.
-
-The downside to implementing a macro instead of a function is that macro
-definitions are more complex than function definitions because you’re writing
-Rust code that writes Rust code. Due to this indirection, macro definitions are
-generally more difficult to read, understand, and maintain than function
-definitions.
-
-Another difference between macros and functions is that macro definitions
-aren’t namespaced within modules like function definitions are. To prevent
-unexpected name clashes when using external crates, you have to explicitly
-bring the macros into the scope of your project at the same time as you bring
-the external crate into scope, using the `#[macro_use]` annotation. The
-following example would bring all the macros defined in the `serde` crate into
-the scope of the current crate:
-
-```
-#[macro_use]
-extern crate serde;
-```
-
-If `extern crate` was able to bring macros into scope by default without this
-explicit annotation, you would be prevented from using two crates that happened
-to define macros with the same name. In practice, this conflict doesn’t occur
-often, but the more crates you use, the more likely it is.
-
-There is one last important difference between macros and functions: you must
-define or bring macros into scope *before* you call them in a file, whereas you
-can define functions anywhere and call them anywhere.
-
-### Declarative Macros with `macro_rules!` for General Metaprogramming
-
-The most widely used form of macros in Rust are *declarative macros*. These are
-also sometimes referred to as *macros by example*, *`macro_rules!` macros*, or
-just plain *macros*. At their core, declarative macros allow you to write
-something similar to a Rust `match` expression. As discussed in Chapter 6,
-`match` expressions are control structures that take an expression, compare the
-resulting value of the expression to patterns, and then run the code associated
-with the matching pattern. Macros also compare a value to patterns that have
-code associated with them; in this situation, the value is the literal Rust
-source code passed to the macro, the patterns are compared with the structure
-of that source code, and the code associated with each pattern is the code that
-replaces the code passed to the macro. This all happens during compilation.
-
-To define a macro, you use the `macro_rules!` construct. Let’s explore how to
-use `macro_rules!` by looking at how the `vec!` macro is defined. Chapter 8
-covered how we can use the `vec!` macro to create a new vector with particular
-values. For example, the following macro creates a new vector with three
-integers inside:
-
-```
-let v: Vec = vec![1, 2, 3];
-```
-
-We could also use the `vec!` macro to make a vector of two integers or a vector
-of five string slices: we wouldn’t be able to use a function to do the same
-because we wouldn’t know the number or type of values up front.
-
-Let’s look at a slightly simplified definition of the `vec!` macro in Listing
-D-1:
-
-```
-#[macro_export]
-macro_rules! vec {
-    ( $( $x:expr ),* ) => {
-        {
-            let mut temp_vec = Vec::new();
-            $(
-                temp_vec.push($x);
-            )*
-            temp_vec
-        }
-    };
-}
-```
-
-Listing D-1: A simplified version of the `vec!` macro definition
-
-> Note: The actual definition of the `vec!` macro in the standard library
-> includes code to preallocate the correct amount of memory up front. That code
-> is an optimization that we don’t include here to make the example simpler.
-
-The `#[macro_export]` annotation indicates that this macro should be made
-available whenever the crate in which we’re defining the macro is imported.
-Without this annotation, even if someone depending on this crate uses the
-`#[macro_use]` annotation, the macro wouldn’t be brought into scope.
-
-We then start the macro definition with `macro_rules!` and the name of the
-macro we’re defining *without* the exclamation mark. The name, in this case
-`vec`, is followed by curly brackets denoting the body of the macro definition.
-
-The structure in the `vec!` body is similar to the structure of a `match`
-expression. Here we have one arm with the pattern `( $( $x:expr ),* )`,
-followed by `=>` and the block of code associated with this pattern. If the
-pattern matches, the associated block of code will be emitted. Given that this
-is the only pattern in this macro, there is only one valid way to match; any
-other will be an error. More complex macros will have more than one arm.
-
-Valid pattern syntax in macro definitions is different than the pattern syntax
-covered in Chapter 18 because macro patterns are matched against Rust code
-structure rather than values. Let’s walk through what the pieces of the pattern
-in Listing D-1 mean; for the full macro pattern syntax, see the reference at
-*https://doc.rust-lang.org/stable/reference/macros.html*.
-
-First, a set of parentheses encompasses the whole pattern. Next comes a dollar
-sign (`$`) followed by a set of parentheses, which captures values that match
-the pattern within the parentheses for use in the replacement code. Within
-`$()` is `$x:expr`, which matches any Rust expression and gives the expression
-the name `$x`.
-
-The comma following `$()` indicates that a literal comma separator character
-could optionally appear after the code that matches the code captured in `$()`.
-The `*` following the comma specifies that the pattern matches zero or more of
-whatever precedes the `*`.
-
-When we call this macro with `vec![1, 2, 3];`, the `$x` pattern matches three
-times with the three expressions `1`, `2`, and `3`.
-
-Now let’s look at the pattern in the body of the code associated with this arm:
-the `temp_vec.push()` code within the `$()*` part is generated for each part
-that matches `$()` in the pattern, zero or more times depending on how many
-times the pattern matches. The `$x` is replaced with each expression matched.
-When we call this macro with `vec![1, 2, 3];`, the code generated that replaces
-this macro call will be the following:
-
-```
-let mut temp_vec = Vec::new();
-temp_vec.push(1);
-temp_vec.push(2);
-temp_vec.push(3);
-temp_vec
-```
-
-We’ve defined a macro that can take any number of arguments of any type and can
-generate code to create a vector containing the specified elements.
-
-Given that most Rust programmers will *use* macros more than *write* macros, we
-won’t discuss `macro_rules!` any further. To learn more about how to write
-macros, consult the online documentation or other resources, such as “The
-Little Book of Rust Macros” at
-*https://danielkeep.github.io/tlborm/book/index.html*.
-
-### Procedural Macros for Custom `derive`
-
-The second form of macros is called *procedural macros* because they’re more
-like functions (which are a type of procedure). Procedural macros accept some
-Rust code as an input, operate on that code, and produce some Rust code as an
-output rather than matching against patterns and replacing the code with other
-code as declarative macros do. At the time of this writing, you can only define
-procedural macros to allow your traits to be implemented on a type by
-specifying the trait name in a `derive` annotation.
-
-We’ll create a crate named `hello_macro` that defines a trait named
-`HelloMacro` with one associated function named `hello_macro`. Rather than
-making our crate users implement the `HelloMacro` trait for each of their
-types, we’ll provide a procedural macro so users can annotate their type with
-`#[derive(HelloMacro)]` to get a default implementation of the `hello_macro`
-function. The default implementation will print `Hello, Macro! My name is
-TypeName!` where `TypeName` is the name of the type on which this trait has
-been defined. In other words, we’ll write a crate that enables another
-programmer to write code like Listing D-2 using our crate.
-
-Filename: src/main.rs
-
-```
-extern crate hello_macro;
-#[macro_use]
-extern crate hello_macro_derive;
-
-use hello_macro::HelloMacro;
-
-#[derive(HelloMacro)]
-struct Pancakes;
-
-fn main() {
-    Pancakes::hello_macro();
-}
-```
-
-Listing D-2: The code a user of our crate will be able to write when using our
-procedural macro
-
-This code will print `Hello, Macro! My name is Pancakes!` when we’re done. The
-first step is to make a new library crate, like this:
-
-```
-$ cargo new hello_macro --lib
-```
-
-Next, we’ll define the `HelloMacro` trait and its associated function:
-
-Filename: src/lib.rs
-
-```
-pub trait HelloMacro {
-    fn hello_macro();
-}
-```
-
-We have a trait and its function. At this point, our crate user could implement
-the trait to achieve the desired functionality, like so:
-
-```
-extern crate hello_macro;
-
-use hello_macro::HelloMacro;
-
-struct Pancakes;
-
-impl HelloMacro for Pancakes {
-    fn hello_macro() {
-        println!("Hello, Macro! My name is Pancakes!");
-    }
-}
-
-fn main() {
-    Pancakes::hello_macro();
-}
-```
-
-However, they would need to write the implementation block for each type they
-wanted to use with `hello_macro`; we want to spare them from having to do this
-work.
-
-Additionally, we can’t yet provide a default implementation for the
-`hello_macro` function that will print the name of the type the trait is
-implemented on: Rust doesn’t have reflection capabilities, so it can’t look up
-the type’s name at runtime. We need a macro to generate code at compile time.
-
-The next step is to define the procedural macro. At the time of this writing,
-procedural macros need to be in their own crate. Eventually, this restriction
-might be lifted. The convention for structuring crates and macro crates is as
-follows: for a crate named `foo`, a custom derive procedural macro crate is
-called `foo_derive`. Let’s start a new crate called `hello_macro_derive` inside
-our `hello_macro` project:
-
-```
-$ cargo new hello_macro_derive --lib
-```
-
-Our two crates are tightly related, so we create the procedural macro crate
-within the directory of our `hello_macro` crate. If we change the trait
-definition in `hello_macro`, we’ll have to change the implementation of the
-procedural macro in `hello_macro_derive` as well. The two crates will need to
-be published separately, and programmers using these crates will need to add
-both as dependencies and bring them both into scope. We could instead have the
-`hello_macro` crate use `hello_macro_derive` as a dependency and reexport the
-procedural macro code. But the way we’ve structured the project makes it
-possible for programmers to use `hello_macro` even if they don’t want the
-`derive` functionality.
-
-We need to declare the `hello_macro_derive` crate as a procedural macro crate.
-We’ll also need functionality from the `syn` and `quote` crates, as you’ll see
-in a moment, so we need to add them as dependencies. Add the following to the
-*Cargo.toml* file for `hello_macro_derive`:
-
-Filename: hello_macro_derive/Cargo.toml
-
-```
-[lib]
-proc-macro = true
-
-[dependencies]
-syn = "0.11.11"
-quote = "0.3.15"
-```
-
-To start defining the procedural macro, place the code in Listing D-3 into your
-*src/lib.rs* file for the `hello_macro_derive` crate. Note that this code won’t
-compile until we add a definition for the `impl_hello_macro` function.
-
-Notice the way we’ve split the functions in D-3; this will be the same for
-almost every procedural macro crate you see or create, because it makes writing
-a procedural macro more convenient. What you choose to do in the place where
-the `impl_hello_macro` function is called will be different depending on your
-procedural macro’s purpose.
-
-Filename: hello_macro_derive/src/lib.rs
-
-```
-extern crate proc_macro;
-extern crate syn;
-#[macro_use]
-extern crate quote;
-
-use proc_macro::TokenStream;
-
-#[proc_macro_derive(HelloMacro)]
-pub fn hello_macro_derive(input: TokenStream) -> TokenStream {
-    // Construct a string representation of the type definition
-    let s = input.to_string();
-
-    // Parse the string representation
-    let ast = syn::parse_derive_input(&s).unwrap();
-
-    // Build the impl
-    let gen = impl_hello_macro(&ast);
-
-    // Return the generated impl
-    gen.parse().unwrap()
-}
-```
-
-Listing D-3: Code that most procedural macro crates will need to have for
-processing Rust code
-
-We’ve introduced three new crates: `proc_macro`, `syn` (available from
-*https://crates.io/crates/syn*), and `quote` (available from
-*https://crates.io/crates/quote*). The `proc_macro` crate comes with Rust, so
-we didn’t need to add that to the dependencies in *Cargo.toml*. The
-`proc_macro` crate allows us to convert Rust code into a string containing that
-Rust code. The `syn` crate parses Rust code from a string into a data structure
-that we can perform operations on. The `quote` crate takes `syn` data
-structures and turns them back into Rust code. These crates make it much
-simpler to parse any sort of Rust code we might want to handle: writing a full
-parser for Rust code is no simple task.
-
-The `hello_macro_derive` function will get called when a user of our library
-specifies `#[derive(HelloMacro)]` on a type. The reason is that we’ve annotated
-the `hello_macro_derive` function here with `proc_macro_derive` and specified
-the name, `HelloMacro`, which matches our trait name; that’s the convention
-most procedural macros follow.
-
-This function first converts the `input` from a `TokenStream` to a `String` by
-calling `to_string`. This `String` is a string representation of the Rust code
-for which we are deriving `HelloMacro`. In the example in Listing D-2, `s` will
-have the `String` value `struct Pancakes;` because that is the Rust code we
-added the `#[derive(HelloMacro)]` annotation to.
-
-> Note: At the time of this writing, you can only convert a `TokenStream` to a
-> string. A richer API will exist in the future.
-
-Now we need to parse the Rust code `String` into a data structure that we can
-then interpret and perform operations on. This is where `syn` comes into play.
-The `parse_derive_input` function in `syn` takes a `String` and returns a
-`DeriveInput` struct representing the parsed Rust code. The following code
-shows the relevant parts of the `DeriveInput` struct we get from parsing the
-string `struct Pancakes;`:
-
-```
-DeriveInput {
-    // --snip--
-
-    ident: Ident(
-        "Pancakes"
-    ),
-    body: Struct(
-        Unit
-    )
-}
-```
-
-The fields of this struct show that the Rust code we’ve parsed is a unit struct
-with the `ident` (identifier, meaning the name) of `Pancakes`. There are more
-fields on this struct for describing all sorts of Rust code; check the `syn`
-documentation for `DeriveInput` at
-*https://docs.rs/syn/0.11.11/syn/struct.DeriveInput.html* for more information.
-
-At this point, we haven’t defined the `impl_hello_macro` function, which is
-where we’ll build the new Rust code we want to include. But before we do, note
-that the last part of this `hello_macro_derive` function uses the `parse`
-function from the `quote` crate to turn the output of the `impl_hello_macro`
-function back into a `TokenStream`. The returned `TokenStream` is added to the
-code that our crate users write, so when they compile their crate, they get
-extra functionality that we provide.
-
-You might have noticed that we’re calling `unwrap` to panic if the calls to the
-`parse_derive_input` or `parse` functions fail here. Panicking on errors is
-necessary in procedural macro code because `proc_macro_derive` functions must
-return `TokenStream` rather than `Result` to conform to the procedural macro
-API. We’ve chosen to simplify this example by using `unwrap`; in production
-code, you should provide more specific error messages about what went wrong by
-using `panic!` or `expect`.
-
-Now that we have the code to turn the annotated Rust code from a `TokenStream`
-into a `String` and a `DeriveInput` instance, let’s generate the code that
-implements the `HelloMacro` trait on the annotated type:
-
-hello_macro_derive/src/lib.rs
-
-```
-fn impl_hello_macro(ast: &syn::DeriveInput) -> quote::Tokens {
-    let name = &ast.ident;
-    quote! {
-        impl HelloMacro for #name {
-            fn hello_macro() {
-                println!("Hello, Macro! My name is {}", stringify!(#name));
-            }
-        }
-    }
-}
-```
-
-We get an `Ident` struct instance containing the name (identifier) of the
-annotated type using `ast.ident`. The code in Listing D-2 specifies that the
-`name` will be `Ident("Pancakes")`.
-
-The `quote!` macro lets us write the Rust code that we want to return and
-convert it into `quote::Tokens`. This macro also provides some very cool
-templating mechanics; we can write `#name` and `quote!` will replace it with
-the value in the variable named `name`. You can even do some repetition similar
-to the way regular macros work. Check out the `quote` crate’s docs at
-*https://docs.rs/quote* for a thorough introduction.
-
-We want our procedural macro to generate an implementation of our `HelloMacro`
-trait for the type the user annotated, which we can get by using `#name`. The
-trait implementation has one function, `hello_macro`, whose body contains the
-functionality we want to provide: printing `Hello, Macro! My name is` and then
-the name of the annotated type.
-
-The `stringify!` macro used here is built into Rust. It takes a Rust
-expression, such as `1 + 2`, and at compile time turns the expression into a
-string literal, such as `"1 + 2"`. This is different than `format!` or
-`println!`, which evaluate the expression and then turn the result into a
-`String`. There is a possibility that the `#name` input might be an expression
-to print literally, so we use `stringify!`. Using `stringify!` also saves an
-allocation by converting `#name` to a string literal at compile time.
-
-At this point, `cargo build` should complete successfully in both `hello_macro`
-and `hello_macro_derive`. Let’s hook up these crates to the code in Listing D-2
-to see the procedural macro in action! Create a new binary project in your
-*projects* directory using `cargo new --bin pancakes`. We need to add
-`hello_macro` and `hello_macro_derive` as dependencies in the `pancakes`
-crate’s *Cargo.toml*. If you’re publishing your versions of `hello_macro` and
-`hello_macro_derive` to *https://crates.io/*, they would be regular
-dependencies; if not, you can specify them as `path` dependencies as follows:
-
-```
-[dependencies]
-hello_macro = { path = "../hello_macro" }
-hello_macro_derive = { path = "../hello_macro/hello_macro_derive" }
-```
-
-Put the code from Listing D-2 into *src/main.rs*, and run `cargo run`: it
-should print `Hello, Macro! My name is Pancakes!` The implementation of the
-`HelloMacro` trait from the procedural macro was included without the
-`pancakes` crate needing to implement it; the `#[derive(HelloMacro)]` added the
-trait implementation.
-
-### The Future of Macros
-
-In the future, Rust will expand declarative and procedural macros. Rust will
-use a better declarative macro system with the `macro` keyword and will add
-more types of procedural macros for more powerful tasks than just `derive`.
-These systems are still under development at the time of this publication;
-please consult the online Rust documentation for the latest information.
diff --git a/src/doc/book/second-edition/nostarch/chapter00.md b/src/doc/book/second-edition/nostarch/chapter00.md
deleted file mode 100644
index 8ee563fdad..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter00.md
+++ /dev/null
@@ -1,177 +0,0 @@
-
-[TOC]
-
-# Introduction
-
-Welcome to *The Rust Programming Language*, an introductory book about Rust.
-
-The Rust programming language helps you write faster, more reliable software.
-High-level ergonomics and low-level control are often at odds in programming
-language design; Rust challenges that conflict. Through balancing powerful
-technical capacity and a great developer experience, Rust gives you the option
-to control low-level details (such as memory usage) without all the hassle
-traditionally associated with such control.
-
-## Who Rust Is For
-
-Rust is ideal for many people for a variety of reasons. Let’s look at a few of
-the most important groups.
-
-### Teams of Developers
-
-Rust is proving to be a productive tool for collaborating among large teams of
-developers with varying levels of systems programming knowledge. Low-level code
-is prone to a variety of subtle bugs, which in most other languages can only be
-caught through extensive testing and careful code review by experienced
-developers. In Rust, the compiler plays a gatekeeper role by refusing to
-compile code with these elusive bugs, including concurrency bugs. By working
-alongside the compiler, the team can spend more time focusing on the program’s
-logic rather than chasing down bugs.
-
-Rust also brings contemporary developer tools to the systems programming world:
-
-* Cargo, the included dependency manager and build tool, makes adding,
-  compiling, and managing dependencies painless and consistent across the Rust
-  ecosystem.
-* Rustfmt ensures a consistent coding style across developers.
-* The Rust Language Server powers Integrated Development Environment (IDE)
-  integration for code completion and inline error messages.
-
-By using these and other tools in the Rust ecosystem, developers can be
-productive while writing systems-level code.
-
-### Students
-
-Rust is for students and those who are interested in learning about systems
-concepts. Using Rust, many people have learned about topics like operating
-systems development. The community is very welcoming and happy to answer
-student questions. Through efforts such as this book, the Rust teams want to
-make systems concepts more accessible to more people, especially those new to
-programming.
-
-### Companies
-
-Hundreds of companies, large and small, use Rust in production for a variety of
-tasks. Those tasks include command line tools, web services, DevOps tooling,
-embedded devices, audio and video analysis and transcoding, cryptocurrencies,
-bioinformatics, search engines, internet of things applications, machine
-learning, and even major parts of the Firefox web browser.
-
-### Open Source Developers
-
-Rust is for people who want to build the Rust programming language, community,
-developer tools, and libraries. We’d love to have you contribute to the Rust
-language.
-
-### People Who Value Speed and Stability
-
-Rust is for people who crave speed and stability in a language. By speed, we
-mean the speed of the programs that you can create with Rust and the speed at
-which Rust lets you write them. The Rust compiler’s checks ensure stability
-through feature additions and refactoring as opposed to brittle legacy code in
-languages without these checks that developers are afraid to modify. By
-striving for zero-cost abstractions, higher-level features that compile to
-lower-level code as fast as code written manually, Rust endeavors to make safe
-code be fast code as well.
-
-Although we’ve not provided a complete list of everyone the Rust language hopes
-to support, those we have mentioned are some of the biggest stakeholders.
-Overall, Rust’s greatest ambition is to eliminate the dichotomy of the
-trade-offs that programmers have accepted for decades: safety *and*
-productivity, speed *and* ergonomics. Give Rust a try, and see if its choices
-work for you.
-
-## Who This Book Is For
-
-This book assumes that you’ve written code in another programming language but
-doesn’t make any assumptions about which one. We’ve tried to make the material
-broadly accessible to those from a wide variety of programming backgrounds. We
-don’t spend a lot of time talking about what programming *is* or how to think
-about it. If you’re entirely new to programming, you would be better served by
-reading a book that specifically provides an introduction to programming.
-
-## How to Use This Book
-
-In general, this book assumes that you’re reading it in sequence from front to
-back. Later chapters build on concepts in earlier chapters, and earlier
-chapters might not delve into details on a topic; we typically revisit the
-topic in a later chapter.
-
-You’ll find two kinds of chapters in this book: concept chapters and project
-chapters. In concept chapters, you’ll learn about an aspect of Rust. In project
-chapters, we’ll build small programs together, applying what you’ve learned so
-far. Chapters 2, 12, and 20 are project chapters; the rest are concept chapters.
-
-Additionally, Chapter 2 is a hands-on introduction to the Rust language. We’ll
-cover concepts at a high level, and later chapters will provide additional
-detail. If you want to get your hands dirty right away, Chapter 2 is the one
-for that. At first, you might even want to skip Chapter 3, which covers Rust
-features similar to other programming language features, and head straight to
-Chapter 4 to learn about Rust’s ownership system. However, if you’re a
-particularly meticulous learner who prefers to learn every detail before moving
-onto the next, you might want to skip Chapter 2 and go straight to Chapter 3,
-returning to Chapter 2 when you’d like to work on a project applying those
-details.
-
-Chapter 5 discusses structs and methods, and Chapter 6 covers enums, `match`
-expressions, and the `if let` control flow construct. You’ll use structs and
-enums to make custom types in Rust.
-
-In Chapter 7, you’ll learn about Rust’s module system and about privacy rules
-for organizing your code and its public Application Programming Interface
-(API). Chapter 8 discusses some common collection data structures that the
-standard library provides, such as vectors, strings, and hash maps. Chapter 9
-explores Rust’s error handling philosophy and techniques.
-
-Chapter 10 digs into generics, traits, and lifetimes, which give you the power
-to define code that applies to multiple types. Chapter 11 is all about testing,
-which is still necessary even with Rust’s safety guarantees to ensure your
-program’s logic is correct. In Chapter 12, we’ll build our own implementation
-of a subset of functionality from the `grep` command line tool that searches
-for text within files. For this, we’ll use many of the concepts we discussed in
-the previous chapters.
-
-Chapter 13 explores closures and iterators: features of Rust that come from
-functional programming languages. In Chapter 14, we’ll examine Cargo in more
-depth and talk about best practices for sharing your libraries with others.
-Chapter 15 discusses smart pointers that the standard library provides and the
-traits that enable their functionality.
-
-In Chapter 16, we’ll walk through different models of concurrent programming
-and talk about how Rust helps you to program in multiple threads fearlessly.
-Chapter 17 looks at how Rust idioms compare to object oriented programming
-principles you might be familiar with.
-
-Chapter 18 is a reference on patterns and pattern matching, which are powerful
-ways of expressing ideas throughout Rust programs. Chapter 19 contains a
-smorgasbord of advanced topics of interest, including unsafe Rust and more
-about lifetimes, traits, types, functions, and closures.
-
-In Chapter 20, we’ll complete a project in which we’ll implement a low-level
-multithreaded web server!
-
-Finally, some appendixes contain useful information about the language in a
-more reference-like format. Appendix A covers Rust’s keywords. Appendix B
-covers Rust’s operators and symbols. Appendix C covers derivable traits
-provided by the standard library. Appendix D covers macros.
-
-There is no wrong way to read this book: if you want to skip ahead, go for it!
-You might have to jump back to earlier chapters if you experience any
-confusion. But do whatever works for you.
-
-An important part of the process of learning Rust is learning how to read the
-error messages the compiler displays: these will guide you toward working code.
-As such, we’ll provide many examples of code that don’t compile along with the
-error message the compiler will show you in each situation. Know that if you
-enter and run a random example, it may not compile! Make sure you read the
-surrounding text to see whether the example you’re trying to run is meant to
-error. In most situations, we’ll lead you to the correct version of any code
-that doesn’t compile.
-
-## Contributing to the Book
-
-This book is open source. If you find an error, please don’t hesitate to file
-an issue or send a pull request on GitHub at
-*https://github.com/rust-lang/book/*. Please see CONTRIBUTING.md at
-*https://github.com/rust-lang/book/blob/master/CONTRIBUTING.md* for more
-details.
diff --git a/src/doc/book/second-edition/nostarch/chapter01.md b/src/doc/book/second-edition/nostarch/chapter01.md
deleted file mode 100644
index 9694aa9bad..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter01.md
+++ /dev/null
@@ -1,592 +0,0 @@
-
-[TOC]
-
-# Getting Started
-
-Let’s start your Rust journey! In this chapter, we’ll discuss:
-
-* Installing Rust on Linux, macOS, and Windows
-* Writing a program that prints “Hello, world!”
-* Using `cargo`, Rust’s package manager and build system
-
-## Installation
-
-The first step is to install Rust. We’ll download Rust through `rustup`, a
-command line tool for managing Rust versions and associated tools. You’ll need
-an internet connection for the download.
-
-The following steps install the latest stable version of the Rust compiler. All
-the examples and output in this book use stable Rust 1.21.0. Rust’s stability
-guarantees ensure that all the examples in the book that compile will continue
-to compile with newer Rust versions. The output might differ slightly between
-versions, because Rust often improves error messages and warnings. In other
-words, any newer, stable version of Rust you install using these steps should
-work as expected with the content of this book.
-
-> ### Command Line Notation
->
-> In this chapter and throughout the book, we’ll show some commands used in the
-> terminal. Lines that you should enter in a terminal all start with `$`. You
-> don’t need to type in the `$` character; it indicates the start of each
-> command. Many tutorials use the convention `$` for commands you run as a
-> regular user and `#` for commands you run as an administrator. Lines that
-> don’t start with `$` typically show the output of the previous command.
-> Additionally, PowerShell specific examples will use `>` rather than `$`.
-
-### Installing Rustup on Linux or macOS
-
-If you’re using Linux or macOS, open a terminal and enter the following command:
-
-```
-$ curl https://sh.rustup.rs -sSf | sh
-```
-
-The command downloads a script and starts the installation of the `rustup`
-tool, which installs the latest stable version of Rust. You might be prompted
-for your password. If the install is successful, the following line will appear:
-
-```
-Rust is installed now. Great!
-```
-
-Of course, if you distrust using `curl URL | sh` to install software, you can
-download, inspect, and run the script however you like.
-
-The installation script automatically adds Rust to your system PATH after your
-next login. If you want to start using Rust right away instead of restarting
-your terminal, run the following command in your shell to add Rust to your
-system PATH manually:
-
-```
-$ source $HOME/.cargo/env
-```
-
-Alternatively, you can add the following line to your *~/.bash_profile*:
-
-```
-$ export PATH="$HOME/.cargo/bin:$PATH"
-```
-
-Additionally, you’ll need a linker of some kind. It’s likely one is already
-installed, but when you try to compile a Rust program and get errors indicating
-that a linker could not execute, you’ll need to install one. You can install a
-C compiler, because that will usually come with the correct linker. Check your
-platform’s documentation for how to install a C compiler. Some common Rust
-packages depend on C code and will need a C compiler too, so it might be worth
-installing one now regardless.
-
-### Installing Rustup on Windows
-
-On Windows, go to *https://www.rust-lang.org/en-US/install.html* and follow the
-instructions for installing Rust. At some point in the installation, you’ll
-receive a message explaining that you’ll also need the C++ build tools for
-Visual Studio 2013 or later. The easiest way to acquire the build tools is to
-install Build Tools for Visual Studio 2017 at
-*https://www.visualstudio.com/downloads/*. The tools are in the Other Tools and
-Frameworks section.
-
-The rest of this book uses commands that work in both *cmd.exe* and PowerShell.
-If there are specific differences, we’ll explain which to use.
-
-### Custom Installations Without Rustup
-
-If you prefer not to use `rustup` for some reason, please see the Rust
-installation page at *https://www.rust-lang.org/install.html* for other options.
-
-### Updating and Uninstalling
-
-After you’ve installed Rust via `rustup`, updating to the latest version is
-easy. From your shell, run the following update script:
-
-```
-$ rustup update
-```
-
-To uninstall Rust and `rustup`, from your shell run the following uninstall
-script:
-
-```
-$ rustup self uninstall
-```
-
-### Troubleshooting
-
-To check whether you have Rust installed correctly, open a shell and enter this
-line:
-
-```
-$ rustc --version
-```
-
-You should see the version number, commit hash, and commit date for the latest
-stable version that has been released in the following format:
-
-```
-rustc x.y.z (abcabcabc yyyy-mm-dd)
-```
-
-If you see this information, you have installed Rust successfully! If you don’t
-see this information and you’re on Windows, check that Rust is in your `%PATH%`
-system variable. If that’s all correct and Rust still isn’t working, there are
-a number of places you can get help. The easiest is the #rust IRC channel on
-*irc.mozilla.org*, which you can access through Mibbit at
-*http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23rust/*. At that
-address you can chat with other Rustaceans (a silly nickname we call ourselves)
-who can help you out. Other great resources include the Users forum at
-*https://users.rust-lang.org/* and Stack Overflow at
-*http://stackoverflow.com/questions/tagged/rust/*.
-
-### Local Documentation
-
-The installer also includes a copy of the documentation locally, so you can
-read it offline. Run `rustup doc` to open the local documentation in your
-browser.
-
-Any time a type or function is provided by the standard library and you’re not
-sure what it does or how to use it, use the application programming interface
-(API) documentation to find out!
-
-## Hello, World!
-
-Now that you’ve installed Rust, let’s write your first Rust program. It’s
-traditional when learning a new language to write a little program that prints
-the text “Hello, world!” to the screen, so we’ll do the same here!
-
-> Note: This book assumes basic familiarity with the command line. Rust makes
-> no specific demands about your editing, tooling, or where your code lives, so
-> if you prefer to use an integrated development environment (IDE) instead of
-> the command line, feel free to use your favorite IDE. Many IDEs now have some
-> degree of Rust support; check the IDE’s documentation for details. Recently,
-> the Rust team has been focusing on enabling great IDE support, and progress
-> has been made rapidly on that front!
-
-### Creating a Project Directory
-
-You’ll start by making a directory to store your Rust code. It doesn’t matter
-to Rust where your code lives, but for the exercises and projects in this book,
-you’ll make a *projects* directory in your home directory to keep all your
-projects there.
-
-Open a terminal and enter the following commands to make a *projects* directory
-and a directory for the “Hello, world!” project within the *projects* directory.
-
-For Linux and macOS, enter this:
-
-```
-$ mkdir ~/projects
-$ cd ~/projects
-$ mkdir hello_world
-$ cd hello_world
-```
-
-For Windows CMD, enter this:
-
-```
-> mkdir "%USERPROFILE%\projects"
-> cd /d "%USERPROFILE%\projects"
-> mkdir hello_world
-> cd hello_world
-```
-
-For Windows PowerShell, enter this:
-
-```
-> mkdir $env:USERPROFILE\projects
-> cd $env:USERPROFILE\projects
-> mkdir hello_world
-> cd hello_world
-```
-
-### Writing and Running a Rust Program
-
-Next, make a new source file and call it *main.rs*. Rust files always end with
-the *.rs* extension. If you’re using more than one word in your filename, use
-an underscore to separate them. For example, use *hello_world.rs* rather than
-*helloworld.rs*.
-
-Now open the *main.rs* file you just created, and enter the code in Listing 1-1.
-
-Filename: main.rs
-
-```
-fn main() {
-    println!("Hello, world!");
-}
-```
-
-Listing 1-1: A program that prints “Hello, world!”
-
-Save the file, and go back to your terminal window. On Linux or macOS, enter
-the following commands to compile and run the file:
-
-```
-$ rustc main.rs
-$ ./main
-Hello, world!
-```
-
-On Windows, enter the command `.\main.exe` instead of `./main`.
-
-```
-> rustc main.rs
-> .\main.exe
-Hello, world!
-```
-
-Regardless of your operating system, the string `Hello, world!` should print to
-the terminal. If you don’t see this output, refer back to the “Troubleshooting”
-section for ways to get help.
-
-If you did see `Hello, world!` printed, congratulations! You’ve officially
-written a Rust program. That makes you a Rust programmer! Welcome!
-
-### Anatomy of a Rust Program
-
-Let’s review in detail what just happened in your “Hello, world!” program.
-Here’s the first piece of the puzzle:
-
-```
-fn main() {
-
-}
-```
-
-These lines define a *function* in Rust. The `main` function is special: it is
-always the first code that runs in every executable Rust program. The first
-line declares a function named `main` that has no parameters and returns
-nothing. If there were parameters, they would go inside the parentheses, `(`
-and `)`.
-
-Also, note that the function body is wrapped in curly brackets, `{` and `}`.
-Rust requires these around all function bodies. It’s good style to place the
-opening curly bracket on the same line as the function declaration, adding one
-space in between.
-
-At the time of this writing, an automatic formatter tool called `rustfmt` is
-under development. If you want to stick to a standard style across Rust
-projects, `rustfmt` will format your code in a particular style. The Rust team
-plans to eventually include it with the standard Rust distribution, like
-`rustc`. So depending on when you read this book, it might already be installed
-on your computer! Check the online documentation for more details.
-
-Inside the `main` function is the following code:
-
-```
-    println!("Hello, world!");
-```
-
-This line does all the work in this little program: it prints text to the
-screen. There are four important details to notice here. First, Rust style is
-to indent with four spaces, not a tab.
-
-Second, `println!` calls a Rust *macro*. If it called a function instead, it
-would be entered as `println` (without the `!`). We’ll discuss Rust macros in
-more detail in Appendix D. For now, you just need to know that using a `!`
-means that you’re calling a macro instead of a normal function.
-
-Third, you see the `"Hello, world!"` *string*. We pass this string as an
-argument to `println!`, and the string is printed to the screen.
-
-Fourth, we end the line with a semicolon `;`, which indicates that this
-expression is over and the next one is ready to begin. Most lines of Rust code
-end with a semicolon.
-
-### Compiling and Running Are Separate Steps
-
-You’ve just run a newly created program, so let’s examine each step in the
-process.
-
-Before running a Rust program, you must compile it using the Rust compiler by
-entering the `rustc` command and passing it the name of your source file, like
-this:
-
-```
-$ rustc main.rs
-```
-
-If you have a C or C++ background, you’ll notice that this is similar to `gcc`
-or `clang`. After compiling successfully, Rust outputs a binary executable.
-
-On Linux, macOS, and PowerShell on Windows, you can see the executable by
-entering the `ls` command in your shell as follows:
-
-```
-$ ls
-main  main.rs
-```
-
-With CMD on Windows, you would enter the following:
-
-```
-> dir /B %= the /B option says to only show the file names =%
-main.exe
-main.pdb
-main.rs
-```
-
-This shows the source code file with the *.rs* extension, the executable file
-(*main.exe* on Windows, but *main* on all other platforms), and, when using
-CMD, a file containing debugging information with the *.pdb* extension. From
-here, you run the *main* or *main.exe* file, like this:
-
-```
-$ ./main # or .\main.exe on Windows
-```
-
-If *main.rs* was your “Hello, world!” program, this line would print `Hello,
-world!` to your terminal.
-
-If you’re more familiar with a dynamic language, such as Ruby, Python, or
-JavaScript, you might not be used to compiling and running a program as
-separate steps. Rust is an *ahead-of-time compiled* language, meaning you can
-compile a program, give the executable to someone else, and they can run it
-even without having Rust installed. If you give someone a *.rb*, *.py*, or
-*.js* file, they need to have a Ruby, Python, or JavaScript implementation
-installed (respectively). But in those languages, you only need one command to
-compile and run your program. Everything is a trade-off in language design.
-
-Just compiling with `rustc` is fine for simple programs, but as your project
-grows, you’ll want to manage all the options and make it easy to share your
-code. Next, we’ll introduce you to the Cargo tool, which will help you write
-real-world Rust programs.
-
-## Hello, Cargo!
-
-Cargo is Rust’s build system and package manager. Most Rustaceans use this tool
-to manage their Rust projects because Cargo handles a lot of tasks for you,
-such as building your code, downloading the libraries your code depends on, and
-building those libraries. (We call libraries your code needs *dependencies*.)
-
-The simplest Rust programs, like the one we’ve written so far, don’t have any
-dependencies. So if we had built the “Hello, world!” project with Cargo, it
-would only use the part of Cargo that handles building your code. As you write
-more complex Rust programs, you’ll add dependencies, and if you start a project
-using Cargo, adding dependencies will be much easier to do.
-
-Because the vast majority of Rust projects use Cargo, the rest of this book
-assumes that you’re using Cargo too. Cargo comes installed with Rust if you
-used the official installers discussed in the “Installation” section. If you
-installed Rust through some other means, check whether Cargo is installed by
-entering the following into your terminal:
-
-```
-$ cargo --version
-```
-
-If you see a version number, you have it! If you see an error, such as `command
-not found`, look at the documentation for your method of installation to
-determine how to install Cargo separately.
-
-### Creating a Project with Cargo
-
-Let’s create a new project using Cargo and look at how it differs from our
-original “Hello, world!” project. Navigate back to your *projects* directory.
-Then, on any operating system, run the following:
-
-```
-$ cargo new hello_cargo --bin
-$ cd hello_cargo
-```
-
-The first command creates a new binary executable called *hello_cargo*. The
-`--bin` argument passed to `cargo new` makes an executable application (often
-just called a *binary*) as opposed to a library. We’ve named our project
-*hello_cargo*, and Cargo creates its files in a directory of the same name.
-
-Go into the *hello_cargo* directory and list the files. You’ll see that Cargo
-has generated two files and one directory for us: a *Cargo.toml* file and a
-*src* directory with a *main.rs* file inside. It has also initialized a new Git
-repository along with a *.gitignore* file.
-
-> Note: Git is a common version control system. You can change `cargo new` to
-> use  a different version control system or no version control system by using
-> the `--vcs` flag. Run `cargo new --help` to see the available options.
-
-Open *Cargo.toml* in your text editor of choice. It should look similar to the
-code in Listing 1-2.
-
-Filename: Cargo.toml
-
-```
-[package]
-name = "hello_cargo"
-version = "0.1.0"
-authors = ["Your Name "]
-
-[dependencies]
-```
-
-Listing 1-2: Contents of *Cargo.toml* generated by `cargo new`
-
-This file is in the *TOML* (Tom’s Obvious, Minimal Language) format, which is
-Cargo’s configuration format.
-
-The first line, `[package]`, is a section heading that indicates that the
-following statements are configuring a package. As we add more information to
-this file, we’ll add other sections.
-
-The next three lines set the configuration information Cargo needs to compile
-your program: the name, the version, and who wrote it. Cargo gets your name and
-email information from your environment, so if that information is not correct,
-fix the information now and then save the file.
-
-The last line, `[dependencies]`, is the start of a section for you to list any
-of your project’s dependencies. In Rust, packages of code are referred to as
-*crates*. We won’t need any other crates for this project, but we will in the
-first project in Chapter 2, so we’ll use this dependencies section then.
-
-Now open *src/main.rs* and take a look:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    println!("Hello, world!");
-}
-```
-
-Cargo has generated a “Hello, world!” program for you, just like the one we
-wrote in Listing 1-1! So far, the differences between our previous project and
-the project Cargo generates are that Cargo placed the code in the *src*
-directory, and we have a *Cargo.toml* configuration file in the top directory.
-
-Cargo expects your source files to live inside the *src* directory. The
-top-level project directory is just for README files, license information,
-configuration files, and anything else not related to your code. Using Cargo
-helps you organize your projects. There’s a place for everything, and
-everything is in its place.
-
-If you started a project that doesn’t use Cargo, as we did with our project in
-the *hello_world* directory, you can convert it to a project that does use
-Cargo. Move the project code into the *src* directory and create an appropriate
-*Cargo.toml* file.
-
-### Building and Running a Cargo Project
-
-Now let’s look at the difference when we build and run the “Hello, world!”
-program with Cargo! From your *hello_cargo* directory, build your project by
-entering the following command:
-
-```
-$ cargo build
-   Compiling hello_cargo v0.1.0 (file:///projects/hello_cargo)
-    Finished dev [unoptimized + debuginfo] target(s) in 2.85 secs
-```
-
-This command creates an executable file in *target/debug/hello_cargo* (or
-*target\debug\hello_cargo.exe* on Windows) rather than in your current
-directory. You can run the executable with this command:
-
-```
-$ ./target/debug/hello_cargo # or .\target\debug\hello_cargo.exe on Windows
-Hello, world!
-```
-
-If all goes well, `Hello, world!` should print to the terminal. Running `cargo
-build` for the first time also causes Cargo to create a new file at the top
-level: *Cargo.lock*. This file keeps track of the exact versions of
-dependencies in your project. This project doesn’t have dependencies, so the
-file is a bit sparse. You won’t ever need to change this file manually; Cargo
-manages its contents for you.
-
-We just built a project with `cargo build` and ran it with
-`./target/debug/hello_cargo`, but we can also use `cargo run` to compile the
-code and then run the resulting executable all in one command:
-
-```
-$ cargo run
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target/debug/hello_cargo`
-Hello, world!
-```
-
-Notice that this time we didn’t see output indicating that Cargo was compiling
-`hello_cargo`. Cargo figured out that the files hadn’t changed, so it just ran
-the binary. If you had modified your source code, Cargo would have rebuilt the
-project before running it, and you would have seen this output:
-
-```
-$ cargo run
-   Compiling hello_cargo v0.1.0 (file:///projects/hello_cargo)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.33 secs
-     Running `target/debug/hello_cargo`
-Hello, world!
-```
-
-Cargo also provides a command called `cargo check`. This command quickly checks
-your code to make sure it compiles but doesn’t produce an executable:
-
-```
-$ cargo check
-   Compiling hello_cargo v0.1.0 (file:///projects/hello_cargo)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.32 secs
-```
-
-Why would you not want an executable? Often, `cargo check` is much faster than
-`cargo build`, because it skips the step of producing an executable. If you’re
-continually checking your work while writing the code, using `cargo check` will
-speed up the process! As such, many Rustaceans run `cargo check` periodically
-as they write their program to make sure it compiles. Then they run `cargo
-build` when they’re ready to use the executable.
-
-To recap what we’ve learned so far about Cargo:
-
-* We can build a project using `cargo build` or `cargo check`.
-* We can build and run a project in one step using `cargo run`.
-* Instead of the result of the build being saved in the same directory as our
-code, Cargo stores it in the *target/debug* directory.
-
-An additional advantage of using Cargo is that the commands are the same no
-matter which operating system you’re working on. So, at this point, we’ll no
-longer provide specific instructions for Linux and macOS versus Windows.
-
-### Building for Release
-
-When your project is finally ready for release, you can use `cargo build
---release` to compile it with optimizations. This command will create an
-executable in *target/release* instead of *target/debug*. The optimizations
-make your Rust code run faster, but turning them on lengthens the time it takes
-for your program to compile. This is why there are two different profiles: one
-for development when you want to rebuild quickly and often, and another for
-building the final program you’ll give to a user that won’t be rebuilt
-repeatedly and that will run as fast as possible. If you’re benchmarking your
-code’s running time, be sure to run `cargo build --release` and benchmark with
-the executable in *target/release*.
-
-### Cargo as Convention
-
-With simple projects, Cargo doesn’t provide a lot of value over just using
-`rustc`, but it will prove its worth as your programs become more intricate.
-With complex projects composed of multiple crates, it’s much easier to let
-Cargo coordinate the build.
-
-Even though the `hello_cargo` project is simple, it now uses much of the real
-tooling you’ll use in the rest of your Rust career. In fact, to work on any
-existing projects, you can use the following commands to check out the code
-using Git, change to that project’s directory, and build:
-
-```
-$ git clone someurl.com/someproject
-$ cd someproject
-$ cargo build
-```
-
-For more information about Cargo, check out its documentation at
-*https://doc.rust-lang.org/cargo/*.
-
-## Summary
-
-You’re already off to a great start on your Rust journey! In this chapter,
-you’ve learned how to:
-
-* Install the latest stable version of Rust using `rustup`
-* Update to a newer Rust version
-* Open locally installed documentation
-* Write and run a “Hello, world!” program using `rustc` directly
-* Create and run a new project using the conventions of Cargo
-
-This is a great time to build a more substantial program to get used to reading
-and writing Rust code. So, in the next chapter, we’ll build a guessing game
-program. If you would rather start by learning how common programming concepts
-work in Rust, see Chapter 3, and then return to Chapter 2.
-
diff --git a/src/doc/book/second-edition/nostarch/chapter02.md b/src/doc/book/second-edition/nostarch/chapter02.md
deleted file mode 100644
index eccf122fa9..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter02.md
+++ /dev/null
@@ -1,984 +0,0 @@
-
-[TOC]
-
-# Programming a Guessing Game
-
-Let’s jump into Rust by working through a hands-on project together! This
-chapter introduces you to a few common Rust concepts by showing you how to use
-them in a real program. You’ll learn about `let`, `match`, methods, associated
-functions, using external crates, and more! The following chapters will explore
-these ideas in more detail. In this chapter, you’ll practice the fundamentals.
-
-We’ll implement a classic beginner programming problem: a guessing game. Here’s
-how it works: the program will generate a random integer between 1 and 100. It
-will then prompt the player to enter a guess. After a guess is entered, the
-program will indicate whether the guess is too low or too high. If the guess is
-correct, the game will print a congratulatory message and exit.
-
-## Setting Up a New Project
-
-To set up a new project, go to the *projects* directory that you created in
-Chapter 1 and make a new project using Cargo, like so:
-
-```
-$ cargo new guessing_game --bin
-$ cd guessing_game
-```
-
-The first command, `cargo new`, takes the name of the project (`guessing_game`)
-as the first argument. The `--bin` flag tells Cargo to make a binary project,
-like the one in Chapter 1. The second command changes to the new project’s
-directory.
-
-Look at the generated *Cargo.toml* file:
-
-Filename: Cargo.toml
-
-```
-[package]
-name = "guessing_game"
-version = "0.1.0"
-authors = ["Your Name "]
-
-[dependencies]
-```
-
-If the author information that Cargo obtained from your environment is not
-correct, fix that in the file and save it again.
-
-As you saw in Chapter 1, `cargo new` generates a “Hello, world!” program for
-you. Check out the *src/main.rs* file:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    println!("Hello, world!");
-}
-```
-
-Now let’s compile this “Hello, world!” program and run it in the same step
-using the `cargo run` command:
-
-```
-$ cargo run
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-    Finished dev [unoptimized + debuginfo] target(s) in 1.50 secs
-     Running `target/debug/guessing_game`
-Hello, world!
-```
-
-The `run` command comes in handy when you need to rapidly iterate on a project,
-as we’ll do in this game, quickly testing each iteration before moving on to
-the next one.
-
-Reopen the *src/main.rs* file. You’ll be writing all the code in this file.
-
-## Processing a Guess
-
-The first part of the guessing game program will ask for user input, process
-that input, and check that the input is in the expected form. To start, we’ll
-allow the player to input a guess. Enter the code in Listing 2-1 into
-*src/main.rs*.
-
-Filename: src/main.rs
-
-```
-use std::io;
-
-fn main() {
-    println!("Guess the number!");
-
-    println!("Please input your guess.");
-
-    let mut guess = String::new();
-
-    io::stdin().read_line(&mut guess)
-        .expect("Failed to read line");
-
-    println!("You guessed: {}", guess);
-}
-```
-
-Listing 2-1: Code that gets a guess from the user and prints it
-
-This code contains a lot of information, so let’s go over it line by line. To
-obtain user input and then print the result as output, we need to bring the
-`io` (input/output) library into scope. The `io` library comes from the
-standard library (which is known as `std`):
-
-```
-use std::io;
-```
-
-By default, Rust brings only a few types into the scope of every program in
-the *prelude*. If a type you want to use isn’t in the
-prelude, you have to bring that type into scope explicitly with a `use`
-statement. Using the `std::io` library provides you with a number of useful
-features, including the ability to accept user input.
-
-As you saw in Chapter 1, the `main` function is the entry point into the
-program:
-
-```
-fn main() {
-```
-
-The `fn` syntax declares a new function, the parentheses, `()`, indicate there
-are no parameters, and the curly bracket, `{`, starts the body of the function.
-
-As you also learned in Chapter 1, `println!` is a macro that prints a string to
-the screen:
-
-```
-println!("Guess the number!");
-
-println!("Please input your guess.");
-```
-
-This code is printing a prompt stating what the game is and requesting input
-from the user.
-
-### Storing Values with Variables
-
-Next, we’ll create a place to store the user input, like this:
-
-```
-let mut guess = String::new();
-```
-
-Now the program is getting interesting! There’s a lot going on in this little
-line. Notice that this is a `let` statement, which is used to create a
-*variable*. Here’s another example:
-
-```
-let foo = bar;
-```
-
-This line creates a new variable named `foo` and bind it to the value `bar`. In
-Rust, variables are immutable by default. We’ll be discussing this concept in
-detail in the “Variables and Mutability” section in Chapter 3. The following
-example shows how to use `mut` before the variable name to make a variable
-mutable:
-
-```
-let foo = 5; // immutable
-let mut bar = 5; // mutable
-```
-
-> Note: The `//` syntax starts a comment that continues until the end of the
-> line. Rust ignores everything in comments, which are discussed in more detail
-> in Chapter 3.
-
-Now you know that `let mut guess` will introduce a mutable variable named
-`guess`. On the other side of the equal sign (`=`) is the value that `guess` is
-bound to, which is the result of calling `String::new`, a function that returns
-a new instance of a `String`. `String` is a string
-type provided by the standard library that is a growable, UTF-8 encoded bit of
-text.
-
-The `::` syntax in the `::new` line indicates that `new` is an *associated
-function* of the `String` type. An associated function is implemented on a type,
-in this case `String`, rather than on a particular instance of a `String`. Some
-languages call this a *static method*.
-
-This `new` function creates a new, empty string. You’ll find a `new` function
-on many types, because it’s a common name for a function that makes a new value
-of some kind.
-
-To summarize, the `let mut guess = String::new();` line has created a mutable
-variable that is currently bound to a new, empty instance of a `String`. Whew!
-
-Recall that we included the input/output functionality from the standard
-library with `use std::io;` on the first line of the program. Now we’ll call an
-associated function, `stdin`, on `io`:
-
-```
-io::stdin().read_line(&mut guess)
-    .expect("Failed to read line");
-```
-
-If we hadn’t listed the `use std::io` line at the beginning of the program, we
-could have written this function call as `std::io::stdin`. The `stdin` function
-returns an instance of `std::io::Stdin`, which is a
-type that represents a handle to the standard input for your terminal.
-
-The next part of the code, `.read_line(&mut guess)`, calls the
-`read_line` method on the standard input handle to
-get input from the user. We’re also passing one argument to `read_line`: `&mut
-guess`.
-
-The job of `read_line` is to take whatever the user types into standard input
-and place that into a string, so it takes that string as an argument. The
-string argument needs to be mutable so the method can change the string’s
-content by adding the user input.
-
-The `&` indicates that this argument is a *reference*, which gives you a way to
-let multiple parts of your code access one piece of data without needing to
-copy that data into memory multiple times. References are a complex feature,
-and one of Rust’s major advantages is how safe and easy it is to use
-references. You don’t need to know a lot of those details to finish this
-program. For now, all you need to know is that like variables, references are
-immutable by default. Hence, you need to write `&mut guess` rather than
-`&guess` to make it mutable. (Chapter 4 will explain references more
-thoroughly.)
-
-### Handling Potential Failure with the `Result` Type
-
-We’re not quite done with this line of code. Although what we’ve discussed so
-far is a single line of text, it’s only the first part of the single logical
-line of code. The second part is this method:
-
-```
-.expect("Failed to read line");
-```
-
-When you call a method with the `.foo()` syntax, it’s often wise to introduce a
-newline and other whitespace to help break up long lines. We could have
-written this code as:
-
-```
-io::stdin().read_line(&mut guess).expect("Failed to read line");
-```
-
-However, one long line is difficult to read, so it’s best to divide it: two
-lines for two method calls. Now let’s discuss what this line does.
-
-As mentioned earlier, `read_line` puts what the user types into the string
-we’re passing it, but it also returns a value—in this case, an
-`io::Result`. Rust has a number of types named
-`Result` in its standard library: a generic `Result`
-as well as specific versions for submodules, such as `io::Result`.
-
-The `Result` types are *enumerations*, often referred
-to as *enums*. An enumeration is a type that can have a fixed set of values,
-and those values are called the enum’s *variants*. Chapter 6 will cover enums
-in more detail.
-
-For `Result`, the variants are `Ok` or `Err`. The `Ok` variant indicates the
-operation was successful, and inside `Ok` is the successfully generated value.
-The `Err` variant means the operation failed, and `Err` contains information
-about how or why the operation failed.
-
-The purpose of these `Result` types is to encode error-handling information.
-Values of the `Result` type, like any type, have methods defined on them. An
-instance of `io::Result` has an `expect` method that
-you can call. If this instance of `io::Result` is an `Err` value, `expect` will
-cause the program to crash and display the message that you passed as an
-argument to `expect`. If the `read_line` method returns an `Err`, it would
-likely be the result of an error coming from the underlying operating system.
-If this instance of `io::Result` is an `Ok` value, `expect` will take the
-return value that `Ok` is holding and return just that value to you so you
-can use it. In this case, that value is the number of bytes in what the user
-entered into standard input.
-
-If you don’t call `expect`, the program will compile, but you’ll get a warning:
-
-```
-$ cargo build
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-warning: unused `std::result::Result` which must be used
-  --> src/main.rs:10:5
-   |
-10 |     io::stdin().read_line(&mut guess);
-   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-   |
-   = note: #[warn(unused_must_use)] on by default
-```
-
-Rust warns that you haven’t used the `Result` value returned from `read_line`,
-indicating that the program hasn’t handled a possible error.
-
-The right way to suppress the warning is to actually write error handling, but
-since you just want to crash this program when a problem occurs, you can use
-`expect`. You’ll learn about recovering from errors in Chapter 9.
-
-### Printing Values with `println!` Placeholders
-
-Aside from the closing curly brackets, there’s only one more line to discuss in
-the code added so far, which is the following:
-
-```
-println!("You guessed: {}", guess);
-```
-
-This line prints the string we saved the user’s input in. The set of curly
-brackets, `{}`, is a placeholder: think of `{}` as little crab pincers that
-hold a value in place. You can print more than one value using curly brackets:
-the first set of curly brackets holds the first value listed after the format
-string, the second set holds the second value, and so on. Printing multiple
-values in one call to `println!` would look like this:
-
-```
-let x = 5;
-let y = 10;
-
-println!("x = {} and y = {}", x, y);
-```
-
-This code would print `x = 5 and y = 10`.
-
-### Testing the First Part
-
-Let’s test the first part of the guessing game. Run it using `cargo run`:
-
-```
-$ cargo run
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-    Finished dev [unoptimized + debuginfo] target(s) in 2.53 secs
-     Running `target/debug/guessing_game`
-Guess the number!
-Please input your guess.
-6
-You guessed: 6
-```
-
-At this point, the first part of the game is done: we’re getting input from the
-keyboard and then printing it.
-
-## Generating a Secret Number
-
-Next, we need to generate a secret number that the user will try to guess. The
-secret number should be different every time so the game is fun to play more
-than once. Let’s use a random number between 1 and 100 so the game isn’t too
-difficult. Rust doesn’t yet include random number functionality in its standard
-library. However, the Rust team does provide a `rand` crate at *https://crates.io/crates/rand*.
-
-
-### Using a Crate to Get More Functionality
-
-Remember that a crate is a package of Rust code. The project we’ve been
-building is a *binary crate*, which is an executable. The `rand` crate is a
-*library crate*, which contains code intended to be used in other programs.
-
-Cargo’s use of external crates is where it really shines. Before we can write
-code that uses `rand`, we need to modify the *Cargo.toml* file to include the
-`rand` crate as a dependency. Open that file now and add the following line to
-the bottom beneath the `[dependencies]` section header that Cargo created for
-you:
-
-Filename: Cargo.toml
-
-```
-[dependencies]
-
-rand = "0.3.14"
-```
-
-In the *Cargo.toml* file, everything that follows a header is part of a section
-that continues until another section starts. The `[dependencies]` section is
-where you tell Cargo which external crates your project depends on and which
-versions of those crates you require. In this case, we’ll specify the `rand`
-crate with the semantic version specifier `0.3.14`. Cargo understands Semantic
-Versioning (sometimes called *SemVer*), which is a
-standard for writing version numbers. The number `0.3.14` is actually shorthand
-for `^0.3.14`, which means “any version that has a public API compatible with
-version 0.3.14.”
-
-Now, without changing any of the code, let’s build the project, as shown in
-Listing 2-2:
-
-```
-$ cargo build
-    Updating registry `https://github.com/rust-lang/crates.io-index`
- Downloading rand v0.3.14
- Downloading libc v0.2.14
-   Compiling libc v0.2.14
-   Compiling rand v0.3.14
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-    Finished dev [unoptimized + debuginfo] target(s) in 2.53 secs
-```
-
-Listing 2-2: The output from running `cargo build` after adding the rand crate
-as a dependency
-
-You may see different version numbers (but they will all be compatible with
-the code, thanks to SemVer!), and the lines may be in a different order.
-
-Now that we have an external dependency, Cargo fetches the latest versions of
-everything from the *registry*, which is a copy of data from
-Crates.io at *https://crates.io*. Crates.io is where people in the Rust ecosystem post
-their open source Rust projects for others to use.
-
-
-After updating the registry, Cargo checks the `[dependencies]` section and
-downloads any crates you don’t have yet. In this case, although we only listed
-`rand` as a dependency, Cargo also grabbed a copy of `libc`, because `rand`
-depends on `libc` to work. After downloading the crates, Rust compiles them and
-then compiles the project with the dependencies available.
-
-If you immediately run `cargo build` again without making any changes, you
-won’t get any output aside from the `Finished` line. Cargo knows it has already
-downloaded and compiled the dependencies, and you haven’t changed anything
-about them in your *Cargo.toml* file. Cargo also knows that you haven’t changed
-anything about your code, so it doesn’t recompile that either. With nothing to
-do, it simply exits.
-
-If you open up the *src/main.rs* file, make a trivial change, and then save it
-and build again, you’ll only see two lines of output:
-
-```
-$ cargo build
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-    Finished dev [unoptimized + debuginfo] target(s) in 2.53 secs
-```
-
-These lines show Cargo only updates the build with your tiny change to the
-*src/main.rs* file. Your dependencies haven’t changed, so Cargo knows it can
-reuse what it has already downloaded and compiled for those. It just rebuilds
-your part of the code.
-
-#### Ensuring Reproducible Builds with the *Cargo.lock* File
-
-Cargo has a mechanism that ensures you can rebuild the same artifact every time
-you or anyone else builds your code: Cargo will use only the versions of the
-dependencies you specified until you indicate otherwise. For example, what
-happens if next week version `v0.3.15` of the `rand` crate comes out and
-contains an important bug fix but also contains a regression that will break
-your code?
-
-The answer to this problem is the *Cargo.lock* file, which was created the
-first time you ran `cargo build` and is now in your *guessing_game* directory.
-When you build a project for the first time, Cargo figures out all the
-versions of the dependencies that fit the criteria and then writes them to
-the *Cargo.lock* file. When you build your project in the future, Cargo will
-see that the *Cargo.lock* file exists and use the versions specified there
-rather than doing all the work of figuring out versions again. This lets you
-have a reproducible build automatically. In other words, your project will
-remain at `0.3.14` until you explicitly upgrade, thanks to the *Cargo.lock*
-file.
-
-#### Updating a Crate to Get a New Version
-
-When you *do* want to update a crate, Cargo provides another command, `update`,
-which will ignore the *Cargo.lock* file and figure out all the latest versions
-that fit your specifications in *Cargo.toml*. If that works, Cargo will write
-those versions to the *Cargo.lock* file.
-
-But by default, Cargo will only look for versions larger than `0.3.0` and
-smaller than `0.4.0`. If the `rand` crate has released two new versions,
-`0.3.15` and `0.4.0`, you would see the following if you ran `cargo update`:
-
-```
-$ cargo update
-    Updating registry `https://github.com/rust-lang/crates.io-index`
-    Updating rand v0.3.14 -> v0.3.15
-```
-
-At this point, you would also notice a change in your *Cargo.lock* file noting
-that the version of the `rand` crate you are now using is `0.3.15`.
-
-If you wanted to use `rand` version `0.4.0` or any version in the `0.4.x`
-series, you’d have to update the *Cargo.toml* file to look like this instead:
-
-```
-[dependencies]
-
-rand = "0.4.0"
-```
-
-The next time you run `cargo build`, Cargo will update the registry of crates
-available and reevaluate your `rand` requirements according to the new version
-you have specified.
-
-There’s a lot more to say about Cargo and its ecosystem which we’ll discuss in
-Chapter 14, but for now, that’s all you need to know. Cargo makes it very easy
-to reuse libraries, so Rustaceans are able to write smaller projects that are
-assembled from a number of packages.
-
-### Generating a Random Number
-
-Now that you’ve added the `rand` crate to *Cargo.toml*, let’s start using
-`rand`. The next step is to update *src/main.rs*, as shown in Listing 2-3:
-
-Filename: src/main.rs
-
-```
-extern crate rand;
-
-use std::io;
-use rand::Rng;
-
-fn main() {
-    println!("Guess the number!");
-
-    let secret_number = rand::thread_rng().gen_range(1, 101);
-
-    println!("The secret number is: {}", secret_number);
-
-    println!("Please input your guess.");
-
-    let mut guess = String::new();
-
-    io::stdin().read_line(&mut guess)
-        .expect("Failed to read line");
-
-    println!("You guessed: {}", guess);
-}
-```
-
-Listing 2-3: Adding code to generate a random number
-
-First, we add a line that lets Rust know we’ll be using the `rand` crate as an
-external dependency. This also does the equivalent of calling `use rand`, so
-now we can call anything in the `rand` crate by placing `rand::` before it.
-
-Next, we add another `use` line: `use rand::Rng`. The `Rng` trait defines
-methods that random number generators implement, and this trait must be in
-scope for us to use those methods. Chapter 10 will cover traits in detail.
-
-Also, we’re adding two more lines in the middle. The `rand::thread_rng` function
-will give us the particular random number generator that we’re going to use:
-one that is local to the current thread of execution and seeded by the
-operating system. Next, we call the `gen_range` method on the random number
-generator. This method is defined by the `Rng` trait that we brought into
-scope with the `use rand::Rng` statement. The `gen_range` method takes two
-numbers as arguments and generates a random number between them. It’s inclusive
-on the lower bound but exclusive on the upper bound, so we need to specify `1`
-and `101` to request a number between 1 and 100.
-
-> Note: You won’t just know which traits to use and which methods and functions
-> to call from a crate. Instructions for using a crate are in each crate’s
-> documentation. Another neat feature of Cargo is that you can run the `cargo
-> doc --open` command, which will build documentation provided by all of your
-> dependencies locally and open it in your browser. If you’re interested in
-> other functionality in the `rand` crate, for example, run `cargo doc --open`
-> and click `rand` in the sidebar on the left.
-
-The second line that we added to the code prints the secret number. This is
-useful while we’re developing the program to be able to test it, but we’ll
-delete it from the final version. It’s not much of a game if the program prints
-the answer as soon as it starts!
-
-Try running the program a few times:
-
-```
-$ cargo run
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-    Finished dev [unoptimized + debuginfo] target(s) in 2.53 secs
-     Running `target/debug/guessing_game`
-Guess the number!
-The secret number is: 7
-Please input your guess.
-4
-You guessed: 4
-$ cargo run
-     Running `target/debug/guessing_game`
-Guess the number!
-The secret number is: 83
-Please input your guess.
-5
-You guessed: 5
-```
-
-You should get different random numbers, and they should all be numbers between
-1 and 100. Great job!
-
-## Comparing the Guess to the Secret Number
-
-Now that we have user input and a random number, we can compare them. That step
-is shown in Listing 2-4. Note that this code won’t compile quite yet, as we
-will explain.
-
-Filename: src/main.rs
-
-```
-extern crate rand;
-
-use std::io;
-use std::cmp::Ordering;
-use rand::Rng;
-
-fn main() {
-    // ---snip---
-
-    println!("You guessed: {}", guess);
-
-    match guess.cmp(&secret_number) {
-        Ordering::Less => println!("Too small!"),
-        Ordering::Greater => println!("Too big!"),
-        Ordering::Equal => println!("You win!"),
-    }
-}
-```
-
-Listing 2-4: Handling the possible return values of comparing two numbers
-
-The first new bit here is another `use` statement, bringing a type called
-`std::cmp::Ordering` into scope from the standard library. Like `Result`,
-`Ordering` is another enum, but the variants for `Ordering` are `Less`,
-`Greater`, and `Equal`. These are the three outcomes that are possible when you
-compare two values.
-
-Then we add five new lines at the bottom that use the `Ordering` type.
-
-The `cmp` method compares two values and can be called on anything that can be
-compared. It takes a reference to whatever you want to compare with: here it’s
-comparing the `guess` to the `secret_number`. Then it returns a variant of the
-`Ordering` enum we brought into scope with the `use` statement. We use a
-`match` expression to decide what to do next based on
-which variant of `Ordering` was returned from the call to `cmp` with the values
-in `guess` and `secret_number`.
-
-A `match` expression is made up of *arms*. An arm consists of a *pattern* and
-the code that should be run if the value given to the beginning of the `match`
-expression fits that arm’s pattern. Rust takes the value given to `match` and
-looks through each arm’s pattern in turn. The `match` construct and patterns
-are powerful features in Rust that let you express a variety of situations your
-code might encounter and make sure that you handle them all. These features
-will be covered in detail in Chapter 6 and Chapter 18, respectively.
-
-Let’s walk through an example of what would happen with the `match` expression
-used here. Say that the user has guessed 50 and the randomly generated secret
-number this time is 38. When the code compares 50 to 38, the `cmp` method will
-return `Ordering::Greater`, because 50 is greater than 38. The `match`
-expression gets the `Ordering::Greater` value and starts checking each arm’s
-pattern. It looks at the first arm’s pattern, `Ordering::Less`, and sees that
-the value `Ordering::Greater` does not match `Ordering::Less`, so it ignores
-the code in that arm and moves to the next arm. The next arm’s pattern,
-`Ordering::Greater`, *does* match `Ordering::Greater`! The associated code in
-that arm will execute and print `Too big!` to the screen. The `match`
-expression ends because it has no need to look at the last arm in this scenario.
-
-However, the code in Listing 2-4 won’t compile yet. Let’s try it:
-
-```
-$ cargo build
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-error[E0308]: mismatched types
-  --> src/main.rs:23:21
-   |
-23 |     match guess.cmp(&secret_number) {
-   |                     ^^^^^^^^^^^^^^ expected struct `std::string::String`, found integral variable
-   |
-   = note: expected type `&std::string::String`
-   = note:    found type `&{integer}`
-
-error: aborting due to previous error
-Could not compile `guessing_game`.
-```
-
-The core of the error states that there are *mismatched types*. Rust has a
-strong, static type system. However, it also has type inference. When we wrote
-`let guess = String::new()`, Rust was able to infer that `guess` should be a
-`String` and didn’t make us write the type. The `secret_number`, on the other
-hand, is a number type. A few number types can have a value between 1 and 100:
-`i32`, a 32-bit number; `u32`, an unsigned 32-bit number; `i64`, a 64-bit
-number; as well as others. Rust defaults to an `i32`, which is the type of
-`secret_number` unless you add type information elsewhere that would cause Rust
-to infer a different numerical type. The reason for the error is that Rust
-cannot compare a string and a number type.
-
-Ultimately, we want to convert the `String` the program reads as input into a
-real number type so we can compare it numerically to the guess. We can do that
-by adding the following two lines to the `main` function body:
-
-Filename: src/main.rs
-
-```
-// --snip--
-
-    let mut guess = String::new();
-
-    io::stdin().read_line(&mut guess)
-        .expect("Failed to read line");
-
-    let guess: u32 = guess.trim().parse()
-        .expect("Please type a number!");
-
-    println!("You guessed: {}", guess);
-
-    match guess.cmp(&secret_number) {
-        Ordering::Less => println!("Too small!"),
-        Ordering::Greater => println!("Too big!"),
-        Ordering::Equal => println!("You win!"),
-    }
-}
-```
-
-The two new lines are:
-
-```
-let guess: u32 = guess.trim().parse()
-    .expect("Please type a number!");
-```
-
-We create a variable named `guess`. But wait, doesn’t the program already have
-a variable named `guess`? It does, but Rust allows us to *shadow* the previous
-value of `guess` with a new one. This feature is often used in situations in
-which you want to convert a value from one type to another type. Shadowing lets
-us reuse the `guess` variable name rather than forcing us to create two unique
-variables, like `guess_str` and `guess` for example. (Chapter 3 covers
-shadowing in more detail.)
-
-We bind `guess` to the expression `guess.trim().parse()`. The `guess` in the
-expression refers to the original `guess` that was a `String` with the input in
-it. The `trim` method on a `String` instance will eliminate any whitespace at
-the beginning and end. Although `u32` can contain only numerical characters,
-the user must press enter to satisfy
-`read_line`. When the user presses enter, a
-newline character is added to the string. For example, if the user types 5 and presses enter,
-`guess` looks like this: `5\n`. The `\n` represents “newline,” the result of
-pressing enter. The `trim` method eliminates
-`\n`, resulting in just `5`.
-
-The `parse` method on strings parses a string into some
-kind of number. Because this method can parse a variety of number types, we
-need to tell Rust the exact number type we want by using `let guess: u32`. The
-colon (`:`) after `guess` tells Rust we’ll annotate the variable’s type. Rust
-has a few built-in number types; the `u32` seen here is an unsigned, 32-bit
-integer. It’s a good default choice for a small positive number. You’ll learn
-about other number types in Chapter 3. Additionally, the `u32` annotation in
-this example program and the comparison with `secret_number` means that Rust
-will infer that `secret_number` should be a `u32` as well. So now the
-comparison will be between two values of the same type!
-
-The call to `parse` could easily cause an error. If, for example, the string
-contained `A👍%`, there would be no way to convert that to a number. Because it
-might fail, the `parse` method returns a `Result` type, much as the `read_line`
-method does (discussed earlier in “Handling Potential Failure with the Result
-Type”). We’ll treat this `Result` the same way by using the `expect` method
-again. If `parse` returns an `Err` `Result` variant because it couldn’t create
-a number from the string, the `expect` call will crash the game and print the
-message we give it. If `parse` can successfully convert the string to a number,
-it will return the `Ok` variant of `Result`, and `expect` will return the
-number that we want from the `Ok` value.
-
-Let’s run the program now!
-
-```
-$ cargo run
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.43 secs
-     Running `target/guessing_game`
-Guess the number!
-The secret number is: 58
-Please input your guess.
-  76
-You guessed: 76
-Too big!
-```
-
-Nice! Even though spaces were added before the guess, the program still figured
-out that the user guessed 76. Run the program a few times to verify the
-different behavior with different kinds of input: guess the number correctly,
-guess a number that is too high, and guess a number that is too low.
-
-We have most of the game working now, but the user can make only one guess.
-Let’s change that by adding a loop!
-
-## Allowing Multiple Guesses with Looping
-
-The `loop` keyword creates an infinite loop. We’ll add that now to give users
-more chances at guessing the number:
-
-Filename: src/main.rs
-
-```
-// --snip--
-
-    println!("The secret number is: {}", secret_number);
-
-    loop {
-        println!("Please input your guess.");
-
-        // --snip--
-
-        match guess.cmp(&secret_number) {
-            Ordering::Less => println!("Too small!"),
-            Ordering::Greater => println!("Too big!"),
-            Ordering::Equal => println!("You win!"),
-        }
-    }
-}
-```
-
-As you can see, we’ve moved everything into a loop from the guess input prompt
-onward. Be sure to indent the lines inside the loop another four spaces each
-and run the program again. Notice that there is a new problem because the
-program is doing exactly what we told it to do: ask for another guess forever!
-It doesn’t seem like the user can quit!
-
-The user could always halt the program by using the keyboard shortcut ctrl-c. But there’s another way to escape this
-insatiable monster, as mentioned in the `parse` discussion in “Comparing the
-Guess to the Secret Number”: if the user enters a non-number answer, the
-program will crash. The user can take advantage of that in order to quit, as
-shown here:
-
-```
-$ cargo run
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-    Finished dev [unoptimized + debuginfo] target(s) in 1.50 secs
-     Running `target/guessing_game`
-Guess the number!
-The secret number is: 59
-Please input your guess.
-45
-You guessed: 45
-Too small!
-Please input your guess.
-60
-You guessed: 60
-Too big!
-Please input your guess.
-59
-You guessed: 59
-You win!
-Please input your guess.
-quit
-thread 'main' panicked at 'Please type a number!: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:785
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-error: Process didn't exit successfully: `target/debug/guess` (exit code: 101)
-```
-
-Typing `quit` actually quits the game, but so will any other non-number input.
-However, this is suboptimal to say the least. We want the game to automatically
-stop when the correct number is guessed.
-
-### Quitting After a Correct Guess
-
-Let’s program the game to quit when the user wins by adding a `break` statement:
-
-Filename: src/main.rs
-
-```
-// --snip--
-
-        match guess.cmp(&secret_number) {
-            Ordering::Less => println!("Too small!"),
-            Ordering::Greater => println!("Too big!"),
-            Ordering::Equal => {
-                println!("You win!");
-                break;
-            }
-        }
-    }
-}
-```
-
-Adding the `break` line after `You win!` makes the program exit the loop when
-the user guesses the secret number correctly. Exiting the loop also means
-exiting the program, because the loop is the last part of `main`.
-
-### Handling Invalid Input
-
-To further refine the game’s behavior, rather than crashing the program when
-the user inputs a non-number, let’s make the game ignore a non-number so the
-user can continue guessing. We can do that by altering the line where `guess`
-is converted from a `String` to a `u32`:
-
-```
-let guess: u32 = match guess.trim().parse() {
-    Ok(num) => num,
-    Err(_) => continue,
-};
-```
-
-Switching from an `expect` call to a `match` expression is how you generally
-move from crashing on an error to handling the error. Remember that `parse`
-returns a `Result` type and `Result` is an enum that has the variants `Ok` or
-`Err`. We’re using a `match` expression here, as we did with the `Ordering`
-result of the `cmp` method.
-
-If `parse` is able to successfully turn the string into a number, it will
-return an `Ok` value that contains the resulting number. That `Ok` value will
-match the first arm’s pattern, and the `match` expression will just return the
-`num` value that `parse` produced and put inside the `Ok` value. That number
-will end up right where we want it in the new `guess` variable we’re creating.
-
-If `parse` is *not* able to turn the string into a number, it will return an
-`Err` value that contains more information about the error. The `Err` value
-does not match the `Ok(num)` pattern in the first `match` arm, but it does
-match the `Err(_)` pattern in the second arm. The underscore, `_`, is a
-catchall value; in this example, we’re saying we want to match all `Err`
-values, no matter what information they have inside them. So the program will
-execute the second arm’s code, `continue`, which means to go to the next
-iteration of the `loop` and ask for another guess. So effectively, the program
-ignores all errors that `parse` might encounter!
-
-Now everything in the program should work as expected. Let’s try it:
-
-```
-$ cargo run
-   Compiling guessing_game v0.1.0 (file:///projects/guessing_game)
-     Running `target/guessing_game`
-Guess the number!
-The secret number is: 61
-Please input your guess.
-10
-You guessed: 10
-Too small!
-Please input your guess.
-99
-You guessed: 99
-Too big!
-Please input your guess.
-foo
-Please input your guess.
-61
-You guessed: 61
-You win!
-```
-
-Awesome! With one tiny final tweak, we will finish the guessing game. Recall
-that the program is still printing the secret number. That worked well for
-testing, but it ruins the game. Let’s delete the `println!` that outputs the
-secret number. Listing 2-5 shows the final code:
-
-Filename: src/main.rs
-
-```
-extern crate rand;
-
-use std::io;
-use std::cmp::Ordering;
-use rand::Rng;
-
-fn main() {
-    println!("Guess the number!");
-
-    let secret_number = rand::thread_rng().gen_range(1, 101);
-
-    loop {
-        println!("Please input your guess.");
-
-        let mut guess = String::new();
-
-        io::stdin().read_line(&mut guess)
-            .expect("Failed to read line");
-
-        let guess: u32 = match guess.trim().parse() {
-            Ok(num) => num,
-            Err(_) => continue,
-        };
-
-        println!("You guessed: {}", guess);
-
-        match guess.cmp(&secret_number) {
-            Ordering::Less => println!("Too small!"),
-            Ordering::Greater => println!("Too big!"),
-            Ordering::Equal => {
-                println!("You win!");
-                break;
-            }
-        }
-    }
-}
-```
-
-Listing 2-5: Complete guessing game code
-
-## Summary
-
-At this point, you’ve successfully built the guessing game! Congratulations!
-
-This project was a hands-on way to introduce you to many new Rust concepts:
-`let`, `match`, methods, associated functions, the use of external crates, and
-more. In the next few chapters, you’ll learn about these concepts in more
-detail. Chapter 3 covers concepts that most programming languages have, such as
-variables, data types, and functions, and shows how to use them in Rust.
-Chapter 4 explores ownership, a feature that makes Rust different from other
-languages. Chapter 5 discusses structs and method syntax, and Chapter 6
-explains how enums work.
diff --git a/src/doc/book/second-edition/nostarch/chapter03.md b/src/doc/book/second-edition/nostarch/chapter03.md
deleted file mode 100644
index 2350ce57b2..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter03.md
+++ /dev/null
@@ -1,1472 +0,0 @@
-
-[TOC]
-
-# Common Programming Concepts
-
-This chapter covers concepts that appear in almost every programming language
-and how they work in Rust. Many programming languages have much in common at
-their core. None of the concepts presented in this chapter are unique to Rust,
-but we’ll discuss them in the context of Rust and explain the conventions
-around using these concepts.
-
-Specifically, you’ll learn about variables, basic types, functions, comments,
-and control flow. These foundations will be in every Rust program, and learning
-them early will give you a strong core to start from.
-
-> ### Keywords
->
-> The Rust language has a set of *keywords* that are reserved for use by
-> the language only, much as in other languages. Keep in mind that you cannot
-> use these words as names of variables or functions. Most of the keywords have
-> special meanings, and you’ll be using them to do various tasks in your Rust
-> programs; a few have no current functionality associated with them but have
-> been reserved for functionality that might be added to Rust in the future. You
-> can find a list of the keywords in Appendix A.
-
-## Variables and Mutability
-
-As mentioned in Chapter 2, by default variables are immutable. This is one of
-many nudges Rust gives you to write your code in a way that takes advantage of
-the safety and easy concurrency that Rust offers. However, you still have the
-option to make your variables mutable. Let’s explore how and why Rust
-encourages you to favor immutability and why sometimes you might want to opt
-out.
-
-When a variable is immutable, once a value is bound to a name, you can’t change
-that value. To illustrate this, let’s generate a new project called *variables*
-in your *projects* directory by using `cargo new --bin variables`.
-
-Then, in your new *variables* directory, open *src/main.rs* and replace its
-code with the following code that won’t compile just yet:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 5;
-    println!("The value of x is: {}", x);
-    x = 6;
-    println!("The value of x is: {}", x);
-}
-```
-
-Save and run the program using `cargo run`. You should receive an error
-message, as shown in this output:
-
-```
-error[E0384]: cannot assign twice to immutable variable `x`
- --> src/main.rs:4:5
-  |
-2 |     let x = 5;
-  |         - first assignment to `x`
-3 |     println!("The value of x is: {}", x);
-4 |     x = 6;
-  |     ^^^^^ cannot assign twice to immutable variable
-```
-
-This example shows how the compiler helps you find errors in your programs.
-Even though compiler errors can be frustrating, they only mean your program
-isn’t safely doing what you want it to do yet; they do *not* mean that you’re
-not a good programmer! Experienced Rustaceans still get compiler errors.
-
-The error indicates that the cause of the error is that you `cannot assign twice
-to immutable variable x`, because you tried to assign a second value to the
-immutable `x` variable.
-
-It’s important that we get compile-time errors when we attempt to change a
-value that we previously designated as immutable because this very situation
-can lead to bugs. If one part of our code operates on the assumption that a
-value will never change and another part of our code changes that value, it’s
-possible that the first part of the code won’t do what it was designed to do.
-The cause of this kind of bug can be difficult to track down after the fact,
-especially when the second piece of code changes the value only *sometimes*.
-
-In Rust, the compiler guarantees that when you state that a value won’t change,
-it really won’t change. That means that when you’re reading and writing code,
-you don’t have to keep track of how and where a value might change. Your code
-is thus easier to reason through.
-
-But mutability can be very useful. Variables are immutable only by default; as
-you did in Chapter 2, you can make them mutable by adding `mut` in front of the
-variable name. In addition to allowing this value to change, `mut` conveys
-intent to future readers of the code by indicating that other parts of the code
-will be changing this variable value.
-
-For example, let’s change *src/main.rs* to the following:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let mut x = 5;
-    println!("The value of x is: {}", x);
-    x = 6;
-    println!("The value of x is: {}", x);
-}
-```
-
-When we run the program now, we get this:
-
-```
-$ cargo run
-   Compiling variables v0.1.0 (file:///projects/variables)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.30 secs
-     Running `target/debug/variables`
-The value of x is: 5
-The value of x is: 6
-```
-
-We’re allowed to change the value that `x` binds to from `5` to `6` when `mut`
-is used. In some cases, you’ll want to make a variable mutable because it makes
-the code more convenient to write than if it had only immutable variables.
-
-There are multiple trade-offs to consider in addition to the prevention of
-bugs. For example, in cases where you’re using large data structures, mutating
-an instance in place may be faster than copying and returning newly allocated
-instances. With smaller data structures, creating new instances and writing in
-a more functional programming style may be easier to think through, so lower
-performance might be a worthwhile penalty for gaining that clarity.
-
-### Differences Between Variables and Constants
-
-Being unable to change the value of a variable might have reminded you of
-another programming concept that most other languages have: *constants*. Like
-immutable variables, constants are values that are bound to a name and are not
-allowed to change, but there are a few differences between constants and
-variables.
-
-First, you aren’t allowed to use `mut` with constants. Constants aren’t just
-immutable by default—they’re always immutable.
-
-You declare constants using the `const` keyword instead of the `let` keyword,
-and the type of the value *must* be annotated. We’re about to cover types and
-type annotations in the next section, “Data Types,” so don’t worry about the
-details right now. Just know that you must always annotate the type.
-
-Constants can be declared in any scope, including the global scope, which makes
-them useful for values that many parts of code need to know about.
-
-The last difference is that constants may be set only to a constant expression,
-not the result of a function call or any other value that could only be
-computed at runtime.
-
-Here’s an example of a constant declaration where the constant’s name is
-`MAX_POINTS` and its value is set to 100,000. (Rust’s constant naming
-convention is to use all uppercase with underscores between words):
-
-```
-const MAX_POINTS: u32 = 100_000;
-```
-
-Constants are valid for the entire time a program runs, within the scope they
-were declared in, making them a useful choice for values in your application
-domain that multiple parts of the program might need to know about, such as the
-maximum number of points any player of a game is allowed to earn or the speed
-of light.
-
-Naming hardcoded values used throughout your program as constants is useful in
-conveying the meaning of that value to future maintainers of the code. It also
-helps to have only one place in your code you would need to change if the
-hardcoded value needed to be updated in the future.
-
-### Shadowing
-
-As you saw in the “Comparing the Guess to the Secret Number” section in Chapter
-2, you can declare a new variable with the same name as a previous variable,
-and the new variable shadows the previous variable. Rustaceans say that the
-first variable is *shadowed* by the second, which means that the second
-variable’s value is what appears when the variable is used. We can shadow a
-variable by using the same variable’s name and repeating the use of the `let`
-keyword as follows:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 5;
-
-    let x = x + 1;
-
-    let x = x * 2;
-
-    println!("The value of x is: {}", x);
-}
-```
-
-This program first binds `x` to a value of `5`. Then it shadows `x` by
-repeating `let x =`, taking the original value and adding `1` so the value of
-`x` is then `6`. The third `let` statement also shadows `x`, multiplying the
-previous value by `2` to give `x` a final value of `12`. When we run this
-program, it will output the following:
-
-```
-$ cargo run
-   Compiling variables v0.1.0 (file:///projects/variables)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
-     Running `target/debug/variables`
-The value of x is: 12
-```
-
-Shadowing is different than marking a variable as `mut`, because we’ll get a
-compile-time error if we accidentally try to reassign to this variable without
-using the `let` keyword. By using `let`, we can perform a few transformations
-on a value but have the variable be immutable after those transformations have
-been completed.
-
-The other difference between `mut` and shadowing is that because we’re
-effectively creating a new variable when we use the `let` keyword again, we can
-change the type of the value but reuse the same name. For example, say our
-program asks a user to show how many spaces they want between some text by
-inputting space characters, but we really want to store that input as a number:
-
-```
-let spaces = "   ";
-let spaces = spaces.len();
-```
-
-This construct is allowed because the first `spaces` variable is a string type
-and the second `spaces` variable, which is a brand-new variable that happens to
-have the same name as the first one, is a number type. Shadowing thus spares us
-from having to come up with different names, such as `spaces_str` and
-`spaces_num`; instead, we can reuse the simpler `spaces` name. However, if we
-try to use `mut` for this, as shown here, we’ll get a compile-time error:
-
-```
-let mut spaces = "   ";
-spaces = spaces.len();
-```
-
-The error says we’re not allowed to mutate a variable’s type:
-
-```
-error[E0308]: mismatched types
- --> src/main.rs:3:14
-  |
-3 |     spaces = spaces.len();
-  |              ^^^^^^^^^^^^ expected &str, found usize
-  |
-  = note: expected type `&str`
-             found type `usize`
-```
-
-Now that we’ve explored how variables work, let’s look at more data types they
-can have.
-
-## Data Types
-
-Every value in Rust is of a certain *data type*, which tells Rust what kind of
-data is being specified so it knows how to work with that data. We’ll look at
-two data type subsets: scalar and compound.
-
-Keep in mind that Rust is a *statically typed* language, which means that it
-must know the types of all variables at compile time. The compiler can usually
-infer what type we want to use based on the value and how we use it. In cases
-when many types are possible, such as when we converted a `String` to a numeric
-type using `parse` in the “Comparing the Guess to the Secret Number” section in
-Chapter 2, we must add a type annotation, like this:
-
-```
-let guess: u32 = "42".parse().expect("Not a number!");
-```
-
-If we don’t add the type annotation here, Rust will display the following
-error, which means the compiler needs more information from us to know which
-type we want to use:
-
-```
-error[E0282]: type annotations needed
- --> src/main.rs:2:9
-  |
-2 |     let guess = "42".parse().expect("Not a number!");
-  |         ^^^^^
-  |         |
-  |         cannot infer type for `_`
-  |         consider giving `guess` a type
-```
-
-You’ll see different type annotations for other data types.
-
-### Scalar Types
-
-A *scalar* type represents a single value. Rust has four primary scalar types:
-integers, floating-point numbers, Booleans, and characters. You may recognize
-these from other programming languages. Let’s jump into how they work in Rust.
-
-#### Integer Types
-
-An *integer* is a number without a fractional component. We used one integer
-type in Chapter 2, the `u32` type. This type declaration indicates that the
-value it’s associated with should be an unsigned integer (signed integer types
-start with `i`, instead of `u`) that takes up 32 bits of space. Table 3-1 shows
-the built-in integer types in Rust. Each variant in the Signed and Unsigned
-columns (for example, `i16`) can be used to declare the type of an integer
-value.
-
-Table 3-1: Integer Types in Rust
-
-| Length | Signed  | Unsigned |
-|--------|---------|----------|
-| 8-bit  | `i8`    | `u8`     |
-| 16-bit | `i16`   | `u16`    |
-| 32-bit | `i32`   | `u32`    |
-| 64-bit | `i64`   | `u64`    |
-| arch   | `isize` | `usize`  |
-
-Each variant can be either signed or unsigned and has an explicit size.
-*Signed* and *unsigned* refer to whether it’s possible for the number to be
-negative or positive—in other words, whether the number needs to have a sign
-with it (signed) or whether it will only ever be positive and can therefore be
-represented without a sign (unsigned). It’s like writing numbers on paper: when
-the sign matters, a number is shown with a plus sign or a minus sign; however,
-when it’s safe to assume the number is positive, it’s shown with no sign.
-Signed numbers are stored using two’s complement representation (if you’re
-unsure what this is, you can search for it online; an explanation is outside
-the scope of this book).
-
-Each signed variant can store numbers from -(2n - 1) to 2n -
-1 - 1 inclusive, where *n* is the number of bits that variant uses. So an
-`i8` can store numbers from -(27) to 27 - 1, which equals
--128 to 127. Unsigned variants can store numbers from 0 to 2n - 1,
-so a `u8` can store numbers from 0 to 28 - 1, which equals 0 to 255.
-
-Additionally, the `isize` and `usize` types depend on the kind of computer your
-program is running on: 64 bits if you’re on a 64-bit architecture and 32 bits
-if you’re on a 32-bit architecture.
-
-You can write integer literals in any of the forms shown in Table 3-2. Note
-that all number literals except the byte literal allow a type suffix, such as
-`57u8`, and `_` as a visual separator, such as `1_000`.
-
-Table 3-2: Integer Literals in Rust
-
-| Number literals  | Example       |
-|------------------|---------------|
-| Decimal          | `98_222`      |
-| Hex              | `0xff`        |
-| Octal            | `0o77`        |
-| Binary           | `0b1111_0000` |
-| Byte (`u8` only) | `b'A'`        |
-
-So how do you know which type of integer to use? If you’re unsure, Rust’s
-defaults are generally good choices, and integer types default to `i32`: this
-type is generally the fastest, even on 64-bit systems. The primary situation in
-which you’d use `isize` or `usize` is when indexing some sort of collection.
-
-#### Floating-Point Types
-
-Rust also has two primitive types for *floating-point numbers*, which are
-numbers with decimal points. Rust’s floating-point types are `f32` and `f64`,
-which are 32 bits and 64 bits in size, respectively. The default type is `f64`
-because on modern CPUs it’s roughly the same speed as `f32` but is capable of
-more precision.
-
-Here’s an example that shows floating-point numbers in action:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 2.0; // f64
-
-    let y: f32 = 3.0; // f32
-}
-```
-
-Floating-point numbers are represented according to the IEEE-754 standard. The
-`f32` type is a single-precision float, and `f64` has double precision.
-
-#### Numeric Operations
-
-Rust supports the basic mathematical operations you’d expect for all of the
-number types: addition, subtraction, multiplication, division, and remainder.
-The following code shows how you’d use each one in a `let` statement:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    // addition
-    let sum = 5 + 10;
-
-    // subtraction
-    let difference = 95.5 - 4.3;
-
-    // multiplication
-    let product = 4 * 30;
-
-    // division
-    let quotient = 56.7 / 32.2;
-
-    // remainder
-    let remainder = 43 % 5;
-}
-```
-
-Each expression in these statements uses a mathematical operator and evaluates
-to a single value, which is then bound to a variable. Appendix B contains a
-list of all operators that Rust provides.
-
-#### The Boolean Type
-
-As in most other programming languages, a Boolean type in Rust has two possible
-values: `true` and `false`. The Boolean type in Rust is specified using `bool`.
-For example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let t = true;
-
-    let f: bool = false; // with explicit type annotation
-}
-```
-
-The main way to consume Boolean values is through conditionals, such as an `if`
-expression. We’ll cover how `if` expressions work in Rust in the “Control Flow”
-section.
-
-#### The Character Type
-
-So far we’ve worked only with numbers, but Rust supports letters too. Rust’s
-`char` type is the language’s most primitive alphabetic type, and the following
-code shows one way to use it. (Note that the `char` type is specified with
-single quotes, as opposed to strings, which use double quotes.)
-
-Filename: src/main.rs
-
-```
-fn main() {
-   let c = 'z';
-   let z = 'ℤ';
-   let heart_eyed_cat = '😻';
-}
-```
-
-Rust’s `char` type represents a Unicode Scalar Value, which means it can
-represent a lot more than just ASCII. Accented letters; Chinese, Japanese, and
-Korean ideographs; emoji; and zero-width spaces are all valid `char` types in
-Rust. Unicode Scalar Values range from `U+0000` to `U+D7FF` and `U+E000` to
-`U+10FFFF` inclusive. However, a “character” isn’t really a concept in Unicode,
-so your human intuition for what a “character” is may not match up with what a
-`char` is in Rust. We’ll discuss this topic in detail in “Strings” in Chapter 8.
-
-### Compound Types
-
-*Compound types* can group multiple values into one type. Rust has two
-primitive compound types: tuples and arrays.
-
-#### The Tuple Type
-
-A tuple is a general way of grouping together some number of other values with
-a variety of types into one compound type.
-
-We create a tuple by writing a comma-separated list of values inside
-parentheses. Each position in the tuple has a type, and the types of the
-different values in the tuple don’t have to be the same. We’ve added optional
-type annotations in this example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let tup: (i32, f64, u8) = (500, 6.4, 1);
-}
-```
-
-The variable `tup` binds to the entire tuple, because a tuple is considered a
-single compound element. To get the individual values out of a tuple, we can
-use pattern matching to destructure a tuple value, like this:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let tup = (500, 6.4, 1);
-
-    let (x, y, z) = tup;
-
-    println!("The value of y is: {}", y);
-}
-```
-
-This program first creates a tuple and binds it to the variable `tup`. It then
-uses a pattern with `let` to take `tup` and turn it into three separate
-variables, `x`, `y`, and `z`. This is called *destructuring*, because it breaks
-the single tuple into three parts. Finally, the program prints the value of
-`y`, which is `6.4`.
-
-In addition to destructuring through pattern matching, we can access a tuple
-element directly by using a period (`.`) followed by the index of the value we
-want to access. For example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x: (i32, f64, u8) = (500, 6.4, 1);
-
-    let five_hundred = x.0;
-
-    let six_point_four = x.1;
-
-    let one = x.2;
-}
-```
-
-This program creates a tuple, `x`, and then makes new variables for each
-element by using their index. As with most programming languages, the first
-index in a tuple is 0.
-
-#### The Array Type
-
-Another way to have a collection of multiple values is with an *array*. Unlike
-a tuple, every element of an array must have the same type. Arrays in Rust are
-different from arrays in some other languages because arrays in Rust have a
-fixed length: once declared, they cannot grow or shrink in size.
-
-In Rust, the values going into an array are written as a comma-separated list
-inside square brackets:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let a = [1, 2, 3, 4, 5];
-}
-```
-
-Arrays are useful when you want your data allocated on the stack rather than
-the heap (we will discuss the stack and the heap more in Chapter 4), or when
-you want to ensure you always have a fixed number of elements. An array isn’t
-as flexible as the vector type, though. A vector is a similar collection type
-provided by the standard library that *is* allowed to grow or shrink in size.
-If you’re unsure whether to use an array or a vector, you should probably use a
-vector. Chapter 8 discusses vectors in more detail.
-
-An example of when you might want to use an array rather than a vector is in a
-program that needs to know the names of the months of the year. It’s very
-unlikely that such a program will need to add or remove months, so you can use
-an array because you know it will always contain 12 items:
-
-```
-let months = ["January", "February", "March", "April", "May", "June", "July",
-              "August", "September", "October", "November", "December"];
-```
-
-##### Accessing Array Elements
-
-An array is a single chunk of memory allocated on the stack. You can access
-elements of an array using indexing, like this:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let a = [1, 2, 3, 4, 5];
-
-    let first = a[0];
-    let second = a[1];
-}
-```
-
-In this example, the variable named `first` will get the value `1`, because
-that is the value at index `[0]` in the array. The variable named `second` will
-get the value `2` from index `[1]` in the array.
-
-##### Invalid Array Element Access
-
-What happens if you try to access an element of an array that is past the end
-of the array? Say you change the example to the following code, which will
-compile but exit with an error when it runs:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let a = [1, 2, 3, 4, 5];
-    let index = 10;
-
-    let element = a[index];
-
-    println!("The value of element is: {}", element);
-}
-```
-
-Running this code using `cargo run` produces the following result:
-
-```
-$ cargo run
-   Compiling arrays v0.1.0 (file:///projects/arrays)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
-     Running `target/debug/arrays`
-thread '
' panicked at 'index out of bounds: the len is 5 but the index is
- 10', src/main.rs:6
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-```
-
-The compilation didn’t produce any errors, but the program resulted in a
-*runtime* error and didn’t exit successfully. When you attempt to access an
-element using indexing, Rust will check that the index you’ve specified is less
-than the array length. If the index is greater than the length, Rust will
-*panic*, which is the term Rust uses when a program exits with an error.
-
-This is the first example of Rust’s safety principles in action. In many
-low-level languages, this kind of check is not done, and when you provide an
-incorrect index, invalid memory can be accessed. Rust protects you against this
-kind of error by immediately exiting instead of allowing the memory access and
-continuing. Chapter 9 discusses more of Rust’s error handling.
-
-## Functions
-
-Functions are pervasive in Rust code. You’ve already seen one of the most
-important functions in the language: the `main` function, which is the entry
-point of many programs. You’ve also seen the `fn` keyword, which allows you to
-declare new functions.
-
-Rust code uses *snake case* as the conventional style for function and variable
-names. In snake case, all letters are lowercase and underscores separate words.
-Here’s a program that contains an example function definition:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    println!("Hello, world!");
-
-    another_function();
-}
-
-fn another_function() {
-    println!("Another function.");
-}
-```
-
-Function definitions in Rust start with `fn` and have a set of parentheses
-after the function name. The curly brackets tell the compiler where the
-function body begins and ends.
-
-We can call any function we’ve defined by entering its name followed by a set
-of parentheses. Because `another_function` is defined in the program, it can be
-called from inside the `main` function. Note that we defined `another_function`
-*after* the `main` function in the source code; we could have defined it before
-as well. Rust doesn’t care where you define your functions, only that they’re
-defined somewhere.
-
-Let’s start a new binary project named *functions* to explore functions
-further. Place the `another_function` example in *src/main.rs* and run it. You
-should see the following output:
-
-```
-$ cargo run
-   Compiling functions v0.1.0 (file:///projects/functions)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.28 secs
-     Running `target/debug/functions`
-Hello, world!
-Another function.
-```
-
-The lines execute in the order in which they appear in the `main` function.
-First, the “Hello, world!” message prints, and then `another_function` is
-called and its message is printed.
-
-### Function Parameters
-
-Functions can also be defined to have *parameters*, which are special variables
-that are part of a function’s signature. When a function has parameters, you
-can provide it with concrete values for those parameters. Technically, the
-concrete values are called *arguments*, but in casual conversation, people tend
-to use the words *parameter* and *argument* interchangeably for either the
-variables in a function’s definition or the concrete values passed in when you
-call a function.
-
-The following rewritten version of `another_function` shows what parameters
-look like in Rust:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    another_function(5);
-}
-
-fn another_function(x: i32) {
-    println!("The value of x is: {}", x);
-}
-```
-
-Try running this program; you should get the following output:
-
-```
-$ cargo run
-   Compiling functions v0.1.0 (file:///projects/functions)
-    Finished dev [unoptimized + debuginfo] target(s) in 1.21 secs
-     Running `target/debug/functions`
-The value of x is: 5
-```
-
-The declaration of `another_function` has one parameter named `x`. The type of
-`x` is specified as `i32`. When `5` is passed to `another_function`, the
-`println!` macro puts `5` where the pair of curly brackets were in the format
-string.
-
-In function signatures, you *must* declare the type of each parameter. This is
-a deliberate decision in Rust’s design: requiring type annotations in function
-definitions means the compiler almost never needs you to use them elsewhere in
-the code to figure out what you mean.
-
-When you want a function to have multiple parameters, separate the parameter
-declarations with commas, like this:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    another_function(5, 6);
-}
-
-fn another_function(x: i32, y: i32) {
-    println!("The value of x is: {}", x);
-    println!("The value of y is: {}", y);
-}
-```
-
-This example creates a function with two parameters, both of which are `i32`
-types. The function then prints the values in both of its parameters. Note that
-function parameters don’t all need to be the same type, they just happen to be
-in this example.
-
-Let’s try running this code. Replace the program currently in your *functions*
-project’s *src/main.rs* file with the preceding example and run it using `cargo
-run`:
-
-```
-$ cargo run
-   Compiling functions v0.1.0 (file:///projects/functions)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
-     Running `target/debug/functions`
-The value of x is: 5
-The value of y is: 6
-```
-
-Because we called the function with `5` as the value for  `x` and `6` is passed
-as the value for `y`, the two strings are printed with these values.
-
-### Function Bodies
-
-Function bodies are made up of a series of statements optionally ending in an
-expression. So far, we’ve only covered functions without an ending expression,
-but you have seen an expression as part of statements. Because Rust is an
-expression-based language, this is an important distinction to understand.
-Other languages don’t have the same distinctions, so let’s look at what
-statements and expressions are and how their differences affect the bodies of
-functions.
-
-### Statements and Expressions
-
-We’ve actually already used statements and expressions. *Statements* are
-instructions that perform some action and do not return a value. *Expressions*
-evaluate to a resulting value. Let’s look at some examples.
-
-Creating a variable and assigning a value to it with the `let` keyword is a
-statement. In Listing 3-1, `let y = 6;` is a statement:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let y = 6;
-}
-```
-
-Listing 3-1: A `main` function declaration containing one statement
-
-Function definitions are also statements; the entire preceding example is a
-statement in itself.
-
-Statements do not return values. Therefore, you can’t assign a `let` statement
-to another variable, as the following code tries to do; you’ll get an error:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = (let y = 6);
-}
-```
-
-When you run this program, the error you’ll get looks like this:
-
-```
-$ cargo run
-   Compiling functions v0.1.0 (file:///projects/functions)
-error: expected expression, found statement (`let`)
- --> src/main.rs:2:14
-  |
-2 |     let x = (let y = 6);
-  |              ^^^
-  |
-  = note: variable declaration using `let` is a statement
-```
-
-The `let y = 6` statement does not return a value, so there isn’t anything for
-`x` to bind to. This is different from what happens in other languages, such as
-C and Ruby, where the assignment returns the value of the assignment. In those
-languages, you can write `x = y = 6` and have both `x` and `y` have the value
-`6`; that is not the case in Rust.
-
-Expressions evaluate to something and make up most of the rest of the code that
-you’ll write in Rust. Consider a simple math operation, such as `5 + 6`, which
-is an expression that evaluates to the value `11`. Expressions can be part of
-statements: in Listing 3-1, the `6` in the statement `let y = 6;` is an
-expression that evaluates to the value `6`. Calling a function is an
-expression. Calling a macro is an expression. The block that we use to create
-new scopes, `{}`, is an expression, for example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 5;
-
-    let y = {
-        let x = 3;
-        x + 1
-    };
-
-    println!("The value of y is: {}", y);
-}
-```
-
-This expression:
-
-```
-{
-    let x = 3;
-    x + 1
-}
-```
-
-is a block that, in this case, evaluates to `4`. That value gets bound to `y`
-as part of the `let` statement. Note the `x + 1` line without a semicolon at
-the end, which is unlike most of the lines you’ve seen so far. Expressions do
-not include ending semicolons. If you add a semicolon to the end of an
-expression, you turn it into a statement, which will then not return a value.
-Keep this in mind as you explore function return values and expressions next.
-
-### Functions with Return Values
-
-Functions can return values to the code that calls them. We don’t name return
-values, but we do declare their type after an arrow (`->`). In Rust, the return
-value of the function is synonymous with the value of the final expression in
-the block of the body of a function. You can return early from a function by
-using the `return` keyword and specifying a value, but most functions return
-the last expression implicitly. Here’s an example of a function that returns a
-value:
-
-Filename: src/main.rs
-
-```
-fn five() -> i32 {
-    5
-}
-
-fn main() {
-    let x = five();
-
-    println!("The value of x is: {}", x);
-}
-```
-
-There are no function calls, macros, or even `let` statements in the `five`
-function—just the number `5` by itself. That’s a perfectly valid function in
-Rust. Note that the function’s return type is specified, too, as `-> i32`. Try
-running this code; the output should look like this:
-
-```
-$ cargo run
-   Compiling functions v0.1.0 (file:///projects/functions)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.30 secs
-     Running `target/debug/functions`
-The value of x is: 5
-```
-
-The `5` in `five` is the function’s return value, which is why the return type
-is `i32`. Let’s examine this in more detail. There are two important bits:
-first, the line `let x = five();` shows that we’re using the return value of a
-function to initialize a variable. Because the function `five` returns a `5`,
-that line is the same as the following:
-
-```
-let x = 5;
-```
-
-Second, the `five` function has no parameters and defines the type of the
-return value, but the body of the function is a lonely `5` with no semicolon
-because it’s an expression whose value we want to return.
-
-Let’s look at another example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = plus_one(5);
-
-    println!("The value of x is: {}", x);
-}
-
-fn plus_one(x: i32) -> i32 {
-    x + 1
-}
-```
-
-Running this code will print `The value of x is: 6`. But if we place a
-semicolon at the end of the line containing `x + 1`, changing it from an
-expression to a statement, we’ll get an error.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = plus_one(5);
-
-    println!("The value of x is: {}", x);
-}
-
-fn plus_one(x: i32) -> i32 {
-    x + 1;
-}
-```
-
-Running this code produces an error, as follows:
-
-```
-error[E0308]: mismatched types
- --> src/main.rs:7:28
-  |
-7 |   fn plus_one(x: i32) -> i32 {
-  |  ____________________________^
-8 | |     x + 1;
-  | |          - help: consider removing this semicolon
-9 | | }
-  | |_^ expected i32, found ()
-  |
-  = note: expected type `i32`
-             found type `()`
-```
-
-The main error message, “mismatched types,” reveals the core issue with this
-code. The definition of the function `plus_one` says that it will return an
-`i32`, but statements don’t evaluate to a value, which is expressed by `()`,
-the empty tuple. Therefore, nothing is returned, which contradicts the function
-definition and results in an error. In this output, Rust provides a message to
-possibly help rectify this issue: it suggests removing the semicolon, which
-would fix the error.
-
-## Comments
-
-All programmers strive to make their code easy to understand, but sometimes
-extra explanation is warranted. In these cases, programmers leave notes, or
-*comments*, in their source code that the compiler will ignore but people
-reading the source code may find useful.
-
-Here’s a simple comment:
-
-```
-// Hello, world.
-```
-
-In Rust, comments must start with two slashes and continue until the end of the
-line. For comments that extend beyond a single line, you’ll need to include
-`//` on each line, like this:
-
-```
-// So we’re doing something complicated here, long enough that we need
-// multiple lines of comments to do it! Whew! Hopefully, this comment will
-// explain what’s going on.
-```
-
-Comments can also be placed at the end of lines containing code:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let lucky_number = 7; // I’m feeling lucky today.
-}
-```
-
-But you’ll more often see them used in this format, with the comment on a
-separate line above the code it’s annotating:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    // I’m feeling lucky today.
-    let lucky_number = 7;
-}
-```
-
-Rust also has another kind of comment, documentation comments, which we’ll
-discuss in Chapter 14.
-
-## Control Flow
-
-Deciding whether or not to run some code depending on if a condition is true
-and deciding to run some code repeatedly while a condition is true are basic
-building blocks in most programming languages. The most common constructs that
-let you control the flow of execution of Rust code are `if` expressions and
-loops.
-
-### `if` Expressions
-
-An `if` expression allows you to branch your code depending on conditions. You
-provide a condition and then state, “If this condition is met, run this block
-of code. If the condition is not met, do not run this block of code.”
-
-Create a new project called *branches* in your *projects* directory to explore
-the `if` expression. In the *src/main.rs* file, input the following:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let number = 3;
-
-    if number < 5 {
-        println!("condition was true");
-    } else {
-        println!("condition was false");
-    }
-}
-```
-
-
-
-All `if` expressions start with the keyword `if`, which is followed by a
-condition. In this case, the condition checks whether or not the variable
-`number` has a value less than 5. The block of code we want to execute if the
-condition is true is placed immediately after the condition inside curly
-brackets. Blocks of code associated with the conditions in `if` expressions are
-sometimes called *arms*, just like the arms in `match` expressions that we
-discussed in the “Comparing the Guess to the Secret Number” section of
-Chapter 2.
-
-Optionally, we can also include an `else` expression, which we chose
-to do here, to give the program an alternative block of code to execute should
-the condition evaluate to false. If you don’t provide an `else` expression and
-the condition is false, the program will just skip the `if` block and move on
-to the next bit of code.
-
-Try running this code; you should see the following output:
-
-```
-$ cargo run
-   Compiling branches v0.1.0 (file:///projects/branches)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
-     Running `target/debug/branches`
-condition was true
-```
-
-Let’s try changing the value of `number` to a value that makes the condition
-`false` to see what happens:
-
-```
-let number = 7;
-```
-
-Run the program again, and look at the output:
-
-```
-$ cargo run
-   Compiling branches v0.1.0 (file:///projects/branches)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
-     Running `target/debug/branches`
-condition was false
-```
-
-It’s also worth noting that the condition in this code *must* be a `bool`. If
-the condition isn’t a `bool`, we’ll get an error. For example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let number = 3;
-
-    if number {
-        println!("number was three");
-    }
-}
-```
-
-The `if` condition evaluates to a value of `3` this time, and Rust throws an
-error:
-
-```
-error[E0308]: mismatched types
- --> src/main.rs:4:8
-  |
-4 |     if number {
-  |        ^^^^^^ expected bool, found integral variable
-  |
-  = note: expected type `bool`
-             found type `{integer}`
-```
-
-The error indicates that Rust expected a `bool` but got an integer. Unlike
-languages such as Ruby and JavaScript, Rust will not automatically try to
-convert non-Boolean types to a Boolean. You must be explicit and always provide
-`if` with a Boolean as its condition. If we want the `if` code block to run
-only when a number is not equal to `0`, for example, we can change the `if`
-expression to the following:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let number = 3;
-
-    if number != 0 {
-        println!("number was something other than zero");
-    }
-}
-```
-
-Running this code will print `number was something other than zero`.
-
-#### Handling Multiple Conditions with `else if`
-
-You can have multiple conditions by combining `if` and `else` in an `else if`
-expression. For example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let number = 6;
-
-    if number % 4 == 0 {
-        println!("number is divisible by 4");
-    } else if number % 3 == 0 {
-        println!("number is divisible by 3");
-    } else if number % 2 == 0 {
-        println!("number is divisible by 2");
-    } else {
-        println!("number is not divisible by 4, 3, or 2");
-    }
-}
-```
-
-This program has four possible paths it can take. After running it, you should
-see the following output:
-
-```
-$ cargo run
-   Compiling branches v0.1.0 (file:///projects/branches)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
-     Running `target/debug/branches`
-number is divisible by 3
-```
-
-When this program executes, it checks each `if` expression in turn and executes
-the first body for which the condition holds true. Note that even though 6 is
-divisible by 2, we don’t see the output `number is divisible by 2`, nor do we
-see the `number is not divisible by 4, 3, or 2` text from the `else` block.
-That’s because Rust only executes the block for the first true condition, and
-once it finds one, it doesn’t even check the rest.
-
-Using too many `else if` expressions can clutter your code, so if you have more
-than one, you might want to refactor your code. Chapter 6 describes a powerful
-Rust branching construct called `match` for these cases.
-
-#### Using `if` in a `let` Statement
-
-Because `if` is an expression, we can use it on the right side of a `let`
-statement, as in Listing 3-2:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let condition = true;
-    let number = if condition {
-        5
-    } else {
-        6
-    };
-
-    println!("The value of number is: {}", number);
-}
-```
-
-Listing 3-2: Assigning the result of an `if` expression to a variable
-
-The `number` variable will be bound to a value based on the outcome of the `if`
-expression. Run this code to see what happens:
-
-```
-$ cargo run
-   Compiling branches v0.1.0 (file:///projects/branches)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.30 secs
-     Running `target/debug/branches`
-The value of number is: 5
-```
-
-Remember that blocks of code evaluate to the last expression in them, and
-numbers by themselves are also expressions. In this case, the value of the
-whole `if` expression depends on which block of code executes. This means the
-values that have the potential to be results from each arm of the `if` must be
-the same type; in Listing 3-2, the results of both the `if` arm and the `else`
-arm were `i32` integers. If the types are mismatched, as in the following
-example, we’ll get an error:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let condition = true;
-
-    let number = if condition {
-        5
-    } else {
-        "six"
-    };
-
-    println!("The value of number is: {}", number);
-}
-```
-
-When we try to run this code, we’ll get an error. The `if` and `else` arms have
-value types that are incompatible, and Rust indicates exactly where to find the
-problem in the program:
-
-```
-error[E0308]: if and else have incompatible types
- --> src/main.rs:4:18
-  |
-4 |       let number = if condition {
-  |  __________________^
-5 | |         5
-6 | |     } else {
-7 | |         "six"
-8 | |     };
-  | |_____^ expected integral variable, found &str
-  |
-  = note: expected type `{integer}`
-             found type `&str`
-```
-
-The expression in the `if` block evaluates to an integer, and the expression in
-the `else` block evaluates to a string. This won’t work because variables must
-have a single type. Rust needs to know at compile time what type the `number`
-variable is, definitively, so it can verify at compile time that its type is
-valid everywhere we use `number`. Rust wouldn’t be able to do that if the type
-of `number` was only determined at runtime; the compiler would be more complex
-and would make fewer guarantees about the code if it had to keep track of
-multiple hypothetical types for any variable.
-
-### Repetition with Loops
-
-It’s often useful to execute a block of code more than once. For this task,
-Rust provides several *loops*. A loop runs through the code inside the loop
-body to the end and then starts immediately back at the beginning. To
-experiment with loops, let’s make a new project called *loops*.
-
-Rust has three kinds of loops: `loop`, `while`, and `for`. Let’s try each one.
-
-#### Repeating Code with `loop`
-
-The `loop` keyword tells Rust to execute a block of code over and over again
-forever or until you explicitly tell it to stop.
-
-As an example, change the *src/main.rs* file in your *loops* directory to look
-like this:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    loop {
-        println!("again!");
-    }
-}
-```
-
-When we run this program, we’ll see `again!` printed over and over continuously
-until we stop the program manually. Most terminals support a keyboard shortcut,
-ctrl-c, to halt a program that is stuck in a
-continual loop. Give it a try:
-
-```
-$ cargo run
-   Compiling loops v0.1.0 (file:///projects/loops)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.29 secs
-     Running `target/debug/loops`
-again!
-again!
-again!
-again!
-^Cagain!
-```
-
-The symbol `^C` represents where you pressed ctrl-c
-. You may or may not see the word `again!` printed after the `^C`,
-depending on where the code was in the loop when it received the halt signal.
-
-Fortunately, Rust provides another, more reliable way to break out of a loop.
-You can place the `break` keyword within the loop to tell the program when to
-stop executing the loop. Recall that we did this in the guessing game in the
-“Quitting After a Correct Guess” section of Chapter 2 to exit the
-program when the user won the game by guessing the correct number.
-
-#### Conditional Loops with `while`
-
-It’s often useful for a program to evaluate a condition within a loop. While
-the condition is true, the loop runs. When the condition ceases to be true, the
-program calls `break`, stopping the loop. This loop type could be implemented
-using a combination of `loop`, `if`, `else`, and `break`; you could try that
-now in a program, if you’d like.
-
-However, this pattern is so common that Rust has a built-in language construct
-for it, called a `while` loop. Listing 3-3 uses `while`: the program loops
-three times, counting down each time, and then, after the loop, it prints
-another message and exits.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let mut number = 3;
-
-    while number != 0 {
-        println!("{}!", number);
-
-        number = number - 1;
-    }
-
-    println!("LIFTOFF!!!");
-}
-```
-
-Listing 3-3: Using a `while` loop to run code while a condition holds true
-
-This construct eliminates a lot of nesting that would be necessary if you used
-`loop`, `if`, `else`, and `break`, and it’s clearer. While a condition holds
-true, the code runs; otherwise, it exits the loop.
-
-#### Looping Through a Collection with `for`
-
-You could use the `while` construct to loop over the elements of a collection,
-such as an array. For example, let’s look at Listing 3-4:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let a = [10, 20, 30, 40, 50];
-    let mut index = 0;
-
-    while index < 5 {
-        println!("the value is: {}", a[index]);
-
-        index = index + 1;
-    }
-}
-```
-
-Listing 3-4: Looping through each element of a collection using a `while` loop
-
-Here, the code counts up through the elements in the array. It starts at index
-`0`, and then loops until it reaches the final index in the array (that is,
-when `index < 5` is no longer true). Running this code will print every element
-in the array:
-
-```
-$ cargo run
-   Compiling loops v0.1.0 (file:///projects/loops)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.32 secs
-     Running `target/debug/loops`
-the value is: 10
-the value is: 20
-the value is: 30
-the value is: 40
-the value is: 50
-```
-
-All five array values appear in the terminal, as expected. Even though `index`
-will reach a value of `5` at some point, the loop stops executing before trying
-to fetch a sixth value from the array.
-
-But this approach is error prone; we could cause the program to panic if the
-index length is incorrect. It’s also slow, because the compiler adds runtime
-code to perform the conditional check on every element on every iteration
-through the loop.
-
-As a more concise alternative, you can use a `for` loop and execute some code
-for each item in a collection. A `for` loop looks like this code in Listing 3-5:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let a = [10, 20, 30, 40, 50];
-
-    for element in a.iter() {
-        println!("the value is: {}", element);
-    }
-}
-```
-
-Listing 3-5: Looping through each element of a collection using a `for` loop
-
-When we run this code, we’ll see the same output as in Listing 3-4. More
-importantly, we’ve now increased the safety of the code and eliminated the
-chance of bugs that might result from going beyond the end of the array or not
-going far enough and missing some items.
-
-For example, in the code in Listing 3-4, if you removed an item from the `a`
-array but forgot to update the condition to `while index < 4`, the code would
-panic. Using the `for` loop, you wouldn’t need to remember to change any other
-code if you changed the number of values in the array.
-
-The safety and conciseness of `for` loops make them the most commonly used loop
-construct in Rust. Even in situations in which you want to run some code a
-certain number of times, as in the countdown example that used a `while` loop
-in Listing 3-3, most Rustaceans would use a `for` loop. The way to do that
-would be to use a `Range`, which is a type provided by the standard library
-that generates all numbers in sequence starting from one number and ending
-before another number.
-
-Here’s what the countdown would look like using a `for` loop and another method
-we’ve not yet talked about, `rev`, to reverse the range:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    for number in (1..4).rev() {
-        println!("{}!", number);
-    }
-    println!("LIFTOFF!!!");
-}
-```
-
-This code is a bit nicer, isn’t it?
-
-## Summary
-
-You made it! That was a sizable chapter: you learned about variables, scalar
-and compound data types, functions, comments, `if` expressions, and loops! If
-you want to practice with the concepts discussed in this chapter, try building
-programs to do the following:
-
-* Convert temperatures between Fahrenheit and Celsius.
-* Generate the nth Fibonacci number.
-* Print the lyrics to the Christmas carol “The Twelve Days of Christmas,”
-taking advantage of the repetition in the song.
-
-When you’re ready to move on, we’ll talk about a concept in Rust that *doesn’t*
-commonly exist in other programming languages: ownership.
diff --git a/src/doc/book/second-edition/nostarch/chapter04.md b/src/doc/book/second-edition/nostarch/chapter04.md
deleted file mode 100644
index e70dc21555..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter04.md
+++ /dev/null
@@ -1,1244 +0,0 @@
-
-[TOC]
-
-# Understanding Ownership
-
-Ownership is Rust’s most unique feature, and it enables Rust to make memory
-safety guarantees without needing a garbage collector. Therefore, it’s
-important to understand how ownership works in Rust. In this chapter, we’ll
-talk about ownership as well as several related features: borrowing, slices,
-and how Rust lays data out in memory.
-
-## What Is Ownership?
-
-Rust’s central feature is *ownership*. Although the feature is straightforward
-to explain, it has deep implications for the rest of the language.
-
-All programs have to manage the way they use a computer’s memory while running.
-Some languages have garbage collection that constantly looks for no longer used
-memory as the program runs; in other languages, the programmer must explicitly
-allocate and free the memory. Rust uses a third approach: memory is managed
-through a system of ownership with a set of rules that the compiler checks at
-compile time. None of the ownership features slow down your program while it’s
-running.
-
-Because ownership is a new concept for many programmers, it does take some time
-to get used to. The good news is that the more experienced you become with Rust
-and the rules of the ownership system, the more you’ll be able to naturally
-develop code that is safe and efficient. Keep at it!
-
-When you understand ownership, you’ll have a solid foundation for understanding
-the features that make Rust unique. In this chapter, you’ll learn ownership by
-working through some examples that focus on a very common data structure:
-strings.
-
-
-
-### The Stack and the Heap
-
-In many programming languages, you don’t have to think about the stack and
-the heap very often. But in a systems programming language like Rust, whether
-a value is on the stack or the heap has more of an effect on how the language
-behaves and why you have to make certain decisions. Parts of ownership will
-be described in relation to the stack and the heap later in this chapter, so
-here is a brief explanation in preparation.
-
-Both the stack and the heap are parts of memory that is available to your code
-to use at runtime, but they are structured in different ways. The stack stores
-values in the order it gets them and removes the values in the opposite order.
-This is referred to as *last in, first out*. Think of a stack of plates: when
-you add more plates, you put them on top of the pile, and when you need a
-plate, you take one off the top. Adding or removing plates from the middle or
-bottom wouldn’t work as well! Adding data is called *pushing onto the stack*,
-and removing data is called *popping off the stack*.
-
-The stack is fast because of the way it accesses the data: it never has to
-search for a place to put new data or a place to get data from because that
-place is always the top. Another property that makes the stack fast is that
-all data on the stack must take up a known, fixed size.
-
-Data with a size unknown at compile time or a size that might change can be
-stored on the heap instead. The heap is less organized: when you put data on
-the heap, you ask for some amount of space. The operating system finds an
-empty spot somewhere in the heap that is big enough, marks it as being in
-use, and returns a *pointer*, which is the address of that location. This
-process is called *allocating on the heap*, sometimes abbreviated as just
-“allocating.” Pushing values onto the stack is not considered allocating.
-Because the pointer is a known, fixed size, you can store the pointer on the
-stack, but when you want the actual data, you have to follow the pointer.
-
-Think of being seated at a restaurant. When you enter, you state the number of
-people in your group, and the staff finds an empty table that fits everyone
-and leads you there. If someone in your group comes late, they can ask where
-you’ve been seated to find you.
-
-Accessing data in the heap is slower than accessing data on the stack because
-you have to follow a pointer to get there. Contemporary processors are faster
-if they jump around less in memory. Continuing the analogy, consider a server
-at a restaurant taking orders from many tables. It’s most efficient to get
-all the orders at one table before moving on to the next table. Taking an
-order from table A, then an order from table B, then one from A again, and
-then one from B again would be a much slower process. By the same token, a
-processor can do its job better if it works on data that’s close to other
-data (as it is on the stack) rather than farther away (as it can be on the
-heap). Allocating a large amount of space on the heap can also take time.
-
-When your code calls a function, the values passed into the function
-(including, potentially, pointers to data on the heap) and the function’s
-local variables get pushed onto the stack. When the function is over, those
-values get popped off the stack.
-
-Keeping track of what parts of code are using what data on the heap,
-minimizing the amount of duplicate data on the heap, and cleaning up unused
-data on the heap so you don’t run out of space are all problems that ownership
-addresses. Once you understand ownership, you won’t need to think about the
-stack and the heap very often, but knowing that managing heap data is why
-ownership exists can help explain why it works the way it does.
-
-
-
-### Ownership Rules
-
-First, let’s take a look at the ownership rules. Keep these rules in mind as we
-work through the examples that illustrate them:
-
-> 1. Each value in Rust has a variable that’s called its *owner*.
-> 2. There can only be one owner at a time.
-> 3. When the owner goes out of scope, the value will be dropped.
-
-### Variable Scope
-
-We’ve walked through an example of a Rust program already in Chapter 2. Now
-that we’re past basic syntax, we won’t include all the `fn main() {` code in
-examples, so if you’re following along, you’ll have to put the following
-examples inside a `main` function manually. As a result, our examples will be a
-bit more concise, letting us focus on the actual details rather than
-boilerplate code.
-
-As a first example of ownership, we’ll look at the *scope* of some variables. A
-scope is the range within a program for which an item is valid. Let’s say we
-have a variable that looks like this:
-
-```
-let s = "hello";
-```
-
-The variable `s` refers to a string literal, where the value of the string is
-hardcoded into the text of our program. The variable is valid from the point at
-which it’s declared until the end of the current *scope*. Listing 4-1 has
-comments annotating where the variable `s` is valid:
-
-```
-{                      // s is not valid here, it’s not yet declared
-    let s = "hello";   // s is valid from this point forward
-
-    // do stuff with s
-}                      // this scope is now over, and s is no longer valid
-```
-
-Listing 4-1: A variable and the scope in which it is valid
-
-In other words, there are two important points in time here:
-
-* When `s` comes *into scope*, it is valid.
-* It remains valid until it goes *out of scope*.
-
-At this point, the relationship between scopes and when variables are valid is
-similar to that in other programming languages. Now we’ll build on top of this
-understanding by introducing the `String` type.
-
-### The `String` Type
-
-To illustrate the rules of ownership, we need a data type that is more complex
-than the ones we covered in the “Data Types” section of Chapter 3. The types
-covered previously are all stored on the stack and popped off the stack when
-their scope is over, but we want to look at data that is stored on the heap and
-explore how Rust knows when to clean up that data.
-
-We’ll use `String` as the example here and concentrate on the parts of `String`
-that relate to ownership. These aspects also apply to other complex data types
-provided by the standard library and that you create. We’ll discuss `String` in
-more depth in Chapter 8.
-
-We’ve already seen string literals, where a string value is hardcoded into our
-program. String literals are convenient, but they aren’t suitable for every
-situation in which we may want to use text. One reason is that they’re
-immutable. Another is that not every string value can be known when we write
-our code: for example, what if we want to take user input and store it? For
-these situations, Rust has a second string type, `String`. This type is
-allocated on the heap and as such is able to store an amount of text that is
-unknown to us at compile time. You can create a `String` from a string literal
-using the `from` function, like so:
-
-```
-let s = String::from("hello");
-```
-
-The double colon (`::`) is an operator that allows us to namespace this
-particular `from` function under the `String` type rather than using some sort
-of name like `string_from`. We’ll discuss this syntax more in the “Method
-Syntax” section of Chapter 5 and when we talk about namespacing with modules in
-“Module Definitions” in Chapter 7.
-
-This kind of string *can* be mutated:
-
-```
-let mut s = String::from("hello");
-
-s.push_str(", world!"); // push_str() appends a literal to a String
-
-println!("{}", s); // This will print `hello, world!`
-```
-
-So, what’s the difference here? Why can `String` be mutated but literals
-cannot? The difference is how these two types deal with memory.
-
-### Memory and Allocation
-
-In the case of a string literal, we know the contents at compile time, so the
-text is hardcoded directly into the final executable. This is why string
-literals are fast and efficient. But these properties only come from the string
-literal’s immutability. Unfortunately, we can’t put a blob of memory into the
-binary for each piece of text whose size is unknown at compile time and whose
-size might change while running the program.
-
-With the `String` type, in order to support a mutable, growable piece of text,
-we need to allocate an amount of memory on the heap, unknown at compile time,
-to hold the contents. This means:
-
-* The memory must be requested from the operating system at runtime.
-* We need a way of returning this memory to the operating system when we’re
-  done with our `String`.
-
-That first part is done by us: when we call `String::from`, its implementation
-requests the memory it needs. This is pretty much universal in programming
-languages.
-
-However, the second part is different. In languages with a *garbage collector
-(GC)*, the GC keeps track and cleans up memory that isn’t being used anymore,
-and we don’t need to think about it. Without a GC, it’s our responsibility to
-identify when memory is no longer being used and call code to explicitly return
-it, just as we did to request it. Doing this correctly has historically been a
-difficult programming problem. If we forget, we’ll waste memory. If we do it
-too early, we’ll have an invalid variable. If we do it twice, that’s a bug too.
-We need to pair exactly one `allocate` with exactly one `free`.
-
-Rust takes a different path: the memory is automatically returned once the
-variable that owns it goes out of scope. Here’s a version of our scope example
-from Listing 4-1 using a `String` instead of a string literal:
-
-```
-{
-    let s = String::from("hello"); // s is valid from this point forward
-
-    // do stuff with s
-}                                  // this scope is now over, and s is no
-                                   // longer valid
-```
-
-There is a natural point at which we can return the memory our `String` needs
-to the operating system: when `s` goes out of scope. When a variable goes out
-of scope, Rust calls a special function for us. This function is called `drop`,
-and it’s where the author of `String` can put the code to return the memory.
-Rust calls `drop` automatically at the closing `}`.
-
-> Note: In C++, this pattern of deallocating resources at the end of an item’s
-> lifetime is sometimes called *Resource Acquisition Is Initialization (RAII)*.
-> The `drop` function in Rust will be familiar to you if you’ve used RAII
-> patterns.
-
-This pattern has a profound impact on the way Rust code is written. It may seem
-simple right now, but the behavior of code can be unexpected in more
-complicated situations when we want to have multiple variables use the data
-we’ve allocated on the heap. Let’s explore some of those situations now.
-
-#### Ways Variables and Data Interact: Move
-
-Multiple variables can interact with the same data in different ways in Rust.
-Let’s look at an example using an integer in Listing 4-2:
-
-```
-let x = 5;
-let y = x;
-```
-
-Listing 4-2: Assigning the integer value of variable `x` to `y`
-
-We can probably guess what this is doing: “bind the value `5` to `x`; then make
-a copy of the value in `x` and bind it to `y`.” We now have two variables, `x`
-and `y`, and both equal `5`. This is indeed what is happening, because integers
-are simple values with a known, fixed size, and these two `5` values are pushed
-onto the stack.
-
-Now let’s look at the `String` version:
-
-```
-let s1 = String::from("hello");
-let s2 = s1;
-```
-
-This looks very similar to the previous code, so we might assume that the way
-it works would be the same: that is, the second line would make a copy of the
-value in `s1` and bind it to `s2`. But this isn’t quite what happens.
-
-Take a look at Figure 4-1 to see what is happening to `String` under the
-covers. A `String` is made up of three parts, shown on the left: a pointer to
-the memory that holds the contents of the string, a length, and a capacity.
-This group of data is stored on the stack. On the right is the memory on the
-heap that holds the contents.
-
-String in memory
-
-Figure 4-1: Representation in memory of a `String` holding the value `"hello"`
-bound to `s1`
-
-The length is how much memory, in bytes, the contents of the `String` is
-currently using. The capacity is the total amount of memory, in bytes, that the
-`String` has received from the operating system. The difference between length
-and capacity matters, but not in this context, so for now, it’s fine to ignore
-the capacity.
-
-When we assign `s1` to `s2`, the `String` data is copied, meaning we copy the
-pointer, the length, and the capacity that are on the stack. We do not copy the
-data on the heap that the pointer refers to. In other words, the data
-representation in memory looks like Figure 4-2.
-
-s1 and s2 pointing to the same value
-
-Figure 4-2: Representation in memory of the variable `s2` that has a copy of
-the pointer, length, and capacity of `s1`
-
-The representation does *not* look like Figure 4-3, which is what memory would
-look like if Rust instead copied the heap data as well. If Rust did this, the
-operation `s2 = s1` could be very expensive in terms of runtime performance if
-the data on the heap were large.
-
-s1 and s2 to two places
-
-Figure 4-3: Another possibility for what `s2 = s1` might do if Rust copied the
-heap data as well
-
-Earlier, we said that when a variable goes out of scope, Rust automatically
-calls the `drop` function and cleans up the heap memory for that variable. But
-Figure 4-2 shows both data pointers pointing to the same location. This is a
-problem: when `s2` and `s1` go out of scope, they will both try to free the
-same memory. This is known as a *double free* error and is one of the memory
-safety bugs we mentioned previously. Freeing memory twice can lead to memory
-corruption, which can potentially lead to security vulnerabilities.
-
-To ensure memory safety, there’s one more detail to what happens in this
-situation in Rust. Instead of trying to copy the allocated memory, Rust
-considers `s1` to no longer be valid and, therefore, Rust doesn’t need to free
-anything when `s1` goes out of scope. Check out what happens when you try to
-use `s1` after `s2` is created; it won’t work:
-
-```
-let s1 = String::from("hello");
-let s2 = s1;
-
-println!("{}, world!", s1);
-```
-
-You’ll get an error like this because Rust prevents you from using the
-invalidated reference:
-
-```
-error[E0382]: use of moved value: `s1`
- --> src/main.rs:5:28
-  |
-3 |     let s2 = s1;
-  |         -- value moved here
-4 |
-5 |     println!("{}, world!", s1);
-  |                            ^^ value used here after move
-  |
-  = note: move occurs because `s1` has type `std::string::String`, which does
-  not implement the `Copy` trait
-```
-
-If you’ve heard the terms *shallow copy* and *deep copy* while working with
-other languages, the concept of copying the pointer, length, and capacity
-without copying the data probably sounds like making a shallow copy. But
-because Rust also invalidates the first variable, instead of being called a
-shallow copy, it’s known as a *move*. Here we would read this by saying that
-`s1` was *moved* into `s2`. So what actually happens is shown in Figure 4-4.
-
-s1 moved to s2
-
-Figure 4-4: Representation in memory after `s1` has been invalidated
-
-That solves our problem! With only `s2` valid, when it goes out of scope, it
-alone will free the memory, and we’re done.
-
-In addition, there’s a design choice that’s implied by this: Rust will never
-automatically create “deep” copies of your data. Therefore, any *automatic*
-copying can be assumed to be inexpensive in terms of runtime performance.
-
-#### Ways Variables and Data Interact: Clone
-
-If we *do* want to deeply copy the heap data of the `String`, not just the
-stack data, we can use a common method called `clone`. We’ll discuss method
-syntax in Chapter 5, but because methods are a common feature in many
-programming languages, you’ve probably seen them before.
-
-Here’s an example of the `clone` method in action:
-
-```
-let s1 = String::from("hello");
-let s2 = s1.clone();
-
-println!("s1 = {}, s2 = {}", s1, s2);
-```
-
-This works just fine and explicitly produces the behavior shown in Figure 4-3,
-where the heap data *does* get copied.
-
-When you see a call to `clone`, you know that some arbitrary code is being
-executed and that code may be expensive. It’s a visual indicator that something
-different is going on.
-
-#### Stack-Only Data: Copy
-
-There’s another wrinkle we haven’t talked about yet. This code using integers,
-part of which was shown earlier in Listing 4-2, works and is valid:
-
-```
-let x = 5;
-let y = x;
-
-println!("x = {}, y = {}", x, y);
-```
-
-But this code seems to contradict what we just learned: we don’t have a call to
-`clone`, but `x` is still valid and wasn’t moved into `y`.
-
-The reason is that types such as integers that have a known size at compile
-time are stored entirely on the stack, so copies of the actual values are quick
-to make. That means there’s no reason we would want to prevent `x` from being
-valid after we create the variable `y`. In other words, there’s no difference
-between deep and shallow copying here, so calling `clone` wouldn’t do anything
-different from the usual shallow copying and we can leave it out.
-
-Rust has a special annotation called the `Copy` trait that we can place on
-types like integers that are stored on the stack (we’ll talk more about traits
-in Chapter 10). If a type has the `Copy` trait, an older variable is still
-usable after assignment. Rust won’t let us annotate a type with the `Copy`
-trait if the type, or any of its parts, has implemented the `Drop` trait. If
-the type needs something special to happen when the value goes out of scope and
-we add the `Copy` annotation to that type, we’ll get a compile time error. To
-learn about how to add the `Copy` annotation to your type, see “Derivable
-Traits” in Appendix C.
-
-So what types are `Copy`? You can check the documentation for the given type to
-be sure, but as a general rule, any group of simple scalar values can be
-`Copy`, and nothing that requires allocation or is some form of resource is
-`Copy`. Here are some of the types that are `Copy`:
-
-* All the integer types, such as `u32`.
-* The Boolean type, `bool`, with values `true` and `false`.
-* All the floating point types, such as `f64`.
-* The character type, `char`.
-* Tuples, but only if they contain types that are also `Copy`. For example,
-  `(i32, i32)` is `Copy`, but `(i32, String)` is not.
-
-### Ownership and Functions
-
-The semantics for passing a value to a function are similar to those for
-assigning a value to a variable. Passing a variable to a function will move or
-copy, just as assignment does. Listing 4-3 has an example with some annotations
-showing where variables go into and out of scope:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let s = String::from("hello");  // s comes into scope
-
-    takes_ownership(s);             // s's value moves into the function...
-                                    // ... and so is no longer valid here
-
-    let x = 5;                      // x comes into scope
-
-    makes_copy(x);                  // x would move into the function,
-                                    // but i32 is Copy, so it’s okay to still
-                                    // use x afterward
-
-} // Here, x goes out of scope, then s. But because s's value was moved, nothing
-  // special happens.
-
-fn takes_ownership(some_string: String) { // some_string comes into scope
-    println!("{}", some_string);
-} // Here, some_string goes out of scope and `drop` is called. The backing
-  // memory is freed.
-
-fn makes_copy(some_integer: i32) { // some_integer comes into scope
-    println!("{}", some_integer);
-} // Here, some_integer goes out of scope. Nothing special happens.
-```
-
-Listing 4-3: Functions with ownership and scope annotated
-
-If we tried to use `s` after the call to `takes_ownership`, Rust would throw a
-compile time error. These static checks protect us from mistakes. Try adding
-code to `main` that uses `s` and `x` to see where you can use them and where
-the ownership rules prevent you from doing so.
-
-### Return Values and Scope
-
-Returning values can also transfer ownership. Listing 4-4 is an example with
-similar annotations to those in Listing 4-3:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let s1 = gives_ownership();         // gives_ownership moves its return
-                                        // value into s1
-
-    let s2 = String::from("hello");     // s2 comes into scope
-
-    let s3 = takes_and_gives_back(s2);  // s2 is moved into
-                                        // takes_and_gives_back, which also
-                                        // moves its return value into s3
-} // Here, s3 goes out of scope and is dropped. s2 goes out of scope but was
-  // moved, so nothing happens. s1 goes out of scope and is dropped.
-
-fn gives_ownership() -> String {             // gives_ownership will move its
-                                             // return value into the function
-                                             // that calls it
-
-    let some_string = String::from("hello"); // some_string comes into scope
-
-    some_string                              // some_string is returned and
-                                             // moves out to the calling
-                                             // function.
-}
-
-// takes_and_gives_back will take a String and return one.
-fn takes_and_gives_back(a_string: String) -> String { // a_string comes into
-                                                      // scope
-
-    a_string  // a_string is returned and moves out to the calling function
-}
-```
-
-Listing 4-4: Transferring ownership of return values
-
-The ownership of a variable follows the same pattern every time: assigning a
-value to another variable moves it. When a variable that includes data on the
-heap goes out of scope, the value will be cleaned up by `drop` unless the data
-has been moved to be owned by another variable.
-
-Taking ownership and then returning ownership with every function is a bit
-tedious. What if we want to let a function use a value but not take ownership?
-It’s quite annoying that anything we pass in also needs to be passed back if we
-want to use it again, in addition to any data resulting from the body of the
-function that we might want to return as well.
-
-It’s possible to return multiple values using a tuple, as shown in Listing 4-5:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let s1 = String::from("hello");
-
-    let (s2, len) = calculate_length(s1);
-
-    println!("The length of '{}' is {}.", s2, len);
-}
-
-fn calculate_length(s: String) -> (String, usize) {
-    let length = s.len(); // len() returns the length of a String
-
-    (s, length)
-}
-```
-
-Listing 4-5: Returning ownership of parameters
-
-But this is too much ceremony and a lot of work for a concept that should be
-common. Luckily for us, Rust has a feature for this concept, called
-*references*.
-
-## References and Borrowing
-
-The issue with the tuple code in 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`.
-
-Here is how you would define and use a `calculate_length` function that has a
-reference to an object as a parameter instead of taking ownership of the
-value:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let s1 = String::from("hello");
-
-    let len = calculate_length(&s1);
-
-    println!("The length of '{}' is {}.", s1, len);
-}
-
-fn calculate_length(s: &String) -> usize {
-    s.len()
-}
-```
-
-First, notice that all the tuple code in the variable declaration and the
-function return value is gone. Second, note that we pass `&s1` into
-`calculate_length` and, in its definition, we take `&String` rather than
-`String`.
-
-These ampersands are *references*, and they allow you to refer to some value
-without taking ownership of it. Figure 4-5 shows a diagram.
-
-&String s pointing at String s1
-
-Figure 4-5: A diagram of `&String s` pointing at `String s1`
-
-> Note: The opposite of referencing by using `&` is *dereferencing*, which is
-> accomplished with the dereference operator, `*`. We’ll see some uses of the
-> dereference operator in Chapter 8 and discuss details of dereferencing in
-> Chapter 15.
-
-Let’s take a closer look at the function call here:
-
-```
-let s1 = String::from("hello");
-
-let len = calculate_length(&s1);
-```
-
-The `&s1` syntax lets us create a reference that *refers* to the value of `s1`
-but does not own it. Because it does not own it, the value it points to will
-not be dropped when the reference goes out of scope.
-
-Likewise, the signature of the function uses `&` to indicate that the type of
-the parameter `s` is a reference. Let’s add some explanatory annotations:
-
-```
-fn calculate_length(s: &String) -> usize { // s is a reference to a String
-    s.len()
-} // Here, s goes out of scope. But because it does not have ownership of what
-  // it refers to, nothing happens.
-```
-
-The scope in which the variable `s` is valid is the same as any function
-parameter’s scope, but we don’t drop what the reference points to when it goes
-out of scope because we don’t have ownership. When functions have references as
-parameters instead of the actual values, we won’t need to return the values in
-order to give back ownership, because we never had ownership.
-
-We call having references as function parameters *borrowing*. As in real life,
-if a person owns something, you can borrow it from them. When you’re done, you
-have to give it back.
-
-So what happens if we try to modify something we’re borrowing? Try the code in
-Listing 4-6. Spoiler alert: it doesn’t work!
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let s = String::from("hello");
-
-    change(&s);
-}
-
-fn change(some_string: &String) {
-    some_string.push_str(", world");
-}
-```
-
-Listing 4-6: Attempting to modify a borrowed value
-
-Here’s the error:
-
-```
-error[E0596]: cannot borrow immutable borrowed content `*some_string` as mutable
- --> error.rs:8:5
-  |
-7 | fn change(some_string: &String) {
-  |                        ------- use `&mut String` here to make mutable
-8 |     some_string.push_str(", world");
-  |     ^^^^^^^^^^^ cannot borrow as mutable
-```
-
-Just as variables are immutable by default, so are references. We’re not
-allowed to modify something we have a reference to.
-
-### Mutable References
-
-We can fix the error in the code from Listing 4-6 with just a small tweak:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let mut s = String::from("hello");
-
-    change(&mut s);
-}
-
-fn change(some_string: &mut String) {
-    some_string.push_str(", world");
-}
-```
-
-First, we had to change `s` to be `mut`. Then we had to create a mutable
-reference with `&mut s` and accept a mutable reference with `some_string: &mut
-String`.
-
-But mutable references have one big restriction: you can only have one mutable
-reference to a particular piece of data in a particular scope. This code will
-fail:
-
-Filename: src/main.rs
-
-```
-let mut s = String::from("hello");
-
-let r1 = &mut s;
-let r2 = &mut s;
-```
-
-Here’s the error:
-
-```
-error[E0499]: cannot borrow `s` as mutable more than once at a time
- --> borrow_twice.rs:5:19
-  |
-4 |     let r1 = &mut s;
-  |                   - first mutable borrow occurs here
-5 |     let r2 = &mut s;
-  |                   ^ second mutable borrow occurs here
-6 | }
-  | - first borrow ends here
-```
-
-This restriction allows for mutation but in a very controlled fashion. It’s
-something that new Rustaceans struggle with, because most languages let you
-mutate whenever you’d like.
-
-The benefit of having this restriction is that Rust can prevent data races at
-compile time. A *data race* is similar to a race condition and happens when
-these three behaviors occur:
-
-* Two or more pointers access the same data at the same time.
-* At least one of the pointers is being used to write to the data.
-* There’s no mechanism being used to synchronize access to the data.
-
-Data races cause undefined behavior and can be difficult to diagnose and fix
-when you’re trying to track them down at runtime; Rust prevents this problem
-from happening because it won’t even compile code with data races!
-
-As always, we can use curly brackets to create a new scope, allowing for
-multiple mutable references, just not *simultaneous* ones:
-
-```
-let mut s = String::from("hello");
-
-{
-    let r1 = &mut s;
-
-} // r1 goes out of scope here, so we can make a new reference with no problems.
-
-let r2 = &mut s;
-```
-
-A similar rule exists for combining mutable and immutable references. This code
-results in an error:
-
-```
-let mut s = String::from("hello");
-
-let r1 = &s; // no problem
-let r2 = &s; // no problem
-let r3 = &mut s; // BIG PROBLEM
-```
-
-Here’s the error:
-
-```
-error[E0502]: cannot borrow `s` as mutable because it is also borrowed as
-immutable
- --> borrow_thrice.rs:6:19
-  |
-4 |     let r1 = &s; // no problem
-  |               - immutable borrow occurs here
-5 |     let r2 = &s; // no problem
-6 |     let r3 = &mut s; // BIG PROBLEM
-  |                   ^ mutable borrow occurs here
-7 | }
-  | - immutable borrow ends here
-```
-
-Whew! We *also* cannot have a mutable reference while we have an immutable one.
-Users of an immutable reference don’t expect the values to suddenly change out
-from under them! However, multiple immutable references are okay because no one
-who is just reading the data has the ability to affect anyone else’s reading of
-the data.
-
-Even though these errors may be frustrating at times, remember that it’s the
-Rust compiler pointing out a potential bug early (at compile time rather than
-at runtime) and showing you exactly where the problem is. Then you don’t have
-to track down why your data isn’t what you thought it was.
-
-### Dangling References
-
-In languages with pointers, it’s easy to erroneously create a *dangling
-pointer*, a pointer that references a location in memory that may have been
-given to someone else, by freeing some memory while preserving a pointer to
-that memory. In Rust, by contrast, the compiler guarantees that references will
-never be dangling references: if you have a reference to some data, the
-compiler will ensure that the data will not go out of scope before the
-reference to the data does.
-
-Let’s try to create a dangling reference, which Rust will prevent with a
-compile-time error:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let reference_to_nothing = dangle();
-}
-
-fn dangle() -> &String {
-    let s = String::from("hello");
-
-    &s
-}
-```
-
-Here’s the error:
-
-```
-error[E0106]: missing lifetime specifier
- --> dangle.rs:5:16
-  |
-5 | fn dangle() -> &String {
-  |                ^ expected lifetime parameter
-  |
-  = help: this function's return type contains a borrowed value, but there is
-  no value for it to be borrowed from
-  = help: consider giving it a 'static lifetime
-```
-
-This error message refers to a feature we haven’t covered yet: *lifetimes*.
-We’ll discuss lifetimes in detail in Chapter 10. But, if you disregard the
-parts about lifetimes, the message does contain the key to why this code is a
-problem:
-
-```
-this function's return type contains a borrowed value, but there is no value
-for it to be borrowed from.
-```
-
-Let’s take a closer look at exactly what’s happening at each stage of our
-`dangle` code:
-
-```
-fn dangle() -> &String { // dangle returns a reference to a String
-
-    let s = String::from("hello"); // s is a new String
-
-    &s // we return a reference to the String, s
-} // Here, s goes out of scope, and is dropped. Its memory goes away.
-  // Danger!
-```
-
-Because `s` is created inside `dangle`, when the code of `dangle` is finished,
-`s` will be deallocated. But we tried to return a reference to it. That means
-this reference would be pointing to an invalid `String` That’s no good! Rust
-won’t let us do this.
-
-The solution here is to return the `String` directly:
-
-```
-fn no_dangle() -> String {
-    let s = String::from("hello");
-
-    s
-}
-```
-
-This works without any problems. Ownership is moved out, and nothing is
-deallocated.
-
-### The Rules of References
-
-Let’s recap what we’ve discussed about references:
-
-* At any given time, you can have *either* (but not both of) one mutable
-  reference or any number of immutable references.
-* References must always be valid.
-
-Next, we’ll look at a different kind of reference: slices.
-
-## The Slice Type
-
-Another data type that does not have ownership is the *slice*. Slices let you
-reference a contiguous sequence of elements in a collection rather than the
-whole collection.
-
-Here’s a small programming problem: write a function that takes a string and
-returns the first word it finds in that string. If the function doesn’t find a
-space in the string, the whole string must be one word, so the entire string
-should be returned.
-
-Let’s think about the signature of this function:
-
-```
-fn first_word(s: &String) -> ?
-```
-
-This function, `first_word`, has a `&String` as a parameter. We don’t want
-ownership, so this is fine. But what should we return? We don’t really have a
-way to talk about *part* of a string. However, we could return the index of the
-end of the word. Let’s try that, as shown in Listing 4-7:
-
-Filename: src/main.rs
-
-```
-fn first_word(s: &String) -> usize {
-    let bytes = s.as_bytes();
-
-    for (i, &item) in bytes.iter().enumerate() {
-        if item == b' ' {
-            return i;
-        }
-    }
-
-    s.len()
-}
-```
-
-Listing 4-7: The `first_word` function that returns a byte index value into the
-`String` parameter
-
-Because we need to go through the `String` element by element and check whether
-a value is a space, we’ll convert our `String` to an array of bytes using the
-`as_bytes` method:
-
-```
-let bytes = s.as_bytes();
-```
-
-Next, we create an iterator over the array of bytes using the `iter` method:
-
-```
-for (i, &item) in bytes.iter().enumerate() {
-```
-
-We’ll discuss iterators in more detail in Chapter 13. For now, know that `iter`
-is a method that returns each element in a collection and that `enumerate`
-wraps the result of `iter` and returns each element as part of a tuple instead.
-The first element of the tuple returned from `enumerate` is the index, and the
-second element is a reference to the element. This is a bit more convenient
-than calculating the index ourselves.
-
-Because the `enumerate` method returns a tuple, we can use patterns to
-destructure that tuple, just like everywhere else in Rust. So in the `for`
-loop, we specify a pattern that has `i` for the index in the tuple and `&item`
-for the single byte in the tuple. Because we get a reference to the element
-from `.iter().enumerate()`, we use `&` in the pattern.
-
-Inside the `for` loop, we search for the byte that represents the space by
-using the byte literal syntax. If we find a space, we return the position.
-Otherwise, we return the length of the string by using `s.len()`:
-
-```
-    if item == b' ' {
-        return i;
-    }
-}
-s.len()
-```
-
-We now have a way to find out the index of the end of the first word in the
-string, but there’s a problem. We’re returning a `usize` on its own, but it’s
-only a meaningful number in the context of the `&String`. In other words,
-because it’s a separate value from the `String`, there’s no guarantee that it
-will still be valid in the future. Consider the program in Listing 4-8 that
-uses the `first_word` function from Listing 4-7:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let mut s = String::from("hello world");
-
-    let word = first_word(&s); // word will get the value 5
-
-    s.clear(); // This empties the String, making it equal to ""
-
-    // word still has the value 5 here, but there's no more string that
-    // we could meaningfully use the value 5 with. word is now totally invalid!
-}
-```
-
-Listing 4-8: Storing the result from calling the `first_word` function and then
-changing the `String` contents
-
-This program compiles without any errors and would also do so if we used `word`
-after calling `s.clear()`. Because `word` isn’t connected to the state of `s`
-at all, `word` still contains the value `5`. We could use that value `5` with
-the variable `s` to try to extract the first word out, but this would be a bug
-because the contents of `s` have changed since we saved `5` in `word`.
-
-Having to worry about the index in `word` getting out of sync with the data in
-`s` is tedious and error prone! Managing these indices is even more brittle if
-we write a `second_word` function. Its signature would have to look like this:
-
-```
-fn second_word(s: &String) -> (usize, usize) {
-```
-
-Now we’re tracking a starting *and* an ending index, and we have even more
-values that were calculated from data in a particular state but aren’t tied to
-that state at all. We now have three unrelated variables floating around that
-need to be kept in sync.
-
-Luckily, Rust has a solution to this problem: string slices.
-
-### String Slices
-
-A *string slice* is a reference to part of a `String`, and it looks like this:
-
-```
-let s = String::from("hello world");
-
-let hello = &s[0..5];
-let world = &s[6..11];
-```
-
-This is similar to taking a reference to the whole `String` but with the extra
-`[0..5]` bit. Rather than a reference to the entire `String`, it’s a reference
-to a portion of the `String`. The `start..end` syntax is a range that begins at
-`start` and continues up to, but not including, `end`.
-
-We can create slices using a range within brackets by specifying
-`[starting_index..ending_index]`, where `starting_index` is the first position
-in the slice and `ending_index` is one more than the last position in the
-slice. Internally, the slice data structure stores the starting position and
-the length of the slice, which corresponds to `ending_index` minus
-`starting_index`. So in the case of `let world = &s[6..11];`, `world` would be
-a slice that contains a pointer to the 6th byte of `s` and a length value of 5.
-
-Figure 4-6 shows this in a diagram.
-
-world containing a pointer to the 6th byte of String s and a length 5
-
-Figure 4-6: String slice referring to part of a `String`
-
-With Rust’s `..` range syntax, if you want to start at the first index (zero),
-you can drop the value before the two periods. In other words, these are equal:
-
-```
-let s = String::from("hello");
-
-let slice = &s[0..2];
-let slice = &s[..2];
-```
-
-By the same token, if your slice includes the last byte of the `String`, you
-can drop the trailing number. That means these are equal:
-
-```
-let s = String::from("hello");
-
-let len = s.len();
-
-let slice = &s[3..len];
-let slice = &s[3..];
-```
-
-You can also drop both values to take a slice of the entire string. So these
-are equal:
-
-```
-let s = String::from("hello");
-
-let len = s.len();
-
-let slice = &s[0..len];
-let slice = &s[..];
-```
-
-> Note: String slice range indices must occur at valid UTF-8 character
-> boundaries. If you attempt to create a string slice in the middle of a
-> multibyte character, your program will exit with an error. For the purposes
-> of introducing string slices, we are assuming ASCII only in this section; a
-> more thorough discussion of UTF-8 handling is in the “Strings” section of
-> Chapter 8.
-
-With all this information in mind, let’s rewrite `first_word` to return a
-slice. The type that signifies “string slice” is written as `&str`:
-
-Filename: src/main.rs
-
-```
-fn first_word(s: &String) -> &str {
-    let bytes = s.as_bytes();
-
-    for (i, &item) in bytes.iter().enumerate() {
-        if item == b' ' {
-            return &s[0..i];
-        }
-    }
-
-    &s[..]
-}
-```
-
-We get the index for the end of the word in the same way as we did in Listing
-4-7, by looking for the first occurrence of a space. When we find a space, we
-return a string slice using the start of the string and the index of the space
-as the starting and ending indices.
-
-Now when we call `first_word`, we get back a single value that is tied to the
-underlying data. The value is made up of a reference to the starting point of
-the slice and the number of elements in the slice.
-
-Returning a slice would also work for a `second_word` function:
-
-```
-fn second_word(s: &String) -> &str {
-```
-
-We now have a straightforward API that’s much harder to mess up, because the
-compiler will ensure the references into the `String` remain valid. Remember
-the bug in the program in Listing 4-8, when we got the index to the end of the
-first word but then cleared the string so our index was invalid? That code was
-logically incorrect but didn’t show any immediate errors. The problems would
-show up later if we kept trying to use the first word index with an emptied
-string. Slices make this bug impossible and let us know we have a problem with
-our code much sooner. Using the slice version of `first_word` will throw a
-compile time error:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let mut s = String::from("hello world");
-
-    let word = first_word(&s);
-
-    s.clear(); // Error!
-}
-```
-
-Here’s the compiler error:
-
-```
-error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
- --> src/main.rs:6:5
-  |
-4 |     let word = first_word(&s);
-  |                            - immutable borrow occurs here
-5 |
-6 |     s.clear(); // Error!
-  |     ^ mutable borrow occurs here
-7 | }
-  | - immutable borrow ends here
-```
-
-Recall from the borrowing rules that if we have an immutable reference to
-something, we cannot also take a mutable reference. Because `clear` needs to
-truncate the `String`, it tries to take a mutable reference, which fails. Not
-only has Rust made our API easier to use, but it has also eliminated an entire
-class of errors at compile time!
-
-#### String Literals Are Slices
-
-Recall that we talked about string literals being stored inside the binary. Now
-that we know about slices, we can properly understand string literals:
-
-```
-let s = "Hello, world!";
-```
-
-The type of `s` here is `&str`: it’s a slice pointing to that specific point of
-the binary. This is also why string literals are immutable; `&str` is an
-immutable reference.
-
-#### String Slices as Parameters
-
-Knowing that you can take slices of literals and `String`s leads us to one more
-improvement on `first_word`, and that’s its signature:
-
-```
-fn first_word(s: &String) -> &str {
-```
-
-A more experienced Rustacean would write the following line instead because it
-allows us to use the same function on both `String`s and `&str`s:
-
-```
-fn first_word(s: &str) -> &str {
-```
-
-If we have a string slice, we can pass that directly. If we have a `String`, we
-can pass a slice of the entire `String`. Defining a function to take a string
-slice instead of a reference to a `String` makes our API more general and useful
-without losing any functionality:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let my_string = String::from("hello world");
-
-    // first_word works on slices of `String`s
-    let word = first_word(&my_string[..]);
-
-    let my_string_literal = "hello world";
-
-    // first_word works on slices of string literals
-    let word = first_word(&my_string_literal[..]);
-
-    // Because string literals *are* string slices already,
-    // this works too, without the slice syntax!
-    let word = first_word(my_string_literal);
-}
-```
-
-### Other Slices
-
-String slices, as you might imagine, are specific to strings. But there’s a
-more general slice type, too. Consider this array:
-
-```
-let a = [1, 2, 3, 4, 5];
-```
-
-Just as we might want to refer to a part of a string, we might want to refer
-to part of an array. We’d do so like this:
-
-```
-let a = [1, 2, 3, 4, 5];
-
-let slice = &a[1..3];
-```
-
-This slice has the type `&[i32]`. It works the same way as string slices do, by
-storing a reference to the first element and a length. You’ll use this kind of
-slice for all sorts of other collections. We’ll discuss these collections in
-detail when we talk about vectors in Chapter 8.
-
-## Summary
-
-The concepts of ownership, borrowing, and slices ensure memory safety in Rust
-programs at compile time. The Rust language gives you control over your memory
-usage in the same way as other systems programming languages, but having the
-owner of data automatically clean up that data when the owner goes out of scope
-means you don’t have to write and debug extra code to get this control.
-
-Ownership affects how lots of other parts of Rust work, so we’ll talk about
-these concepts further throughout the rest of the book. Let’s move on to
-Chapter 5 and look at grouping pieces of data together in a `struct`.
diff --git a/src/doc/book/second-edition/nostarch/chapter05.md b/src/doc/book/second-edition/nostarch/chapter05.md
deleted file mode 100644
index c171681355..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter05.md
+++ /dev/null
@@ -1,859 +0,0 @@
-
-[TOC]
-
-# Using Structs to Structure Related Data
-
-A *struct*, or *structure*, is a custom data type that lets you name and
-package together multiple related values that make up a meaningful group. If
-you’re familiar with an object-oriented language, a *struct* is like an
-object’s data attributes. In this chapter, we’ll compare and contrast tuples
-with structs, demonstrate how to use structs, and discuss how to define methods
-and associated functions to specify behavior associated with a struct’s data.
-Structs and enums (discussed in Chapter 6) are the building blocks for creating
-new types in your program’s domain to take full advantage of Rust’s compile
-time type checking.
-
-## Defining and Instantiating Structs
-
-Structs are similar to tuples, which were discussed in Chapter 3. Like tuples,
-the pieces of a struct can be different types. Unlike with tuples, you’ll name
-each piece of data so it’s clear what the values mean. As a result of these
-names, structs are more flexible than tuples: you don’t have to rely on the
-order of the data to specify or access the values of an instance.
-
-To define a struct, we enter the keyword `struct` and name the entire struct. A
-struct’s name should describe the significance of the pieces of data being
-grouped together. Then, inside curly brackets, we define the names and types of
-the pieces of data, which we call *fields*. For example, Listing 5-1 shows a
-struct that stores information about a user account:
-
-```
-struct User {
-    username: String,
-    email: String,
-    sign_in_count: u64,
-    active: bool,
-}
-```
-
-Listing 5-1: A `User` struct definition
-
-To use a struct after we’ve defined it, we create an *instance* of that struct
-by specifying concrete values for each of the fields. We create an instance by
-stating the name of the struct and then add curly brackets containing `key:
-value` pairs, where the keys are the names of the fields and the values are the
-data we want to store in those fields. We don’t have to specify the fields in
-the same order in which we declared them in the struct. In other words, the
-struct definition is like a general template for the type, and instances fill
-in that template with particular data to create values of the type. For
-example, we can declare a particular user as shown in Listing 5-2:
-
-```
-# struct User {
-#     username: String,
-#     email: String,
-#     sign_in_count: u64,
-#     active: bool,
-# }
-#
-let user1 = User {
-    email: String::from("someone@example.com"),
-    username: String::from("someusername123"),
-    active: true,
-    sign_in_count: 1,
-};
-```
-
-Listing 5-2: Creating an instance of the `User` struct
-
-To get a specific value from a struct, we can use dot notation. If we wanted
-just this user’s email address, we could use `user1.email` wherever we wanted
-to use this value. If the instance is mutable, we can change a value by using
-the dot notation and assigning into a particular field. Listing 5-3 shows how
-to change the value in the `email` field of a mutable `User` instance:
-
-```
-# struct User {
-#     username: String,
-#     email: String,
-#     sign_in_count: u64,
-#     active: bool,
-# }
-#
-let mut user1 = User {
-    email: String::from("someone@example.com"),
-    username: String::from("someusername123"),
-    active: true,
-    sign_in_count: 1,
-};
-
-user1.email = String::from("anotheremail@example.com");
-```
-
-Listing 5-3: Changing the value in the `email` field of a `User` instance
-
-Note that the entire instance must be mutable; Rust doesn’t allow us to mark
-only certain fields as mutable.
-
-As with any expression, we can construct a new instance of the struct as the
-last expression in the function body to implicitly return that new instance.
-Listing 5-4 shows a `build_user` function that returns a `User` instance with
-the given email and username. The `active` field gets the value of `true`, and
-the `sign_in_count` gets a value of `1`.
-
-```
-# struct User {
-#     username: String,
-#     email: String,
-#     sign_in_count: u64,
-#     active: bool,
-# }
-#
-fn build_user(email: String, username: String) -> User {
-    User {
-        email: email,
-        username: username,
-        active: true,
-        sign_in_count: 1,
-    }
-}
-```
-
-Listing 5-4: A `build_user` function that takes an email and username and
-returns a `User` instance
-
-It makes sense to name the function parameters with the same name as the struct
-fields, but having to repeat the `email` and `username` field names and
-variables is a bit tedious. If the struct had more fields, repeating each name
-would get even more annoying. Luckily, there’s a convenient shorthand!
-
-### Using the Field Init Shorthand when Variables and Fields Have the Same Name
-
-Because the parameter names and the struct field names are exactly the same in
-Listing 5-4, we can use the *field init shorthand* syntax to rewrite
-`build_user` so that it behaves exactly the same but doesn’t have the
-repetition of `email` and `username` as shown in Listing 5-5.
-
-```
-# struct User {
-#     username: String,
-#     email: String,
-#     sign_in_count: u64,
-#     active: bool,
-# }
-#
-fn build_user(email: String, username: String) -> User {
-    User {
-        email,
-        username,
-        active: true,
-        sign_in_count: 1,
-    }
-}
-```
-
-Listing 5-5: A `build_user` function that uses field init shorthand because the
-`email` and `username` parameters have the same name as struct fields
-
-Here, we’re creating a new instance of the `User` struct, which has a field
-named `email`. We want to set the `email` field’s value to the value in the
-`email` parameter of the `build_user` function. Because the `email` field and
-the `email` parameter have the same name, we only need to write `email` rather
-than `email: email`.
-
-### Creating Instances From Other Instances With Struct Update Syntax
-
-It’s often useful to create a new instance of a struct that uses most of an old
-instance’s values but changes some. You’ll do this using *struct update syntax*.
-
-First, Listing 5-6 shows how we create a new `User` instance in `user2` without
-the update syntax. We set new values for `email` and `username` but otherwise
-use the same values from `user1` that we created in Listing 5-2:
-
-```
-# struct User {
-#     username: String,
-#     email: String,
-#     sign_in_count: u64,
-#     active: bool,
-# }
-#
-# let user1 = User {
-#     email: String::from("someone@example.com"),
-#     username: String::from("someusername123"),
-#     active: true,
-#     sign_in_count: 1,
-# };
-#
-let user2 = User {
-    email: String::from("another@example.com"),
-    username: String::from("anotherusername567"),
-    active: user1.active,
-    sign_in_count: user1.sign_in_count,
-};
-```
-
-Listing 5-6: Creating a new `User` instance using some of the values from
-`user1`
-
-Using struct update syntax, we can achieve the same effect with less code, as
-shown in Listing 5-7. The syntax `..` specifies that the remaining fields not
-explicitly set should have the same value as the fields in the given instance.
-
-```
-# struct User {
-#     username: String,
-#     email: String,
-#     sign_in_count: u64,
-#     active: bool,
-# }
-#
-# let user1 = User {
-#     email: String::from("someone@example.com"),
-#     username: String::from("someusername123"),
-#     active: true,
-#     sign_in_count: 1,
-# };
-#
-let user2 = User {
-    email: String::from("another@example.com"),
-    username: String::from("anotherusername567"),
-    ..user1
-};
-```
-
-Listing 5-7: Using struct update syntax to set new `email` and `username`
-values for a `User` instance but use the rest of the values from the fields of
-the instance in the `user1` variable
-
-The code in Listing 5-7 also creates an instance in `user2` that has a
-different value for `email` and `username` but has the same values for the
-`active` and `sign_in_count` fields from `user1`.
-
-### Tuple Structs without Named Fields to Create Different Types
-
-You can also define structs that look similar to tuples, called *tuple
-structs*. Tuple structs have the added meaning the struct name provides but
-don’t have names associated with their fields; rather, they just have the types
-of the fields. Tuple structs are useful when you want to give the whole tuple a
-name and make the tuple be a different type than other tuples, and naming each
-field as in a regular struct would be verbose or redundant.
-
-To define a tuple struct start with the `struct` keyword and the struct name
-followed by the types in the tuple. For example, here are definitions and
-usages of two tuple structs named `Color` and `Point`:
-
-```
-struct Color(i32, i32, i32);
-struct Point(i32, i32, i32);
-
-let black = Color(0, 0, 0);
-let origin = Point(0, 0, 0);
-```
-
-Note that the `black` and `origin` values are different types, because they’re
-instances of different tuple structs. Each struct you define is its own type,
-even though the fields within the struct have the same types. For example, a
-function that takes a parameter of type `Color` cannot take a `Point` as an
-argument, even though both types are made up of three `i32` values. Otherwise,
-tuple struct instances behave like tuples: you can destructure them into their
-individual pieces, you can use a `.` followed by the index to access an
-individual value, and so on.
-
-### Unit-Like Structs Without Any Fields
-
-You can also define structs that don’t have any fields! These are called
-*unit-like structs* because they behave similarly to `()`, the unit type.
-Unit-like structs can be useful in situations in which you need to implement a
-trait on some type but don’t have any data that you want to store in the type
-itself. We’ll discuss traits in Chapter 10.
-
-> ### Ownership of Struct Data
->
-> In the `User` struct definition in Listing 5-1, we used the owned `String`
-> type rather than the `&str` string slice type. This is a deliberate choice
-> because we want instances of this struct to own all of its data and for that
-> data to be valid for as long as the entire struct is valid.
->
-> It’s possible for structs to store references to data owned by something else,
-> but to do so requires the use of *lifetimes*, a Rust feature that we’ll
-> discuss in Chapter 10. Lifetimes ensure that the data referenced by a struct
-> is valid for as long as the struct is. Let’s say you try to store a reference
-> in a struct without specifying lifetimes, like this, which won’t work:
->
-> Filename: src/main.rs
->
-> ```rust,ignore
-> struct User {
->     username: &str,
->     email: &str,
->     sign_in_count: u64,
->     active: bool,
-> }
->
-> fn main() {
->     let user1 = User {
->         email: "someone@example.com",
->         username: "someusername123",
->         active: true,
->         sign_in_count: 1,
->     };
-> }
-> ```
->
-> The compiler will complain that it needs lifetime specifiers:
->
-> ```text
-> errorE0106: missing lifetime specifier
->  -->
->   |
-> 2 |     username: &str,
->   |               ^ expected lifetime parameter
->
-> errorE0106: missing lifetime specifier
->  -->
->   |
-> 3 |     email: &str,
->   |            ^ expected lifetime parameter
-> ```
->
-> In Chapter 10, we’ll discuss how to fix these errors so you can store
-> references in structs, but for now, we’ll fix errors like these using owned
-> types like `String` instead of references like `&str`.
-
-## An Example Program Using Structs
-
-To understand when we might want to use structs, let’s write a program that
-calculates the area of a rectangle. We’ll start with single variables, and then
-refactor the program until we’re using structs instead.
-
-Let’s make a new binary project with Cargo called *rectangles* that will take
-the width and height of a rectangle specified in pixels and calculate the area
-of the rectangle. Listing 5-8 shows a short program with one way of doing
-exactly that in our project’s *src/main.rs*:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let width1 = 30;
-    let height1 = 50;
-
-    println!(
-        "The area of the rectangle is {} square pixels.",
-        area(width1, height1)
-    );
-}
-
-fn area(width: u32, height: u32) -> u32 {
-    width * height
-}
-```
-
-Listing 5-8: Calculating the area of a rectangle specified by separate width
-and height variables
-
-Now, run this program using `cargo run`:
-
-```
-The area of the rectangle is 1500 square pixels.
-```
-
-Even though Listing 5-8 works and figures out the area of the rectangle by
-calling the `area` function with each dimension, we can do better. The width
-and the height are related to each other because together they describe one
-rectangle.
-
-The issue with this code is evident in the signature of `area`:
-
-```
-fn area(width: u32, height: u32) -> u32 {
-```
-
-The `area` function is supposed to calculate the area of one rectangle, but the
-function we wrote has two parameters. The parameters are related, but that’s
-not expressed anywhere in our program. It would be more readable and more
-manageable to group width and height together. We’ve already discussed one way
-we might do that in “The Tuple Type” section of Chapter 3: by using tuples.
-
-### Refactoring with Tuples
-
-Listing 5-9 shows another version of our program that uses tuples:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let rect1 = (30, 50);
-
-    println!(
-        "The area of the rectangle is {} square pixels.",
-        area(rect1)
-    );
-}
-
-fn area(dimensions: (u32, u32)) -> u32 {
-    dimensions.0 * dimensions.1
-}
-```
-
-Listing 5-9: Specifying the width and height of the rectangle with a tuple
-
-In one way, this program is better. Tuples let us add a bit of structure, and
-we’re now passing just one argument. But in another way, this version is less
-clear: tuples don’t name their elements, so our calculation has become more
-confusing because we have to index into the parts of the tuple.
-
-It doesn’t matter if we mix up width and height for the area calculation, but
-if we want to draw the rectangle on the screen, it would matter! We would have
-to keep in mind that `width` is the tuple index `0` and `height` is the tuple
-index `1`. If someone else worked on this code, they would have to figure this
-out and keep it in mind as well. It would be easy to forget or mix up these
-values and cause errors, because we haven’t conveyed the meaning of our data in
-our code.
-
-### Refactoring with Structs: Adding More Meaning
-
-We use structs to add meaning by labeling the data. We can transform the tuple
-we’re using into a data type with a name for the whole as well as names for the
-parts, as shown in Listing 5-10:
-
-Filename: src/main.rs
-
-```
-struct Rectangle {
-    width: u32,
-    height: u32,
-}
-
-fn main() {
-    let rect1 = Rectangle { width: 30, height: 50 };
-
-    println!(
-        "The area of the rectangle is {} square pixels.",
-        area(&rect1)
-    );
-}
-
-fn area(rectangle: &Rectangle) -> u32 {
-    rectangle.width * rectangle.height
-}
-```
-
-Listing 5-10: Defining a `Rectangle` struct
-
-Here we’ve defined a struct and named it `Rectangle`. Inside the curly
-brackets, we defined the fields as `width` and `height`, both of which have
-type `u32`. Then in `main`, we created a particular instance of `Rectangle`
-that has a width of 30 and a height of 50.
-
-Our `area` function is now defined with one parameter, which we’ve named
-`rectangle`, whose type is an immutable borrow of a struct `Rectangle`
-instance. As mentioned in Chapter 4, we want to borrow the struct rather than
-take ownership of it. This way, `main` retains its ownership and can continue
-using `rect1`, which is the reason we use the `&` in the function signature and
-where we call the function.
-
-The `area` function accesses the `width` and `height` fields of the `Rectangle`
-instance. Our function signature for `area` now says exactly what we mean:
-calculate the area of `Rectangle`, using its `width` and `height` fields. This
-conveys that the width and height are related to each other, and it gives
-descriptive names to the values rather than using the tuple index values of `0`
-and `1`. This is a win for clarity.
-
-### Adding Useful Functionality with Derived Traits
-
-It’d be nice to be able to print an instance of `Rectangle` while we’re
-debugging our program and see the values for all its fields. Listing 5-11 tries
-using the `println!` macro as we have used in previous chapters. This won’t
-work, however:
-
-Filename: src/main.rs
-
-```
-struct Rectangle {
-    width: u32,
-    height: u32,
-}
-
-fn main() {
-    let rect1 = Rectangle { width: 30, height: 50 };
-
-    println!("rect1 is {}", rect1);
-}
-```
-
-Listing 5-11: Attempting to print a `Rectangle` instance
-
-When we run this code, we get an error with this core message:
-
-```
-error[E0277]: the trait bound `Rectangle: std::fmt::Display` is not satisfied
-```
-
-The `println!` macro can do many kinds of formatting, and by default, curly
-brackets tell `println!` to use formatting known as `Display`: output intended
-for direct end user consumption. The primitive types we’ve seen so far
-implement `Display` by default, because there’s only one way you’d want to show
-a `1` or any other primitive type to a user. But with structs, the way
-`println!` should format the output is less clear because there are more
-display possibilities: Do you want commas or not? Do you want to print the
-curly brackets? Should all the fields be shown? Due to this ambiguity, Rust
-doesn’t try to guess what we want, and structs don’t have a provided
-implementation of `Display`.
-
-If we continue reading the errors, we’ll find this helpful note:
-
-```
-`Rectangle` cannot be formatted with the default formatter; try using
-`:?` instead if you are using a format string
-```
-
-Let’s try it! The `println!` macro call will now look like `println!("rect1 is
-{:?}", rect1);`. Putting the specifier `:?` inside the curly brackets tells
-`println!` we want to use an output format called `Debug`. `Debug` is a trait
-that enables us to print our struct in a way that is useful for developers so
-we can see its value while we’re debugging our code.
-
-Run the code with this change. Drat! We still get an error:
-
-```
-error[E0277]: the trait bound `Rectangle: std::fmt::Debug` is not satisfied
-```
-
-But again, the compiler gives us a helpful note:
-
-```
-`Rectangle` cannot be formatted using `:?`; if it is defined in your
-crate, add `#[derive(Debug)]` or manually implement it
-```
-
-Rust *does* include functionality to print out debugging information, but we
-have to explicitly opt in to make that functionality available for our struct.
-To do that, we add the annotation `#[derive(Debug)]` just before the struct
-definition, as shown in Listing 5-12:
-
-Filename: src/main.rs
-
-```
-#[derive(Debug)]
-struct Rectangle {
-    width: u32,
-    height: u32,
-}
-
-fn main() {
-    let rect1 = Rectangle { width: 30, height: 50 };
-
-    println!("rect1 is {:?}", rect1);
-}
-```
-
-Listing 5-12: Adding the annotation to derive the `Debug` trait and printing
-the `Rectangle` instance using debug formatting
-
-Now when we run the program, we won’t get any errors, and we’ll see the
-following output:
-
-```
-rect1 is Rectangle { width: 30, height: 50 }
-```
-
-Nice! It’s not the prettiest output, but it shows the values of all the fields
-for this instance, which would definitely help during debugging. When we have
-larger structs, it’s useful to have output that’s a bit easier to read; in
-those cases, we can use `{:#?}` instead of `{:?}` in the `println!` string.
-When we use the `{:#?}` style in the example, the output will look like this:
-
-```
-rect1 is Rectangle {
-    width: 30,
-    height: 50
-}
-```
-
-Rust has provided a number of traits for us to use with the `derive` annotation
-that can add useful behavior to our custom types. Those traits and their
-behaviors are listed in Appendix C, “Derivable Traits.” We’ll cover how to
-implement these traits with custom behavior as well as how to create your own
-traits in Chapter 10.
-
-Our `area` function is very specific: it only computes the area of rectangles.
-It would be helpful to tie this behavior more closely to our `Rectangle`
-struct, because it won’t work with any other type. Let’s look at how we can
-continue to refactor this code by turning the `area` function into an `area`
-*method* defined on our `Rectangle` type.
-
-## Method Syntax
-
-*Methods* are similar to functions: they’re declared with the `fn` keyword and
-their name, they can have parameters and a return value, and they contain some
-code that is run when they’re called from somewhere else. However, methods are
-different from functions in that they’re defined within the context of a struct
-(or an enum or a trait object, which we cover in Chapters 6 and 17,
-respectively), and their first parameter is always `self`, which represents the
-instance of the struct the method is being called on.
-
-### Defining Methods
-
-Let’s change the `area` function that has a `Rectangle` instance as a parameter
-and instead make an `area` method defined on the `Rectangle` struct, as shown
-in Listing 5-13:
-
-Filename: src/main.rs
-
-```
-#[derive(Debug)]
-struct Rectangle {
-    width: u32,
-    height: u32,
-}
-
-impl Rectangle {
-    fn area(&self) -> u32 {
-        self.width * self.height
-    }
-}
-
-fn main() {
-    let rect1 = Rectangle { width: 30, height: 50 };
-
-    println!(
-        "The area of the rectangle is {} square pixels.",
-        rect1.area()
-    );
-}
-```
-
-Listing 5-13: Defining an `area` method on the `Rectangle` struct
-
-To define the function within the context of `Rectangle`, we start an `impl`
-(implementation) block. Then we move the `area` function within the `impl`
-curly brackets and change the first (and in this case, only) parameter to be
-`self` in the signature and everywhere within the body. In `main`, where we
-called the `area` function and passed `rect1` as an argument, we can instead
-use *method syntax* to call the `area` method on our `Rectangle` instance.
-The method syntax goes after an instance: we add a dot followed by the method
-name, parentheses, and any arguments.
-
-In the signature for `area`, we use `&self` instead of `rectangle: &Rectangle`
-because Rust knows the type of `self` is `Rectangle` due to this method’s being
-inside the `impl Rectangle` context. Note that we still need to use the `&`
-before `self`, just as we did in `&Rectangle`. Methods can take ownership of
-`self`, borrow `self` immutably as we’ve done here, or borrow `self` mutably,
-just as they can any other parameter.
-
-We’ve chosen `&self` here for the same reason we used `&Rectangle` in the
-function version: we don’t want to take ownership, and we just want to read the
-data in the struct, not write to it. If we wanted to change the instance that
-we’ve called the method on as part of what the method does, we’d use `&mut
-self` as the first parameter. Having a method that takes ownership of the
-instance by using just `self` as the first parameter is rare; this technique is
-usually used when the method transforms `self` into something else and you want
-to prevent the caller from using the original instance after the transformation.
-
-The main benefit of using methods instead of functions, in addition to using
-method syntax and not having to repeat the type of `self` in every method’s
-signature, is for organization. We’ve put all the things we can do with an
-instance of a type in one `impl` block rather than making future users of our
-code search for capabilities of `Rectangle` in various places in the library we
-provide.
-
-> ### Where’s the `->` Operator?
->
-> In C and C++, two different operators are used for calling methods: you use
-> `.` if you’re calling a method on the object directly and `->` if you’re
-> calling the method on a pointer to the object and need to dereference the
-> pointer first. In other words, if `object` is a pointer,
-> `object->something()` is similar to `(*object).something()`.
->
-> Rust doesn’t have an equivalent to the `->` operator; instead, Rust has a
-> feature called *automatic referencing and dereferencing*. Calling methods is
-> one of the few places in Rust that has this behavior.
->
-> Here’s how it works: when you call a method with `object.something()`, Rust
-> automatically adds in `&`, `&mut`, or `*` so `object` matches the signature of
-> the method. In other words, the following are the same:
->
-> ```rust
-> # #derive(Debug,Copy,Clone)
-> # struct Point {
-> #     x: f64,
-> #     y: f64,
-> # }
-> #
-> # impl Point {
-> #    fn distance(&self, other: &Point) -> f64 {
-> #        let x_squared = f64::powi(other.x - self.x, 2);
-> #        let y_squared = f64::powi(other.y - self.y, 2);
-> #
-> #        f64::sqrt(x_squared + y_squared)
-> #    }
-> # }
-> # let p1 = Point { x: 0.0, y: 0.0 };
-> # let p2 = Point { x: 5.0, y: 6.5 };
-> p1.distance(&p2);
-> (&p1).distance(&p2);
-> ```
->
-> The first one looks much cleaner. This automatic referencing behavior works
-> because methods have a clear receiver—the type of `self`. Given the receiver
-> and name of a method, Rust can figure out definitively whether the method is
-> reading (`&self`), mutating (`&mut self`), or consuming (`self`). The fact
-> that Rust makes borrowing implicit for method receivers is a big part of
-> making ownership ergonomic in practice.
-
-### Methods with More Parameters
-
-Let’s practice using methods by implementing a second method on the `Rectangle`
-struct. This time, we want an instance of `Rectangle` to take another instance
-of `Rectangle` and return `true` if the second `Rectangle` can fit completely
-within `self`; otherwise it should return `false`. That is, we want to be able
-to write the program shown in Listing 5-14, once we’ve defined the `can_hold`
-method:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let rect1 = Rectangle { width: 30, height: 50 };
-    let rect2 = Rectangle { width: 10, height: 40 };
-    let rect3 = Rectangle { width: 60, height: 45 };
-
-    println!("Can rect1 hold rect2? {}", rect1.can_hold(&rect2));
-    println!("Can rect1 hold rect3? {}", rect1.can_hold(&rect3));
-}
-```
-
-Listing 5-14: Using the as-yet-unwritten `can_hold` method
-
-And the expected output would look like the following, because both dimensions
-of `rect2` are smaller than the dimensions of `rect1` but `rect3` is wider than
-`rect1`:
-
-```
-Can rect1 hold rect2? true
-Can rect1 hold rect3? false
-```
-
-We know we want to define a method, so it will be within the `impl Rectangle`
-block. The method name will be `can_hold`, and it will take an immutable borrow
-of another `Rectangle` as a parameter. We can tell what the type of the
-parameter will be by looking at the code that calls the method:
-`rect1.can_hold(&rect2)` passes in `&rect2`, which is an immutable borrow to
-`rect2`, an instance of `Rectangle`. This makes sense because we only need to
-read `rect2` (rather than write, which would mean we’d need a mutable borrow),
-and we want `main` to retain ownership of `rect2` so we can use it again after
-calling the `can_hold` method. The return value of `can_hold` will be a
-Boolean, and the implementation will check whether the width and height of
-`self` are both greater than the width and height of the other `Rectangle`,
-respectively. Let’s add the new `can_hold` method to the `impl` block from
-Listing 5-13, shown in Listing 5-15:
-
-Filename: src/main.rs
-
-```
-# #[derive(Debug)]
-# struct Rectangle {
-#     width: u32,
-#     height: u32,
-# }
-#
-impl Rectangle {
-    fn area(&self) -> u32 {
-        self.width * self.height
-    }
-
-    fn can_hold(&self, other: &Rectangle) -> bool {
-        self.width > other.width && self.height > other.height
-    }
-}
-```
-
-Listing 5-15: Implementing the `can_hold` method on `Rectangle` that takes
-another `Rectangle` instance as a parameter
-
-When we run this code with the `main` function in Listing 5-14, we’ll get our
-desired output. Methods can take multiple parameters that we add to the
-signature after the `self` parameter, and those parameters work just like
-parameters in functions.
-
-### Associated Functions
-
-Another useful feature of `impl` blocks is that we’re allowed to define
-functions within `impl` blocks that *don’t* take `self` as a parameter. These
-are called *associated functions* because they’re associated with the struct.
-They’re still functions, not methods, because they don’t have an instance of
-the struct to work with. You’ve already used the `String::from` associated
-function.
-
-Associated functions are often used for constructors that will return a new
-instance of the struct. For example, we could provide an associated function
-that would have one dimension parameter and use that as both width and height,
-thus making it easier to create a square `Rectangle` rather than having to
-specify the same value twice:
-
-Filename: src/main.rs
-
-```
-# #[derive(Debug)]
-# struct Rectangle {
-#     width: u32,
-#     height: u32,
-# }
-#
-impl Rectangle {
-    fn square(size: u32) -> Rectangle {
-        Rectangle { width: size, height: size }
-    }
-}
-```
-
-To call this associated function, we use the `::` syntax with the struct name;
-`let sq = Rectangle::square(3);` is an example. This function is namespaced by
-the struct: the `::` syntax is used for both associated functions and
-namespaces created by modules. We’ll discuss modules in Chapter 7.
-
-### Multiple `impl` Blocks
-
-Each struct is allowed to have multiple `impl` blocks. For example, Listing
-5-15 is equivalent to the code shown in Listing 5-16, which has each method
-in its own `impl` block:
-
-```
-# #[derive(Debug)]
-# struct Rectangle {
-#     width: u32,
-#     height: u32,
-# }
-#
-impl Rectangle {
-    fn area(&self) -> u32 {
-        self.width * self.height
-    }
-}
-
-impl Rectangle {
-    fn can_hold(&self, other: &Rectangle) -> bool {
-        self.width > other.width && self.height > other.height
-    }
-}
-```
-
-Listing 5-16: Rewriting Listing 5-15 using multiple `impl` blocks
-
-There’s no reason to separate these methods into multiple `impl` blocks here,
-but this is valid syntax. We’ll see a case in which multiple `impl` blocks are
-useful in Chapter 10 where we discuss generic types and traits.
-
-## Summary
-
-Structs let you create custom types that are meaningful for your domain. By
-using structs, you can keep associated pieces of data connected to each other
-and name each piece to make your code clear. Methods let you specify the
-behavior that instances of your structs have, and associated functions let you
-namespace functionality that is particular to your struct without having an
-instance available.
-
-But structs aren’t the only way you can create custom types: let’s turn to
-Rust’s enum feature to add another tool to your toolbox.
diff --git a/src/doc/book/second-edition/nostarch/chapter06.md b/src/doc/book/second-edition/nostarch/chapter06.md
deleted file mode 100644
index acf4bffe94..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter06.md
+++ /dev/null
@@ -1,753 +0,0 @@
-
-[TOC]
-
-# Enums and Pattern Matching
-
-In this chapter we’ll look at *enumerations*, also referred to as *enums*.
-Enums allow you to define a type by enumerating its possible values. First,
-we’ll define and use an enum to show how an enum can encode meaning along with
-data. Next, we’ll explore a particularly useful enum, called `Option`, which
-expresses that a value can be either something or nothing. Then we’ll look at
-how pattern matching in the `match` expression makes it easy to run different
-code for different values of an enum. Finally, we’ll cover how the `if let`
-construct is another convenient and concise idiom available to you to handle
-enums in your code.
-
-Enums are a feature in many languages, but their capabilities differ in each
-language. Rust’s enums are most similar to *algebraic data types* in functional
-languages, such as F#, OCaml, and Haskell.
-
-## Defining an Enum
-
-Let’s look at a situation we might want to express in code and see why enums
-are useful and more appropriate than structs in this case. Say we need to work
-with IP addresses. Currently, two major standards are used for IP addresses:
-version four and version six. These are the only possibilities for an IP
-address that our program will come across: we can *enumerate* all possible
-values, which is where enumeration gets its name.
-
-Any IP address can be either a version four or a version six address, but not
-both at the same time. That property of IP addresses makes the enum data
-structure appropriate, because enum values can only be one of the variants.
-Both version four and version six addresses are still fundamentally IP
-addresses, so they should be treated as the same type when the code is handling
-situations that apply to any kind of IP address.
-
-We can express this concept in code by defining an `IpAddrKind` enumeration and
-listing the possible kinds an IP address can be, `V4` and `V6`. These are known
-as the *variants* of the enum:
-
-```
-enum IpAddrKind {
-    V4,
-    V6,
-}
-```
-
-`IpAddrKind` is now a custom data type that we can use elsewhere in our code.
-
-### Enum Values
-
-We can create instances of each of the two variants of `IpAddrKind` like this:
-
-```
-let four = IpAddrKind::V4;
-let six = IpAddrKind::V6;
-```
-
-Note that the variants of the enum are namespaced under its identifier, and we
-use a double colon to separate the two. The reason this is useful is that now
-both values `IpAddrKind::V4` and `IpAddrKind::V6` are of the same type:
-`IpAddrKind`. We can then, for instance, define a function that takes any
-`IpAddrKind`:
-
-```
-fn route(ip_type: IpAddrKind) { }
-```
-
-And we can call this function with either variant:
-
-```
-route(IpAddrKind::V4);
-route(IpAddrKind::V6);
-```
-
-Using enums has even more advantages. Thinking more about our IP address type,
-at the moment we don’t have a way to store the actual IP address *data*; we
-only know what *kind* it is. Given that you just learned about structs in
-Chapter 5, you might tackle this problem as shown in Listing 6-1:
-
-```
-enum IpAddrKind {
-    V4,
-    V6,
-}
-
-struct IpAddr {
-    kind: IpAddrKind,
-    address: String,
-}
-
-let home = IpAddr {
-    kind: IpAddrKind::V4,
-    address: String::from("127.0.0.1"),
-};
-
-let loopback = IpAddr {
-    kind: IpAddrKind::V6,
-    address: String::from("::1"),
-};
-```
-
-Listing 6-1: Storing the data and `IpAddrKind` variant of an IP address using a
-`struct`
-
-Here, we’ve defined a struct `IpAddr` that has two fields: a `kind` field that
-is of type `IpAddrKind` (the enum we defined previously) and an `address` field
-of type `String`. We have two instances of this struct. The first, `home`, has
-the value `IpAddrKind::V4` as its `kind` with associated address data of
-`127.0.0.1`. The second instance, `loopback`, has the other variant of
-`IpAddrKind` as its `kind` value, `V6`, and has address `::1` associated with
-it. We’ve used a struct to bundle the `kind` and `address` values together, so
-now the variant is associated with the value.
-
-We can represent the same concept in a more concise way using just an enum,
-rather than an enum inside a struct, by putting data directly into each enum
-variant. This new definition of the `IpAddr` enum says that both `V4` and `V6`
-variants will have associated `String` values:
-
-```
-enum IpAddr {
-    V4(String),
-    V6(String),
-}
-
-let home = IpAddr::V4(String::from("127.0.0.1"));
-
-let loopback = IpAddr::V6(String::from("::1"));
-```
-
-We attach data to each variant of the enum directly, so there is no need for an
-extra struct.
-
-There’s another advantage to using an enum rather than a struct: each variant
-can have different types and amounts of associated data. Version four type IP
-addresses will always have four numeric components that will have values
-between 0 and 255. If we wanted to store `V4` addresses as four `u8` values but
-still express `V6` addresses as one `String` value, we wouldn’t be able to with
-a struct. Enums handle this case with ease:
-
-```
-enum IpAddr {
-    V4(u8, u8, u8, u8),
-    V6(String),
-}
-
-let home = IpAddr::V4(127, 0, 0, 1);
-
-let loopback = IpAddr::V6(String::from("::1"));
-```
-
-We’ve shown several different ways to define data structures to store version
-four and version six IP addresses. However, as it turns out, wanting to store
-IP addresses and encode which kind they are is so common that the standard
-library has a definition we can use! Let’s look at how the standard library
-defines `IpAddr`: it has the exact enum and variants that we’ve defined and
-used, but it embeds the address data inside the variants in the form of two
-different structs, which are defined differently for each variant:
-
-```
-struct Ipv4Addr {
-    // --snip--
-}
-
-struct Ipv6Addr {
-    // --snip--
-}
-
-enum IpAddr {
-    V4(Ipv4Addr),
-    V6(Ipv6Addr),
-}
-```
-
-This code illustrates that you can put any kind of data inside an enum variant:
-strings, numeric types, or structs, for example. You can even include another
-enum! Also, standard library types are often not much more complicated than
-what you might come up with.
-
-Note that even though the standard library contains a definition for `IpAddr`,
-we can still create and use our own definition without conflict because we
-haven’t brought the standard library’s definition into our scope. We’ll talk
-more about bringing types into scope in Chapter 7.
-
-Let’s look at another example of an enum in Listing 6-2: this one has a wide
-variety of types embedded in its variants:
-
-```
-enum Message {
-    Quit,
-    Move { x: i32, y: i32 },
-    Write(String),
-    ChangeColor(i32, i32, i32),
-}
-```
-
-Listing 6-2: A `Message` enum whose variants each store different amounts and
-types of values
-
-This enum has four variants with different types:
-
-* `Quit` has no data associated with it at all.
-* `Move` includes an anonymous struct inside it.
-* `Write` includes a single `String`.
-* `ChangeColor` includes three `i32` values.
-
-Defining an enum with variants like the ones in Listing 6-2 is similar to
-defining different kinds of struct definitions, except the enum doesn’t use the
-`struct` keyword and all the variants are grouped together under the `Message`
-type. The following structs could hold the same data that the preceding enum
-variants hold:
-
-```
-struct QuitMessage; // unit struct
-struct MoveMessage {
-    x: i32,
-    y: i32,
-}
-struct WriteMessage(String); // tuple struct
-struct ChangeColorMessage(i32, i32, i32); // tuple struct
-```
-
-But if we used the different structs, which each have their own type, we
-couldn’t as easily define a function to take any of these kinds of messages as
-we could with the `Message` enum defined in Listing 6-2, which is a single type.
-
-There is one more similarity between enums and structs: just as we’re able to
-define methods on structs using `impl`, we’re also able to define methods on
-enums. Here’s a method named `call` that we could define on our `Message` enum:
-
-```
-impl Message {
-    fn call(&self) {
-        // method body would be defined here
-    }
-}
-
-let m = Message::Write(String::from("hello"));
-m.call();
-```
-
-The body of the method would use `self` to get the value that we called the
-method on. In this example, we’ve created a variable `m` that has the value
-`Message::Write(String::from("hello"))`, and that is what `self` will be in the
-body of the `call` method when `m.call()` runs.
-
-Let’s look at another enum in the standard library that is very common and
-useful: `Option`.
-
-### The `Option` Enum and Its Advantages Over Null Values
-
-In the previous section, we looked at how the `IpAddr` enum let us use Rust’s
-type system to encode more information than just the data into our program.
-This section explores a case study of `Option`, which is another enum defined
-by the standard library. The `Option` type is used in many places because it
-encodes the very common scenario in which a value could be something or it
-could be nothing. Expressing this concept in terms of the type system means the
-compiler can check whether you’ve handled all the cases you should be handling;
-this functionality can prevent bugs that are extremely common in other
-programming languages.
-
-Programming language design is often thought of in terms of which features you
-include, but the features you exclude are important too. Rust doesn’t have the
-null feature that many other languages have. *Null* is a value that means there
-is no value there. In languages with null, variables can always be in one of
-two states: null or not-null.
-
-In his 2009 presentation “Null References: The Billion Dollar Mistake,” Tony
-Hoare, the inventor of null, has this to say:
-
-> I call it my billion-dollar mistake. At that time, I was designing the first
-> comprehensive type system for references in an object-oriented language. My
-> goal was to ensure that all use of references should be absolutely safe, with
-> checking performed automatically by the compiler. But I couldn’t resist the
-> temptation to put in a null reference, simply because it was so easy to
-> implement. This has led to innumerable errors, vulnerabilities, and system
-> crashes, which have probably caused a billion dollars of pain and damage in
-> the last forty years.
-
-The problem with null values is that if you try to use a null value as a
-not-null value, you’ll get an error of some kind. Because this null or not-null
-property is pervasive, it’s extremely easy to make this kind of error.
-
-However, the concept that null is trying to express is still a useful one: a
-null is a value that is currently invalid or absent for some reason.
-
-The problem isn’t really with the concept but with the particular
-implementation. As such, Rust does not have nulls, but it does have an enum
-that can encode the concept of a value being present or absent. This enum is
-`Option`, and it is defined by the standard library as follows:
-
-```
-enum Option {
-    Some(T),
-    None,
-}
-```
-
-The `Option` enum is so useful that it’s even included in the prelude; you
-don’t need to bring it into scope explicitly. In addition, so are its variants:
-you can use `Some` and `None` directly without the `Option::` prefix. The
-`Option` enum is still just a regular enum, and `Some(T)` and `None` are
-still variants of type `Option`.
-
-The `` syntax is a feature of Rust we haven’t talked about yet. It’s a
-generic type parameter, and we’ll cover generics in more detail in Chapter 10.
-For now, all you need to know is that `` means the `Some` variant of the
-`Option` enum can hold one piece of data of any type. Here are some examples of
-using `Option` values to hold number types and string types:
-
-```
-let some_number = Some(5);
-let some_string = Some("a string");
-
-let absent_number: Option = None;
-```
-
-If we use `None` rather than `Some`, we need to tell Rust what type of
-`Option` we have, because the compiler can’t infer the type that the `Some`
-variant will hold by looking only at a `None` value.
-
-When we have a `Some` value, we know that a value is present and the value is
-held within the `Some`. When we have a `None` value, in some sense, it means
-the same thing as null: we don’t have a valid value. So why is having
-`Option` any better than having null?
-
-In short, because `Option` and `T` (where `T` can be any type) are different
-types, the compiler won’t let us use an `Option` value as if it were
-definitely a valid value. For example, this code won’t compile because it’s
-trying to add an `i8` to an `Option`:
-
-```
-let x: i8 = 5;
-let y: Option = Some(5);
-
-let sum = x + y;
-```
-
-If we run this code, we get an error message like this:
-
-```
-error[E0277]: the trait bound `i8: std::ops::Add>` is
-not satisfied
- -->
-  |
-5 |     let sum = x + y;
-  |                 ^ no implementation for `i8 + std::option::Option`
-  |
-```
-
-Intense! In effect, this error message means that Rust doesn’t understand how
-to add an `i8` and an `Option`, because they’re different types. When we
-have a value of a type like `i8` in Rust, the compiler will ensure that we
-always have a valid value. We can proceed confidently without having to check
-for null before using that value. Only when we have an `Option` (or
-whatever type of value we’re working with) do we have to worry about possibly
-not having a value, and the compiler will make sure we handle that case before
-using the value.
-
-In other words, you have to convert an `Option` to a `T` before you can
-perform `T` operations with it. Generally, this helps catch one of the most
-common issues with null: assuming that something isn’t null when it actually
-is.
-
-Not having to worry about incorrectly assuming a not-null value helps you to be
-more confident in your code. In order to have a value that can possibly be
-null, you must explicitly opt in by making the type of that value `Option`.
-Then, when you use that value, you are required to explicitly handle the case
-when the value is null. Everywhere that a value has a type that isn’t an
-`Option`, you *can* safely assume that the value isn’t null. This was a
-deliberate design decision for Rust to limit null’s pervasiveness and increase
-the safety of Rust code.
-
-So, how do you get the `T` value out of a `Some` variant when you have a value
-of type `Option` so you can use that value? The `Option` enum has a large
-number of methods that are useful in a variety of situations; you can check
-them out in its documentation. Becoming familiar with the methods on
-`Option` will be extremely useful in your journey with Rust.
-
-In general, in order to use an `Option` value, you want to have code that
-will handle each variant. You want some code that will run only when you have a
-`Some(T)` value, and this code is allowed to use the inner `T`. You want some
-other code to run if you have a `None` value, and that code doesn’t have a `T`
-value available. The `match` expression is a control flow construct that does
-just this when used with enums: it will run different code depending on which
-variant of the enum it has, and that code can use the data inside the matching
-value.
-
-## The `match` Control Flow Operator
-
-Rust has an extremely powerful control flow operator called `match` that allows
-you to compare a value against a series of patterns and then execute code based
-on which pattern matches. Patterns can be made up of literal values, variable
-names, wildcards, and many other things; Chapter 18 covers all the different
-kinds of patterns and what they do. The power of `match` comes from the
-expressiveness of the patterns and the fact that the compiler confirms that all
-possible cases are handled.
-
-Think of a `match` expression as being like a coin-sorting machine: coins slide
-down a track with variously sized holes along it, and each coin falls through
-the first hole it encounters that it fits into. In the same way, values go
-through each pattern in a `match`, and at the first pattern the value “fits,”
-the value falls into the associated code block to be used during execution.
-
-Because we just mentioned coins, let’s use them as an example using `match`! We
-can write a function that can take an unknown United States coin and, in a
-similar way as the counting machine, determine which coin it is and return its
-value in cents, as shown here in Listing 6-3:
-
-```
-enum Coin {
-    Penny,
-    Nickel,
-    Dime,
-    Quarter,
-}
-
-fn value_in_cents(coin: Coin) -> u32 {
-    match coin {
-        Coin::Penny => 1,
-        Coin::Nickel => 5,
-        Coin::Dime => 10,
-        Coin::Quarter => 25,
-    }
-}
-```
-
-Listing 6-3: An enum and a `match` expression that has the variants of the enum
-as its patterns
-
-Let’s break down the `match` in the `value_in_cents` function. First, we list
-the `match` keyword followed by an expression, which in this case is the value
-`coin`. This seems very similar to an expression used with `if`, but there’s a
-big difference: with `if`, the expression needs to return a Boolean value, but
-here, it can be any type. The type of `coin` in this example is the `Coin` enum
-that we defined on line 1.
-
-Next are the `match` arms. An arm has two parts: a pattern and some code. The
-first arm here has a pattern that is the value `Coin::Penny` and then the `=>`
-operator that separates the pattern and the code to run. The code in this case
-is just the value `1`. Each arm is separated from the next with a comma.
-
-When the `match` expression executes, it compares the resulting value against
-the pattern of each arm, in order. If a pattern matches the value, the code
-associated with that pattern is executed. If that pattern doesn’t match the
-value, execution continues to the next arm, much as in a coin-sorting machine.
-We can have as many arms as we need: in Listing 6-3, our `match` has four arms.
-
-The code associated with each arm is an expression, and the resulting value of
-the expression in the matching arm is the value that gets returned for the
-entire `match` expression.
-
-Curly brackets typically aren’t used if the match arm code is short, as it is
-in Listing 6-3 where each arm just returns a value. If you want to run multiple
-lines of code in a match arm, you can use curly brackets. For example, the
-following code would print “Lucky penny!” every time the method was called with
-a `Coin::Penny` but would still return the last value of the block, `1`:
-
-```
-fn value_in_cents(coin: Coin) -> u32 {
-    match coin {
-        Coin::Penny => {
-            println!("Lucky penny!");
-            1
-        },
-        Coin::Nickel => 5,
-        Coin::Dime => 10,
-        Coin::Quarter => 25,
-    }
-}
-```
-
-### Patterns that Bind to Values
-
-Another useful feature of match arms is that they can bind to the parts of the
-values that match the pattern. This is how we can extract values out of enum
-variants.
-
-As an example, let’s change one of our enum variants to hold data inside it.
-From 1999 through 2008, the United States minted quarters with different
-designs for each of the 50 states on one side. No other coins got state
-designs, so only quarters have this extra value. We can add this information to
-our `enum` by changing the `Quarter` variant to include a `UsState` value stored
-inside it, which we’ve done here in Listing 6-4:
-
-```
-#[derive(Debug)] // So we can inspect the state in a minute
-enum UsState {
-    Alabama,
-    Alaska,
-    // --snip--
-}
-
-enum Coin {
-    Penny,
-    Nickel,
-    Dime,
-    Quarter(UsState),
-}
-```
-
-Listing 6-4: A `Coin` enum in which the `Quarter` variant also holds a
-`UsState` value
-
-Let’s imagine that a friend of ours is trying to collect all 50 state quarters.
-While we sort our loose change by coin type, we’ll also call out the name of
-the state associated with each quarter so if it’s one our friend doesn’t have,
-they can add it to their collection.
-
-In the match expression for this code, we add a variable called `state` to the
-pattern that matches values of the variant `Coin::Quarter`. When a
-`Coin::Quarter` matches, the `state` variable will bind to the value of that
-quarter’s state. Then we can use `state` in the code for that arm, like so:
-
-```
-fn value_in_cents(coin: Coin) -> u32 {
-    match coin {
-        Coin::Penny => 1,
-        Coin::Nickel => 5,
-        Coin::Dime => 10,
-        Coin::Quarter(state) => {
-            println!("State quarter from {:?}!", state);
-            25
-        },
-    }
-}
-```
-
-If we were to call `value_in_cents(Coin::Quarter(UsState::Alaska))`, `coin`
-would be `Coin::Quarter(UsState::Alaska)`. When we compare that value with each
-of the match arms, none of them match until we reach `Coin::Quarter(state)`. At
-that point, the binding for `state` will be the value `UsState::Alaska`. We can
-then use that binding in the `println!` expression, thus getting the inner
-state value out of the `Coin` enum variant for `Quarter`.
-
-### Matching with `Option`
-
-In the previous section, we wanted to get the inner `T` value out of the `Some`
-case when using `Option`; we can also handle `Option` using `match` as we
-did with the `Coin` enum! Instead of comparing coins, we’ll compare the
-variants of `Option`, but the way that the `match` expression works remains
-the same.
-
-Let’s say we want to write a function that takes an `Option` and, if
-there’s a value inside, adds 1 to that value. If there isn’t a value inside,
-the function should return the `None` value and not attempt to perform any
-operations.
-
-This function is very easy to write, thanks to `match`, and will look like
-Listing 6-5:
-
-```
-fn plus_one(x: Option) -> Option {
-    match x {
-        None => None,
-        Some(i) => Some(i + 1),
-    }
-}
-
-let five = Some(5);
-let six = plus_one(five);
-let none = plus_one(None);
-```
-
-Listing 6-5: A function that uses a `match` expression on an `Option`
-
-Let’s examine the first execution of `plus_one` in more detail. When we call
-`plus_one(five)`, the variable `x` in the body of `plus_one` will have the
-value `Some(5)`. We then compare that against each match arm.
-
-```
-None => None,
-```
-
-The `Some(5)` value doesn’t match the pattern `None`, so we continue to the
-next arm.
-
-```
-Some(i) => Some(i + 1),
-```
-
-Does `Some(5)` match `Some(i)`? Why yes it does! We have the same variant. The
-`i` binds to the value contained in `Some`, so `i` takes the value `5`. The
-code in the match arm is then executed, so we add 1 to the value of `i` and
-create a new `Some` value with our total `6` inside.
-
-Now let’s consider the second call of `plus_one` in Listing 6-5, where `x` is
-`None`. We enter the `match` and compare to the first arm.
-
-```
-None => None,
-```
-
-It matches! There’s no value to add to, so the program stops and returns the
-`None` value on the right side of `=>`. Because the first arm matched, no other
-arms are compared.
-
-Combining `match` and enums is useful in many situations. You’ll see this
-pattern a lot in Rust code: `match` against an enum, bind a variable to the
-data inside, and then execute code based on it. It’s a bit tricky at first, but
-once you get used to it, you’ll wish you had it in all languages. It’s
-consistently a user favorite.
-
-### Matches Are Exhaustive
-
-There’s one other aspect of `match` we need to discuss. Consider this version
-of our `plus_one` function that has a bug and won’t compile:
-
-```
-fn plus_one(x: Option) -> Option {
-    match x {
-        Some(i) => Some(i + 1),
-    }
-}
-```
-
-We didn’t handle the `None` case, so this code will cause a bug. Luckily, it’s
-a bug Rust knows how to catch. If we try to compile this code, we’ll get this
-error:
-
-```
-error[E0004]: non-exhaustive patterns: `None` not covered
- -->
-  |
-6 |         match x {
-  |               ^ pattern `None` not covered
-```
-
-Rust knows that we didn’t cover every possible case and even knows which
-pattern we forgot! Matches in Rust are *exhaustive*: we must exhaust every last
-possibility in order for the code to be valid. Especially in the case of
-`Option`, when Rust prevents us from forgetting to explicitly handle the
-`None` case, it protects us from assuming that we have a value when we might
-have null, thus making the billion-dollar mistake discussed earlier.
-
-### The `_` Placeholder
-
-Rust also has a pattern we can use when we don’t want to list all possible
-values. For example, a `u8` can have valid values of 0 through 255. If we only
-care about the values 1, 3, 5, and 7, we don’t want to have to list out 0, 2,
-4, 6, 8, 9 all the way up to 255. Fortunately, we don’t have to: we can use the
-special pattern `_` instead:
-
-```
-let some_u8_value = 0u8;
-match some_u8_value {
-    1 => println!("one"),
-    3 => println!("three"),
-    5 => println!("five"),
-    7 => println!("seven"),
-    _ => (),
-}
-```
-
-The `_` pattern will match any value. By putting it after our other arms, the
-`_` will match all the possible cases that aren’t specified before it. The `()`
-is just the unit value, so nothing will happen in the `_` case. As a result, we
-can say that we want to do nothing for all the possible values that we don’t
-list before the `_` placeholder.
-
-However, the `match` expression can be a bit wordy in a situation in which we
-only care about *one* of the cases. For this situation, Rust provides `if let`.
-
-## Concise Control Flow with `if let`
-
-The `if let` syntax lets you combine `if` and `let` into a less verbose way to
-handle values that match one pattern while ignoring the rest. Consider the
-program in Listing 6-6 that matches on an `Option` value but only wants to
-execute code if the value is 3:
-
-```
-let some_u8_value = Some(0u8);
-match some_u8_value {
-    Some(3) => println!("three"),
-    _ => (),
-}
-```
-
-Listing 6-6: A `match` that only cares about executing code when the value is
-`Some(3)`
-
-We want to do something with the `Some(3)` match but do nothing with any other
-`Some` value or the `None` value. To satisfy the `match` expression, we
-have to add `_ => ()` after processing just one variant, which is a lot of
-boilerplate code to add.
-
-Instead, we could write this in a shorter way using `if let`. The following
-code behaves the same as the `match` in Listing 6-6:
-
-```
-if let Some(3) = some_u8_value {
-    println!("three");
-}
-```
-
-The syntax `if let` takes a pattern and an expression separated by an `=`. It
-works the same way as a `match`, where the expression is given to the `match`
-and the pattern is its first arm.
-
-Using `if let` means you have less typing, less indentation, and less
-boilerplate code. However, you lose the exhaustive checking that `match`
-enforces. Choosing between `match` and `if let` depends on what you’re doing in
-your particular situation and whether gaining conciseness is an appropriate
-trade-off for losing exhaustive checking.
-
-In other words, you can think of `if let` as syntax sugar for a `match` that
-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, 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:
-
-```
-let mut count = 0;
-match coin {
-    Coin::Quarter(state) => println!("State quarter from {:?}!", state),
-    _ => count += 1,
-}
-```
-
-Or we could use an `if let` and `else` expression like this:
-
-```
-let mut count = 0;
-if let Coin::Quarter(state) = coin {
-    println!("State quarter from {:?}!", state);
-} else {
-    count += 1;
-}
-```
-
-If you have a situation in which your program has logic that is too verbose to
-express using a `match`, remember that `if let` is in your Rust toolbox as well.
-
-## Summary
-
-We’ve now covered how to use enums to create custom types that can be one of a
-set of enumerated values. We’ve shown how the standard library’s `Option`
-type helps you use the type system to prevent errors. When enum values have
-data inside them, you can use `match` or `if let` to extract and use those
-values, depending on how many cases you need to handle.
-
-Your Rust programs can now express concepts in your domain using structs and
-enums. Creating custom types to use in your API ensures type safety: the
-compiler will make certain your functions get only values of the type each
-function expects.
-
-In order to provide a well-organized API to your users that is straightforward
-to use and only exposes exactly what your users will need, let’s now turn to
-Rust’s modules.
diff --git a/src/doc/book/second-edition/nostarch/chapter07.md b/src/doc/book/second-edition/nostarch/chapter07.md
deleted file mode 100644
index 7be64e7930..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter07.md
+++ /dev/null
@@ -1,1069 +0,0 @@
-
-[TOC]
-
-# Using Modules to Reuse and Organize Code
-
-When you start writing programs in Rust, your code might live solely in the
-`main` function. As your code grows, you’ll eventually move functionality into
-other functions for reuse and better organization. By splitting your code into
-smaller chunks, you make each chunk easier to understand on its own. But what
-happens if you have too many functions? Rust has a module system that enables
-the reuse of code in an organized fashion.
-
-In the same way that you extract lines of code into a function, you can extract
-functions (and other code, like structs and enums) into different modules. A
-*module* is a namespace that contains definitions of functions or types, and
-you can choose whether those definitions are visible outside their module
-(public) or not (private). Here’s an overview of how modules work:
-
-* The `mod` keyword declares a new module. Code within the module appears
-  either immediately following this declaration within curly brackets or in
-  another file.
-* By default, functions, types, constants, and modules are private. The `pub`
-  keyword makes an item public and therefore visible outside its namespace.
-* The `use` keyword brings modules, or the definitions inside modules, into
-  scope so it’s easier to refer to them.
-
-We’ll look at each of these parts to see how they fit into the whole.
-
-## `mod` and the Filesystem
-
-We’ll start our module example by making a new project with Cargo, but instead
-of creating a binary crate, we’ll make a library crate: a project that other
-people can pull into their projects as a dependency. For example, the `rand`
-crate discussed in Chapter 2 is a library crate that we used as a dependency in
-the guessing game project.
-
-We’ll create a skeleton of a library that provides some general networking
-functionality; we’ll concentrate on the organization of the modules and
-functions, but we won’t worry about what code goes in the function bodies.
-We’ll call our library `communicator`. To create a library, pass the `--lib`
-option instead of `--bin`:
-
-```
-$ cargo new communicator --lib
-$ cd communicator
-```
-
-Notice that Cargo generated *src/lib.rs* instead of *src/main.rs*. Inside
-*src/lib.rs* we’ll find the following:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn it_works() {
-        assert_eq!(2 + 2, 4);
-    }
-}
-```
-
-Cargo creates an example test to help us get our library started, rather than
-the “Hello, world!” binary that we get when we use the `--bin` option. We’ll
-look at the `#[]` and `mod tests` syntax in the “Using `super` to Access a
-Parent Module” section later in this chapter, but for now, leave this code at
-the bottom of *src/lib.rs*.
-
-Because we don’t have a *src/main.rs* file, there’s nothing for Cargo to
-execute with the `cargo run` command. Therefore, we’ll use the `cargo build`
-command to compile our library crate’s code.
-
-We’ll look at different options for organizing your library’s code that will be
-suitable in a variety of situations, depending on the intent of the code.
-
-### Module Definitions
-
-For our `communicator` networking library, we’ll first define a module named
-`network` that contains the definition of a function called `connect`. Every
-module definition in Rust starts with the `mod` keyword. Add this code to the
-beginning of the *src/lib.rs* file, above the test code:
-
-Filename: src/lib.rs
-
-```
-mod network {
-    fn connect() {
-    }
-}
-```
-
-After the `mod` keyword, we put the name of the module, `network`, and then a
-block of code in curly brackets. Everything inside this block is inside the
-namespace `network`. In this case, we have a single function, `connect`. If we
-wanted to call this function from code outside the `network` module, we
-would need to specify the module and use the namespace syntax `::` like so:
-`network::connect()`.
-
-We can also have multiple modules, side by side, in the same *src/lib.rs* file.
-For example, to also have a `client` module that has a function named
-`connect`, we can add it as shown in Listing 7-1:
-
-Filename: src/lib.rs
-
-```
-mod network {
-    fn connect() {
-    }
-}
-
-mod client {
-    fn connect() {
-    }
-}
-```
-
-Listing 7-1: The `network` module and the `client` module defined side by side
-in *src/lib.rs*
-
-Now we have a `network::connect` function and a `client::connect` function.
-These can have completely different functionality, and the function names do
-not conflict with each other because they’re in different modules.
-
-In this case, because we’re building a library, the file that serves as the
-entry point for building our library is *src/lib.rs*. However, in respect to
-creating modules, there’s nothing special about *src/lib.rs*. We could also
-create modules in *src/main.rs* for a binary crate in the same way as we’re
-creating modules in *src/lib.rs* for the library crate. In fact, we can put
-modules inside of modules, which can be useful as your modules grow to keep
-related functionality organized together and separate functionality apart. The
-way you choose to organize your code depends on how you think about the
-relationship between the parts of your code. For instance, the `client` code
-and its `connect` function might make more sense to users of our library if
-they were inside the `network` namespace instead, as in Listing 7-2:
-
-Filename: src/lib.rs
-
-```
-mod network {
-    fn connect() {
-    }
-
-    mod client {
-        fn connect() {
-        }
-    }
-}
-```
-
-Listing 7-2: Moving the `client` module inside the `network` module
-
-In your *src/lib.rs* file, replace the existing `mod network` and `mod client`
-definitions with the ones in Listing 7-2, which have the `client` module as an
-inner module of `network`. The functions `network::connect` and
-`network::client::connect` are both named `connect`, but they don’t conflict
-with each other because they’re in different namespaces.
-
-In this way, modules form a hierarchy. The contents of *src/lib.rs* are at the
-topmost level, and the submodules are at lower levels. Here’s what the
-organization of our example in Listing 7-1 looks like when thought of as a
-hierarchy:
-
-```
-communicator
- ├── network
- └── client
-```
-
-And here’s the hierarchy corresponding to the example in Listing 7-2:
-
-```
-communicator
- └── network
-     └── client
-```
-
-The hierarchy shows that in Listing 7-2, `client` is a child of the `network`
-module rather than a sibling. More complicated projects can have many modules,
-and they’ll need to be organized logically in order for you to keep track of
-them. What “logically” means in your project is up to you and depends on how
-you and your library’s users think about your project’s domain. Use the
-techniques shown here to create side-by-side modules and nested modules in
-whatever structure you would like.
-
-### Moving Modules to Other Files
-
-Modules form a hierarchical structure, much like another structure in computing
-that you’re used to: filesystems! We can use Rust’s module system along with
-multiple files to split up Rust projects so not everything lives in
-*src/lib.rs* or *src/main.rs*. For this example, let’s start with the code in
-Listing 7-3:
-
-Filename: src/lib.rs
-
-```
-mod client {
-    fn connect() {
-    }
-}
-
-mod network {
-    fn connect() {
-    }
-
-    mod server {
-        fn connect() {
-        }
-    }
-}
-```
-
-Listing 7-3: Three modules, `client`, `network`, and `network::server`, all
-defined in *src/lib.rs*
-
-The file *src/lib.rs* has this module hierarchy:
-
-```
-communicator
- ├── client
- └── network
-     └── server
-```
-
-If these modules had many functions, and those functions were becoming lengthy,
-it would be difficult to scroll through this file to find the code we wanted to
-work with. Because the functions are nested inside one or more `mod` blocks,
-the lines of code inside the functions will start getting lengthy as well.
-These would be good reasons to separate the `client`, `network`, and `server`
-modules from *src/lib.rs* and place them into their own files.
-
-First, let’s replace the `client` module code with only the declaration of the
-`client` module so that *src/lib.rs* looks like code shown in Listing 7-4:
-
-Filename: src/lib.rs
-
-```
-mod client;
-
-mod network {
-    fn connect() {
-    }
-
-    mod server {
-        fn connect() {
-        }
-    }
-}
-```
-
-Listing 7-4: Extracting the contents of the `client` module but leaving the
-declaration in *src/lib.rs*
-
-We’re still *declaring* the `client` module here, but by replacing the block
-with a semicolon, we’re telling Rust to look in another location for the code
-defined within the scope of the `client` module. In other words, the line `mod
-client;` means this:
-
-```
-mod client {
-    // contents of client.rs
-}
-```
-
-Now we need to create the external file with that module name. Create a
-*client.rs* file in your *src/* directory and open it. Then enter the
-following, which is the `connect` function in the `client` module that we
-removed in the previous step:
-
-Filename: src/client.rs
-
-```
-fn connect() {
-}
-```
-
-Note that we don’t need a `mod` declaration in this file because we already
-declared the `client` module with `mod` in *src/lib.rs*. This file just
-provides the *contents* of the `client` module. If we put a `mod client` here,
-we’d be giving the `client` module its own submodule named `client`!
-
-Rust only knows to look in *src/lib.rs* by default. If we want to add more
-files to our project, we need to tell Rust in *src/lib.rs* to look in other
-files; this is why `mod client` needs to be defined in *src/lib.rs* and can’t
-be defined in *src/client.rs*.
-
-Now the project should compile successfully, although you’ll get a few
-warnings. Remember to use `cargo build` instead of `cargo run` because we have
-a library crate rather than a binary crate:
-
-```
-$ cargo build
-   Compiling communicator v0.1.0 (file:///projects/communicator)
-warning: function is never used: `connect`
- --> src/client.rs:1:1
-  |
-1 | / fn connect() {
-2 | | }
-  | |_^
-  |
-  = note: #[warn(dead_code)] on by default
-
-warning: function is never used: `connect`
- --> src/lib.rs:4:5
-  |
-4 | /     fn connect() {
-5 | |     }
-  | |_____^
-
-warning: function is never used: `connect`
- --> src/lib.rs:8:9
-  |
-8 | /         fn connect() {
-9 | |         }
-  | |_________^
-```
-
-These warnings tell us that we have functions that are never used. Don’t worry
-about these warnings for now; we’ll address them later in this chapter in the
-“Controlling Visibility with `pub`” section. The good news is that they’re just
-warnings; our project built successfully!
-
-Next, let’s extract the `network` module into its own file using the same
-pattern. In *src/lib.rs*, delete the body of the `network` module and add a
-semicolon to the declaration, like so:
-
-Filename: src/lib.rs
-
-```
-mod client;
-
-mod network;
-```
-
-Then create a new *src/network.rs* file and enter the following:
-
-Filename: src/network.rs
-
-```
-fn connect() {
-}
-
-mod server {
-    fn connect() {
-    }
-}
-```
-
-Notice that we still have a `mod` declaration within this module file; this is
-because we still want `server` to be a submodule of `network`.
-
-Run `cargo build` again. Success! We have one more module to extract: `server`.
-Because it’s a submodule—that is, a module within a module—our current tactic
-of extracting a module into a file named after that module won’t work. We’ll
-try anyway so you can see the error. First, change *src/network.rs* to have
-`mod server;` instead of the `server` module’s contents:
-
-Filename: src/network.rs
-
-```
-fn connect() {
-}
-
-mod server;
-```
-
-Then create a *src/server.rs* file and enter the contents of the `server`
-module that we extracted:
-
-Filename: src/server.rs
-
-```
-fn connect() {
-}
-```
-
-When we try to `cargo build`, we’ll get the error shown in Listing 7-5:
-
-```
-$ cargo build
-   Compiling communicator v0.1.0 (file:///projects/communicator)
-error: cannot declare a new module at this location
- --> src/network.rs:4:5
-  |
-4 | mod server;
-  |     ^^^^^^
-  |
-note: maybe move this module `src/network.rs` to its own directory via `src/network/mod.rs`
- --> src/network.rs:4:5
-  |
-4 | mod server;
-  |     ^^^^^^
-note: ... or maybe `use` the module `server` instead of possibly redeclaring it
- --> src/network.rs:4:5
-  |
-4 | mod server;
-  |     ^^^^^^
-```
-
-Listing 7-5: Error when trying to extract the `server` submodule into
-*src/server.rs*
-
-The error says we `cannot declare a new module at this location` and is
-pointing to the `mod server;` line in *src/network.rs*. So *src/network.rs* is
-different than *src/lib.rs* somehow: keep reading to understand why.
-
-The note in the middle of Listing 7-5 is actually very helpful because it
-points out something we haven’t yet talked about doing:
-
-```
-note: maybe move this module `network` to its own directory via
-`network/mod.rs`
-```
-
-Instead of continuing to follow the same file-naming pattern we used
-previously, we can do what the note suggests:
-
-1. Make a new *directory* named *network*, the parent module’s name.
-2. Move the *src/network.rs* file into the new *network* directory and
-   rename it *src/network/mod.rs*.
-3. Move the submodule file *src/server.rs* into the *network* directory.
-
-Here are commands to carry out these steps:
-
-```
-$ mkdir src/network
-$ mv src/network.rs src/network/mod.rs
-$ mv src/server.rs src/network
-```
-
-Now when we try to run `cargo build`, compilation will work (we’ll still have
-warnings though). Our module layout still looks exactly the same as it did when
-we had all the code in *src/lib.rs* in Listing 7-3:
-
-```
-communicator
- ├── client
- └── network
-     └── server
-```
-
-The corresponding file layout now looks like this:
-
-```
-└── src
-    ├── client.rs
-    ├── lib.rs
-    └── network
-        ├── mod.rs
-        └── server.rs
-```
-
-So when we wanted to extract the `network::server` module, why did we have to
-also change the *src/network.rs* file to the *src/network/mod.rs* file and put
-the code for `network::server` in the *network* directory in
-*src/network/server.rs*? Why couldn’t we just extract the `network::server`
-module into *src/server.rs*? The reason is that Rust wouldn’t be able to
-recognize that `server` was supposed to be a submodule of `network` if the
-*server.rs* file was in the *src* directory. To clarify Rust’s behavior here,
-let’s consider a different example with the following module hierarchy, where
-all the definitions are in *src/lib.rs*:
-
-```
-communicator
- ├── client
- └── network
-     └── client
-```
-
-In this example, we have three modules again: `client`, `network`, and
-`network::client`. Following the same steps we did earlier for extracting
-modules into files, we would create *src/client.rs* for the `client` module.
-For the `network` module, we would create *src/network.rs*. But we wouldn’t be
-able to extract the `network::client` module into a *src/client.rs* file
-because that already exists for the top-level `client` module! If we could put
-the code for *both* the `client` and `network::client` modules in the
-*src/client.rs* file, Rust wouldn’t have any way to know whether the code was
-for `client` or for `network::client`.
-
-Therefore, in order to extract a file for the `network::client` submodule of
-the `network` module, we needed to create a directory for the `network` module
-instead of a *src/network.rs* file. The code that is in the `network` module
-then goes into the *src/network/mod.rs* file, and the submodule
-`network::client` can have its own *src/network/client.rs* file. Now the
-top-level *src/client.rs* is unambiguously the code that belongs to the
-`client` module.
-
-### Rules of Module Filesystems
-
-Let’s summarize the rules of modules with regard to files:
-
-* If a module named `foo` has no submodules, you should put the declarations
-  for `foo` in a file named *foo.rs*.
-* If a module named `foo` does have submodules, you should put the declarations
-  for `foo` in a file named *foo/mod.rs*.
-
-These rules apply recursively, so if a module named `foo` has a submodule named
-`bar` and `bar` does not have submodules, you should have the following files
-in your *src* directory:
-
-```
-└── foo
-    ├── bar.rs (contains the declarations in `foo::bar`)
-    └── mod.rs (contains the declarations in `foo`, including `mod bar`)
-```
-
-The modules should be declared in their parent module’s file using the `mod`
-keyword.
-
-Next, we’ll talk about the `pub` keyword and get rid of those warnings!
-
-## Controlling Visibility with `pub`
-
-We resolved the error messages shown in Listing 7-5 by moving the `network` and
-`network::server` code into the *src/network/mod.rs* and
-*src/network/server.rs* files, respectively. At that point, `cargo build` was
-able to build our project, but we still get warning messages about the
-`client::connect`, `network::connect`, and `network::server::connect` functions
-not being used.
-
-So why are we receiving these warnings? After all, we’re building a library
-with functions that are intended to be used by our *users*, not necessarily by
-us within our own project, so it shouldn’t matter that these `connect`
-functions go unused. The point of creating them is that they will be used by
-another project, not our own.
-
-To understand why this program invokes these warnings, let’s try using the
-`connect` library from another project, calling it externally. To do that,
-we’ll create a binary crate in the same directory as our library crate by
-making a *src/main.rs* file containing this code:
-
-Filename: src/main.rs
-
-```
-extern crate communicator;
-
-fn main() {
-    communicator::client::connect();
-}
-```
-
-We use the `extern crate` command to bring the `communicator` library crate
-into scope. Our package now contains *two* crates. Cargo treats *src/main.rs*
-as the root file of a binary crate, which is separate from the existing library
-crate whose root file is *src/lib.rs*. This pattern is quite common for
-executable projects: most functionality is in a library crate, and the binary
-crate uses that library crate. As a result, other programs can also use the
-library crate, and it’s a nice separation of concerns.
-
-From the point of view of a crate outside the `communicator` library looking
-in, all the modules we’ve been creating are within a module that has the same
-name as the crate, `communicator`. We call the top-level module of a crate the
-*root module*.
-
-Also note that even if we’re using an external crate within a submodule of our
-project, the `extern crate` should go in our root module (so in *src/main.rs*
-or *src/lib.rs*). Then, in our submodules, we can refer to items from external
-crates as if the items are top-level modules.
-
-Right now, our binary crate just calls our library’s `connect` function from
-the `client` module. However, invoking `cargo build` will now give us an error
-after the warnings:
-
-```
-error[E0603]: module `client` is private
- --> src/main.rs:4:5
-  |
-4 |     communicator::client::connect();
-  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-```
-
-Ah ha! This error tells us that the `client` module is private, which is the
-crux of the warnings. It’s also the first time we’ve run into the concepts of
-*public* and *private* in the context of Rust. The default state of all code in
-Rust is private: no one else is allowed to use the code. If you don’t use a
-private function within your program, because your program is the only code
-allowed to use that function, Rust will warn you that the function has gone
-unused.
-
-After you specify that a function such as `client::connect` is public, not only
-will your call to that function from your binary crate be allowed, but also the
-warning that the function is unused will go away. Marking a function as public
-lets Rust know that the function will be used by code outside of your program.
-Rust considers the theoretical external usage that’s now possible as the
-function “being used.” Thus, when a function is marked public, Rust will not
-require that it be used in your program and will stop warning that the function
-is unused.
-
-### Making a Function Public
-
-To tell Rust to make a function public, we add the `pub` keyword to the start
-of the declaration. We’ll focus on fixing the warning that indicates
-`client::connect` has gone unused for now, as well as the `` module `client` is
-private `` error from our binary crate. Modify *src/lib.rs* to make the
-`client` module public, like so:
-
-Filename: src/lib.rs
-
-```
-pub mod client;
-
-mod network;
-```
-
-The `pub` keyword is placed right before `mod`. Let’s try building again:
-
-```
-error[E0603]: function `connect` is private
- --> src/main.rs:4:5
-  |
-4 |     communicator::client::connect();
-  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-```
-
-Hooray! We have a different error! Yes, different error messages are a cause
-for celebration. The new error shows `` function `connect` is private ``, so
-let’s edit *src/client.rs* to make `client::connect` public too:
-
-Filename: src/client.rs
-
-```
-pub fn connect() {
-}
-```
-
-Now run `cargo build` again:
-
-```
-warning: function is never used: `connect`
- --> src/network/mod.rs:1:1
-  |
-1 | / fn connect() {
-2 | | }
-  | |_^
-  |
-  = note: #[warn(dead_code)] on by default
-
-warning: function is never used: `connect`
- --> src/network/server.rs:1:1
-  |
-1 | / fn connect() {
-2 | | }
-  | |_^
-```
-
-The code compiled, and the warning that `client::connect` is not being used is
-gone!
-
-Unused code warnings don’t always indicate that an item in your code needs to
-be made public: if you *didn’t* want these functions to be part of your public
-API, unused code warnings could be alerting you to code you no longer need that
-you can safely delete. They could also be alerting you to a bug if you had just
-accidentally removed all places within your library where this function is
-called.
-
-But in this case, we *do* want the other two functions to be part of our
-crate’s public API, so let’s mark them as `pub` as well to get rid of the
-remaining warnings. Modify *src/network/mod.rs* to look like the following:
-
-Filename: src/network/mod.rs
-
-```
-pub fn connect() {
-}
-
-mod server;
-```
-
-Then compile the code:
-
-```
-warning: function is never used: `connect`
- --> src/network/mod.rs:1:1
-  |
-1 | / pub fn connect() {
-2 | | }
-  | |_^
-  |
-  = note: #[warn(dead_code)] on by default
-
-warning: function is never used: `connect`
- --> src/network/server.rs:1:1
-  |
-1 | / fn connect() {
-2 | | }
-  | |_^
-```
-
-Hmmm, we’re still getting an unused function warning, even though
-`network::connect` is set to `pub`. The reason is that the function is public
-within the module, but the `network` module that the function resides in is not
-public. We’re working from the interior of the library out this time, whereas
-with `client::connect` we worked from the outside in. We need to change
-*src/lib.rs* to make `network` public too, like so:
-
-Filename: src/lib.rs
-
-```
-pub mod client;
-
-pub mod network;
-```
-
-Now when we compile, that warning is gone:
-
-```
-warning: function is never used: `connect`
- --> src/network/server.rs:1:1
-  |
-1 | / fn connect() {
-2 | | }
-  | |_^
-  |
-  = note: #[warn(dead_code)] on by default
-```
-
-Only one warning is left—try to fix this one on your own!
-
-### Privacy Rules
-
-Overall, these are the rules for item visibility:
-
-- If an item is public, it can be accessed through any of its parent modules.
-- If an item is private, it can be accessed only by its immediate parent
-  module and any of the parent’s child modules.
-
-### Privacy Examples
-
-Let’s look at a few more privacy examples to get some practice. Create a new
-library project and enter the code in Listing 7-6 into your new project’s
-*src/lib.rs*:
-
-Filename: src/lib.rs
-
-```
-mod outermost {
-    pub fn middle_function() {}
-
-    fn middle_secret_function() {}
-
-    mod inside {
-        pub fn inner_function() {}
-
-        fn secret_function() {}
-    }
-}
-
-fn try_me() {
-    outermost::middle_function();
-    outermost::middle_secret_function();
-    outermost::inside::inner_function();
-    outermost::inside::secret_function();
-}
-```
-
-Listing 7-6: Examples of private and public functions, some of which are
-incorrect
-
-Before you try to compile this code, make a guess about which lines in the
-`try_me` function will have errors. Then, try compiling the code to see whether
-you were right—and read on for the discussion of the errors!
-
-#### Looking at the Errors
-
-The `try_me` function is in the root module of our project. The module named
-`outermost` is private, but the second privacy rule states that the `try_me`
-function is allowed to access the `outermost` module because `outermost` is in
-the current (root) module, as is `try_me`.
-
-The call to `outermost::middle_function` will work because `middle_function` is
-public and `try_me` is accessing `middle_function` through its parent module
-`outermost`. We determined in the previous paragraph that this module is
-accessible.
-
-The call to `outermost::middle_secret_function` will cause a compilation error.
-Because `middle_secret_function` is private, the second rule applies. The root
-module is neither the current module of `middle_secret_function` (`outermost`
-is), nor is it a child module of the current module of `middle_secret_function`.
-
-The module named `inside` is private and has no child modules, so it can be
-accessed only by its current module `outermost`. That means the `try_me`
-function is not allowed to call `outermost::inside::inner_function` or
-`outermost::inside::secret_function`.
-
-#### Fixing the Errors
-
-Here are some suggestions for changing the code in an attempt to fix the
-errors. Make a guess as to whether it will fix the errors before you try each
-one. Then compile the code to see whether or not you’re right, using the
-privacy rules to understand why. Feel free to design more experiments and try
-them out!
-
-* What if the `inside` module were public?
-* What if `outermost` were public and `inside` were private?
-* What if, in the body of `inner_function`, you called
-  `::outermost::middle_secret_function()`? (The two colons at the beginning mean
-  that we want to refer to the modules starting from the root module.)
-
-Next, let’s talk about bringing items into scope with the `use` keyword.
-
-## Referring to Names in Different Modules
-
-We’ve covered how to call functions defined within a module using the module
-name as part of the call, as in the call to the `nested_modules` function shown
-here in Listing 7-7:
-
-Filename: src/main.rs
-
-```
-pub mod a {
-    pub mod series {
-        pub mod of {
-            pub fn nested_modules() {}
-        }
-    }
-}
-
-fn main() {
-    a::series::of::nested_modules();
-}
-```
-
-Listing 7-7: Calling a function by fully specifying its enclosing module’s path
-
-As you can see, referring to the fully qualified name can get quite lengthy.
-Fortunately, Rust has a keyword to make these calls more concise.
-
-### Bringing Names into Scope with the `use` Keyword
-
-Rust’s `use` keyword shortens lengthy function calls by bringing the modules of
-the function you want to call into scope. Here’s an example of bringing the
-`a::series::of` module into a binary crate’s root scope:
-
-Filename: src/main.rs
-
-```
-pub mod a {
-    pub mod series {
-        pub mod of {
-            pub fn nested_modules() {}
-        }
-    }
-}
-
-use a::series::of;
-
-fn main() {
-    of::nested_modules();
-}
-```
-
-The line `use a::series::of;` means that rather than using the full
-`a::series::of` path wherever we want to refer to the `of` module, we can use
-`of`.
-
-The `use` keyword brings only what we’ve specified into scope: it does not
-bring children of modules into scope. That’s why we still have to use
-`of::nested_modules` when we want to call the `nested_modules` function.
-
-We could have chosen to bring the function into scope by instead specifying the
-function in the `use` as follows:
-
-```
-pub mod a {
-    pub mod series {
-        pub mod of {
-            pub fn nested_modules() {}
-        }
-    }
-}
-
-use a::series::of::nested_modules;
-
-fn main() {
-    nested_modules();
-}
-```
-
-Doing so allows us to exclude all the modules and reference the function
-directly.
-
-Because enums also form a sort of namespace like modules, we can bring an
-enum’s variants into scope with `use` as well. For any kind of `use` statement,
-if you’re bringing multiple items from one namespace into scope, you can list
-them using curly brackets and commas in the last position, like so:
-
-```
-enum TrafficLight {
-    Red,
-    Yellow,
-    Green,
-}
-
-use TrafficLight::{Red, Yellow};
-
-fn main() {
-    let red = Red;
-    let yellow = Yellow;
-    let green = TrafficLight::Green;
-}
-```
-
-We’re still specifying the `TrafficLight` namespace for the `Green` variant
-because we didn’t include `Green` in the `use` statement.
-
-### Bringing All Names into Scope with a Glob
-
-To bring all the items in a namespace into scope at once, we can use the `*`
-syntax, which is called the *glob operator*. This example brings all the
-variants of an enum into scope without having to list each specifically:
-
-```
-enum TrafficLight {
-    Red,
-    Yellow,
-    Green,
-}
-
-use TrafficLight::*;
-
-fn main() {
-    let red = Red;
-    let yellow = Yellow;
-    let green = Green;
-}
-```
-
-The `*` will bring into scope all the visible items in the `TrafficLight`
-namespace. You should use globs sparingly: they are convenient, but a glob
-might also pull in more items than you expected and cause naming conflicts.
-
-### Using `super` to Access a Parent Module
-
-As you saw at the beginning of this chapter, when you create a library crate,
-Cargo makes a `tests` module for you. Let’s go into more detail about that now.
-In your `communicator` project, open *src/lib.rs*:
-
-Filename: src/lib.rs
-
-```
-pub mod client;
-
-pub mod network;
-
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn it_works() {
-        assert_eq!(2 + 2, 4);
-    }
-}
-```
-
-Chapter 11 explains more about testing, but parts of this example should make
-sense now: we have a module named `tests` that lives next to our other modules
-and contains one function named `it_works`. Even though there are special
-annotations, the `tests` module is just another module! So our module hierarchy
-looks like this:
-
-```
-communicator
- ├── client
- ├── network
- |   └── client
- └── tests
-```
-
-Tests are for exercising the code within our library, so let’s try to call our
-`client::connect` function from this `it_works` function, even though we won’t
-be checking any functionality right now. This won’t work yet:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn it_works() {
-        client::connect();
-    }
-}
-```
-
-Run the tests by invoking the `cargo test` command:
-
-```
-$ cargo test
-   Compiling communicator v0.1.0 (file:///projects/communicator)
-error[E0433]: failed to resolve. Use of undeclared type or module `client`
- --> src/lib.rs:9:9
-  |
-9 |         client::connect();
-  |         ^^^^^^ Use of undeclared type or module `client`
-```
-
-The compilation failed, but why? We don’t need to place `communicator::` in
-front of the function, as we did in *src/main.rs*, because we are definitely
-within the `communicator` library crate here. The reason is that paths are
-always relative to the current module, which here is `tests`. The only
-exception is in a `use` statement, where paths are relative to the crate root
-by default. Our `tests` module needs the `client` module in its scope!
-
-So how do we get back up one module in the module hierarchy to call the
-`client::connect` function in the `tests` module? In the `tests` module, we can
-either use leading colons to let Rust know that we want to start from the root
-and list the whole path, like this:
-
-```
-::client::connect();
-```
-
-Or, we can use `super` to move up one module in the hierarchy from our current
-module, like this:
-
-```
-super::client::connect();
-```
-
-These two options don’t look that different in this example, but if you’re
-deeper in a module hierarchy, starting from the root every time would make your
-code lengthy. In those cases, using `super` to get from the current module to
-sibling modules is a good shortcut. Plus, if you’ve specified the path from the
-root in many places in your code and then rearrange your modules by moving a
-subtree to another place, you’ll end up needing to update the path in several
-places, which would be tedious.
-
-It would also be annoying to have to type `super::` in each test, but you’ve
-already seen the tool for that solution: `use`! The `super::` functionality
-changes the path you give to `use` so it is relative to the parent module
-instead of to the root module.
-
-For these reasons, in the `tests` module especially, `use super::something` is
-usually the best solution. So now our test looks like this:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    use super::client;
-
-    #[test]
-    fn it_works() {
-        client::connect();
-    }
-}
-```
-
-When we run `cargo test` again, the test will pass, and the first part of the
-test result output will be the following:
-
-```
-$ cargo test
-   Compiling communicator v0.1.0 (file:///projects/communicator)
-     Running target/debug/communicator-92007ddb5330fa5a
-
-running 1 test
-test tests::it_works ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-## Summary
-
-Now you know some new techniques for organizing your code! Use these techniques
-to group related functionality together, keep files from becoming too long, and
-present a tidy public API to your library users.
-
-Next, we’ll look at some collection data structures in the standard library
-that you can use in your nice, neat code.
diff --git a/src/doc/book/second-edition/nostarch/chapter08.md b/src/doc/book/second-edition/nostarch/chapter08.md
deleted file mode 100644
index c824e9045b..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter08.md
+++ /dev/null
@@ -1,1046 +0,0 @@
-
-[TOC]
-
-# Common Collections
-
-Rust’s standard library includes a number of very useful data structures called
-*collections*. Most other data types represent one specific value, but
-collections can contain multiple values. Unlike the built-in array and tuple
-types, the data these collections point to is stored on the heap, which means
-the amount of data does not need to be known at compile time and can grow or
-shrink as the program runs. Each kind of collection has different capabilities
-and costs, and choosing an appropriate one for your current situation is a
-skill you’ll develop over time. In this chapter, we’ll discuss three
-collections that are used very often in Rust programs:
-
-* A *vector* allows you to store a variable number of values next to each other.
-* A *string* is a collection of characters. We’ve mentioned the `String` type
-  previously, but in this chapter we’ll talk about it in depth.
-* A *hash map* allows you to associate a value with a particular key. It’s a
-  particular implementation of the more general data structure called a *map*.
-
-To learn about the other kinds of collections provided by the standard library,
-see the documentation at *https://doc.rust-lang.org/stable/std/collections/*.
-
-We’ll discuss how to create and update vectors, strings, and hash maps, as well
-as what makes each special.
-
-## Storing Lists of Values with Vectors
-
-The first collection type we’ll look at is `Vec`, also known as a *vector*.
-Vectors allow you to store more than one value in a single data structure that
-puts all the values next to each other in memory. Vectors can only store values
-of the same type. They are useful when you have a list of items, such as the
-lines of text in a file or the prices of items in a shopping cart.
-
-### Creating a New Vector
-
-To create a new, empty vector, we can call the `Vec::new` function, as shown in
-Listing 8-1:
-
-```
-let v: Vec = Vec::new();
-```
-
-Listing 8-1: Creating a new, empty vector to hold values of type `i32`
-
-Note that we added a type annotation here. Because we aren’t inserting any
-values into this vector, Rust doesn’t know what kind of elements we intend to
-store. This is an important point. Vectors are implemented using generics;
-we’ll cover how to use generics with your own types in Chapter 10. For now,
-know that the `Vec` type provided by the standard library can hold any type,
-and when a specific vector holds a specific type, the type is specified within
-angle brackets. In Listing 8-1, we’ve told Rust that the `Vec` in `v` will
-hold elements of the `i32` type.
-
-In more realistic code, Rust can often infer the type of value you want to
-store once you insert values, so you rarely need to do this type annotation.
-It’s more common to create a `Vec` that has initial values, and Rust
-provides the `vec!` macro for convenience. The macro will create a new vector
-that holds the values you give it. Listing 8-2 creates a new `Vec` that
-holds the values `1`, `2`, and `3`:
-
-```
-let v = vec![1, 2, 3];
-```
-
-Listing 8-2: Creating a new vector containing values
-
-Because we’ve given initial `i32` values, Rust can infer that the type of `v`
-is `Vec`, and the type annotation isn’t necessary. Next, we’ll look at how
-to modify a vector.
-
-### Updating a Vector
-
-To create a vector and then add elements to it, we can use the `push` method,
-as shown in Listing 8-3:
-
-```
-let mut v = Vec::new();
-
-v.push(5);
-v.push(6);
-v.push(7);
-v.push(8);
-```
-
-Listing 8-3: Using the `push` method to add values to a vector
-
-As with any variable, if we want to be able to change its value, we need to
-make it mutable using the `mut` keyword, as discussed in Chapter 3. The numbers
-we place inside are all of type `i32`, and Rust infers this from the data, so
-we don’t need the `Vec` annotation.
-
-### Dropping a Vector Drops Its Elements
-
-Like any other `struct`, a vector is freed when it goes out of scope, as
-annotated in Listing 8-4:
-
-```
-{
-    let v = vec![1, 2, 3, 4];
-
-    // do stuff with v
-
-} // <- v goes out of scope and is freed here
-```
-
-Listing 8-4: Showing where the vector and its elements are dropped
-
-When the vector gets dropped, all of its contents are also dropped, meaning
-those integers it holds will be cleaned up. This may seem like a
-straightforward point but can get a bit more complicated when you start to
-introduce references to the elements of the vector. Let’s tackle that next!
-
-### Reading Elements of Vectors
-
-Now that you know how to create, update, and destroy vectors, knowing how to
-read their contents is a good next step. There are two ways to reference a
-value stored in a vector. In the examples, we’ve annotated the types of the
-values that are returned from these functions for extra clarity.
-
-Listing 8-5 shows both methods of accessing a value in a vector, either with
-indexing syntax or the `get` method:
-
-```
-let v = vec![1, 2, 3, 4, 5];
-
-let third: &i32 = &v[2];
-let third: Option<&i32> = v.get(2);
-```
-
-Listing 8-5: Using indexing syntax or the `get` method to access an item in a
-vector
-
-Note two details here. First, we use the index value of `2` to get the third
-element: vectors are indexed by number, starting at zero. Second, the two ways
-to get the third element are by using `&` and `[]`, which gives us a reference,
-or by using the `get` method with the index passed as an argument, which gives
-us an `Option<&T>`.
-
-Rust has two ways to reference an element so you can choose how the program
-behaves when you try to use an index value that the vector doesn’t have an
-element for. As an example, let’s see what a program will do if it has a vector
-that holds five elements and then tries to access an element at index 100, as
-shown in Listing 8-6:
-
-```
-let v = vec![1, 2, 3, 4, 5];
-
-let does_not_exist = &v[100];
-let does_not_exist = v.get(100);
-```
-
-Listing 8-6: Attempting to access the element at index 100 in a vector
-containing five elements
-
-When we run this code, the first `[]` method will cause the program to panic
-because it references a nonexistent element. This method is best used when you
-want your program to crash if there’s an attempt to access an element past the
-end of the vector.
-
-When the `get` method is passed an index that is outside the vector, it returns
-`None` without panicking. You would use this method if accessing an element
-beyond the range of the vector happens occasionally under normal circumstances.
-Your code will then have logic to handle having either `Some(&element)` or
-`None`, as discussed in Chapter 6. For example, the index could be coming from
-a person entering a number. If they accidentally enter a number that’s too
-large and the program gets a `None` value, you could tell the user how many
-items are in the current vector and give them another chance to enter a valid
-value. That would be more user-friendly than crashing the program due to a typo!
-
-When the program has a valid reference, the borrow checker enforces the
-ownership and borrowing rules (covered in Chapter 4) to ensure this reference
-and any other references to the contents of the vector remain valid. Recall the
-rule that states you can’t have mutable and immutable references in the same
-scope. That rule applies in Listing 8-7, where we hold an immutable reference to
-the first element in a vector and try to add an element to the end, which won’t
-work:
-
-```
-let mut v = vec![1, 2, 3, 4, 5];
-
-let first = &v[0];
-
-v.push(6);
-```
-
-Listing 8-7: Attempting to add an element to a vector while holding a reference
-to an item
-
-Compiling this code will result in this error:
-
-```
-error[E0502]: cannot borrow `v` as mutable because it is also borrowed as immutable
- -->
-  |
-4 |     let first = &v[0];
-  |                  - immutable borrow occurs here
-5 |
-6 |     v.push(6);
-  |     ^ mutable borrow occurs here
-7 |
-8 | }
-  | - immutable borrow ends here
-```
-
-The code in Listing 8-7 might look like it should work: why should a reference
-to the first element care about what changes at the end of the vector? This
-error is due to the way vectors work: adding a new element onto the end of the
-vector might require allocating new memory and copying the old elements to the
-new space, if there isn’t enough room to put all the elements next to each
-other where the vector currently is. In that case, the reference to the first
-element would be pointing to deallocated memory. The borrowing rules prevent
-programs from ending up in that situation.
-
-> Note: For more on the implementation details of the `Vec` type, see “The
-> Rustonomicon” at https://doc.rust-lang.org/stable/nomicon/vec.html.
-
-### Iterating over the Values in a Vector
-
-If we want to access each element in a vector in turn, we can iterate through
-all of the elements rather than use indexes to access one at a time. Listing
-8-8 shows how to use a `for` loop to get immutable references to each element
-in a vector of `i32` values and print them:
-
-```
-let v = vec![100, 32, 57];
-for i in &v {
-    println!("{}", i);
-}
-```
-
-Listing 8-8: Printing each element in a vector by iterating over the elements
-using a `for` loop
-
-We can also iterate over mutable references to each element in a mutable vector
-in order to make changes to all the elements. The `for` loop in Listing 8-9
-will add `50` to each element:
-
-```
-let mut v = vec![100, 32, 57];
-for i in &mut v {
-    *i += 50;
-}
-```
-
-Listing 8-9: Iterating over mutable references to elements in a vector
-
-To change the value that the mutable reference refers to, we have to use the
-dereference operator (`*`) to get to the value in `i` before we can use the
-`+=` operator .
-
-### Using an Enum to Store Multiple Types
-
-At the beginning of this chapter, we said that vectors can only store values
-that are the same type. This can be inconvenient; there are definitely use
-cases for needing to store a list of items of different types. Fortunately, the
-variants of an enum are defined under the same enum type, so when we need to
-store elements of a different type in a vector, we can define and use an enum!
-
-For example, say we want to get values from a row in a spreadsheet in which
-some of the columns in the row contain integers, some floating-point numbers,
-and some strings. We can define an enum whose variants will hold the different
-value types, and then all the enum variants will be considered the same type:
-that of the enum. Then we can create a vector that holds that enum and so,
-ultimately, holds different types. We’ve demonstrated this in Listing 8-10:
-
-```
-enum SpreadsheetCell {
-    Int(i32),
-    Float(f64),
-    Text(String),
-}
-
-let row = vec![
-    SpreadsheetCell::Int(3),
-    SpreadsheetCell::Text(String::from("blue")),
-    SpreadsheetCell::Float(10.12),
-];
-```
-
-Listing 8-10: Defining an `enum` to store values of different types in one
-vector
-
-Rust needs to know what types will be in the vector at compile time so it knows
-exactly how much memory on the heap will be needed to store each element. A
-secondary advantage is that we can be explicit about what types are allowed in
-this vector. If Rust allowed a vector to hold any type, there would be a chance
-that one or more of the types would cause errors with the operations performed
-on the elements of the vector. Using an enum plus a `match` expression means
-that Rust will ensure at compile time that every possible case is handled, as
-discussed in Chapter 6.
-
-When you’re writing a program, if you don’t know the exhaustive set of types
-the program will get at runtime to store in a vector, the enum technique won’t
-work. Instead, you can use a trait object, which we’ll cover in Chapter 17.
-
-Now that we’ve discussed some of the most common ways to use vectors, be sure
-to review the API documentation for all the many useful methods defined on
-`Vec` by the standard library. For example, in addition to `push`, a `pop`
-method removes and returns the last element. Let’s move on to the next
-collection type: `String`!
-
-## Storing UTF-8 Encoded Text with Strings
-
-We talked about strings in Chapter 4, but we’ll look at them in more depth now.
-New Rustaceans commonly get stuck on strings due to a combination of three
-reasons: Rust’s propensity for exposing possible errors, strings being a more
-complicated data structure than many programmers give them credit for, and
-UTF-8. These factors combine in a way that can seem difficult when you’re
-coming from other programming languages.
-
-It’s useful to discuss strings in the context of collections because strings
-are implemented as a collection of bytes, plus some methods to provide useful
-functionality when those bytes are interpreted as text. In this section, we’ll
-talk about the operations on `String` that every collection type has, such as
-creating, updating, and reading. We’ll also discuss the ways in which `String`
-is different from the other collections, namely how indexing into a `String` is
-complicated by the differences between how people and computers interpret
-`String` data.
-
-### What Is a String?
-
-We’ll first define what we mean by the term *string*. Rust has only one string
-type in the core language, which is the string slice `str` that is usually seen
-in its borrowed form `&str`. In Chapter 4, we talked about *string slices*,
-which are references to some UTF-8 encoded string data stored elsewhere. String
-literals, for example, are stored in the binary output of the program and are
-therefore string slices.
-
-The `String` type, which is provided by Rust’s standard library rather than
-coded into the core language, is a growable, mutable, owned, UTF-8 encoded
-string type. When Rustaceans refer to “strings” in Rust, they usually mean the
-`String` and the string slice `&str` types, not just one of those types.
-Although this section is largely about `String`, both types are used heavily in
-Rust’s standard library, and both `String` and string slices are UTF-8 encoded.
-
-Rust’s standard library also includes a number of other string types, such as
-`OsString`, `OsStr`, `CString`, and `CStr`. Library crates can provide even
-more options for storing string data. See how those names all end in `String`
-or `Str`? They refer to owned and borrowed variants, just like the `String` and
-`str` types you’ve seen previously. These string types can store text in
-different encodings or be represented in memory in a different way, for
-example. We won’t discuss these other string types in this chapter; see their
-API documentation for more about how to use them and when each is appropriate.
-
-### Creating a New String
-
-Many of the same operations available with `Vec` are available with `String`
-as well, starting with the `new` function to create a string, shown in Listing
-8-11:
-
-```
-let mut s = String::new();
-```
-
-Listing 8-11: Creating a new, empty `String`
-
-This line creates a new empty string called `s`, which we can then load data
-into. Often, we’ll have some initial data that we want to start the string
-with. For that, we use the `to_string` method, which is available on any type
-that implements the `Display` trait, as string literals do. Listing 8-12 shows
-two examples:
-
-```
-let data = "initial contents";
-
-let s = data.to_string();
-
-// the method also works on a literal directly:
-let s = "initial contents".to_string();
-```
-
-Listing 8-12: Using the `to_string` method to create a `String` from a string
-literal
-
-This code creates a string containing `initial contents`.
-
-We can also use the function `String::from` to create a `String` from a string
-literal. The code in Listing 8-13 is equivalent to the code from Listing 8-12
-that uses `to_string`:
-
-```
-let s = String::from("initial contents");
-```
-
-Listing 8-13: Using the `String::from` function to create a `String` from a
-string literal
-
-Because strings are used for so many things, we can use many different generic
-APIs for strings, providing us with a lot of options. Some of them can seem
-redundant, but they all have their place! In this case, `String::from` and
-`to_string` do the same thing, so which you choose is a matter of style.
-
-Remember that strings are UTF-8 encoded, so we can include any properly encoded
-data in them, as shown in Listing 8-14:
-
-```
-let hello = String::from("السلام عليكم");
-let hello = String::from("Dobrý den");
-let hello = String::from("Hello");
-let hello = String::from("שָׁלוֹם");
-let hello = String::from("नमस्ते");
-let hello = String::from("こんにちは");
-let hello = String::from("안녕하세요");
-let hello = String::from("你好");
-let hello = String::from("Olá");
-let hello = String::from("Здравствуйте");
-let hello = String::from("Hola");
-```
-
-Listing 8-14: Storing greetings in different languages in strings
-
-All of these are valid `String` values.
-
-### Updating a String
-
-A `String` can grow in size and its contents can change, just like the contents
-of a `Vec`, if you push more data into it. In addition, you can conveniently
-use the `+` operator or the `format!` macro to concatenate `String` values.
-
-#### Appending to a String with `push_str` and `push`
-
-We can grow a `String` by using the `push_str` method to append a string slice,
-as shown in Listing 8-15:
-
-```
-let mut s = String::from("foo");
-s.push_str("bar");
-```
-
-Listing 8-15: Appending a string slice to a `String` using the `push_str` method
-
-After these two lines, `s` will contain `foobar`. The `push_str` method takes a
-string slice because we don’t necessarily want to take ownership of the
-parameter. For example, the code in Listing 8-16 shows that it would be
-unfortunate if we weren’t able to use `s2` after appending its contents to `s1`:
-
-```
-let mut s1 = String::from("foo");
-let s2 = "bar";
-s1.push_str(s2);
-println!("s2 is {}", s2);
-```
-
-Listing 8-16: Using a string slice after appending its contents to a `String`
-
-If the `push_str` method took ownership of `s2`, we wouldn’t be able to print
-its value on the last line. However, this code works as we’d expect!
-
-The `push` method takes a single character as a parameter and adds it to the
-`String`. Listing 8-17 shows code that adds the letter l to a `String` using
-the `push` method:
-
-```
-let mut s = String::from("lo");
-s.push('l');
-```
-
-Listing 8-17: Adding one character to a `String` value using `push`
-
-As a result of this code, `s` will contain `lol`.
-
-#### Concatenation with the `+` Operator or the `format!` Macro
-
-Often, you’ll want to combine two existing strings. One way is to use the `+`
-operator, as shown in Listing 8-18:
-
-```
-let s1 = String::from("Hello, ");
-let s2 = String::from("world!");
-let s3 = s1 + &s2; // Note s1 has been moved here and can no longer be used
-```
-
-Listing 8-18: Using the `+` operator to combine two `String` values into a new
-`String` value
-
-The string `s3` will contain `Hello, world!` as a result of this code. The
-reason `s1` is no longer valid after the addition and the reason we used a
-reference to `s2` has to do with the signature of the method that gets called
-when we use the `+` operator. The `+` operator uses the `add` method, whose
-signature looks something like this:
-
-```
-fn add(self, s: &str) -> String {
-```
-
-This isn’t the exact signature that’s in the standard library: in the standard
-library, `add` is defined using generics. Here, we’re looking at the signature
-of `add` with concrete types substituted for the generic ones, which is what
-happens when we call this method with `String` values. We’ll discuss generics
-in Chapter 10. This signature gives us the clues we need to understand the
-tricky bits of the `+` operator.
-
-First, `s2` has an `&`, meaning that we’re adding a *reference* of the second
-string to the first string because of the `s` parameter in the `add` function:
-we can only add a `&str` to a `String`; we can’t add two `String` values
-together. But wait—the type of `&s2` is `&String`, not `&str`, as specified in
-the second parameter to `add`. So why does Listing 8-18 compile?
-
-The reason we’re able to use `&s2` in the call to `add` is that the compiler
-can *coerce* the `&String` argument into a `&str`. When we call the `add`
-method, Rust uses a *deref coercion*, which here turns `&s2` into `&s2[..]`.
-We’ll discuss deref coercion in more depth in Chapter 15. Because `add` does
-not take ownership of the `s` parameter, `s2` will still be a valid `String`
-after this operation.
-
-Second, we can see in the signature that `add` takes ownership of `self`,
-because `self` does *not* have an `&`. This means `s1` in Listing 8-18 will be
-moved into the `add` call and no longer be valid after that. So although `let
-s3 = s1 + &s2;` looks like it will copy both strings and create a new one, this
-statement actually takes ownership of `s1`, appends a copy of the contents of
-`s2`, and then returns ownership of the result. In other words, it looks like
-it’s making a lot of copies but isn’t; the implementation is more efficient
-than copying.
-
-If we need to concatenate multiple strings, the behavior of the `+` operator
-gets unwieldy:
-
-```
-let s1 = String::from("tic");
-let s2 = String::from("tac");
-let s3 = String::from("toe");
-
-let s = s1 + "-" + &s2 + "-" + &s3;
-```
-
-At this point, `s` will be `tic-tac-toe`. With all of the `+` and `"`
-characters, it’s difficult to see what’s going on. For more complicated string
-combining, we can use the `format!` macro:
-
-```
-let s1 = String::from("tic");
-let s2 = String::from("tac");
-let s3 = String::from("toe");
-
-let s = format!("{}-{}-{}", s1, s2, s3);
-```
-
-This code also sets `s` to `tic-tac-toe`. The `format!` macro works in the same
-way as `println!`, but instead of printing the output to the screen, it returns
-a `String` with the contents. The version of the code using `format!` is much
-easier to read and doesn’t take ownership of any of its parameters.
-
-### Indexing into Strings
-
-In many other programming languages, accessing individual characters in a
-string by referencing them by index is a valid and common operation. However,
-if you try to access parts of a `String` using indexing syntax in Rust, you’ll
-get an error. Consider the invalid code in Listing 8-19:
-
-```
-let s1 = String::from("hello");
-let h = s1[0];
-```
-
-Listing 8-19: Attempting to use indexing syntax with a String
-
-This code will result in the following error:
-
-```
-error[E0277]: the trait bound `std::string::String: std::ops::Index<{integer}>` is not satisfied
- -->
-  |
-3 |     let h = s1[0];
-  |             ^^^^^ the type `std::string::String` cannot be indexed by `{integer}`
-  |
-  = help: the trait `std::ops::Index<{integer}>` is not implemented for `std::string::String`
-```
-
-The error and the note tell the story: Rust strings don’t support indexing. But
-why not? To answer that question, we need to discuss how Rust stores strings in
-memory.
-
-#### Internal Representation
-
-A `String` is a wrapper over a `Vec`. Let’s look at some of our properly
-encoded UTF-8 example strings from Listing 8-14. First, this one:
-
-```
-let len = String::from("Hola").len();
-```
-
-In this case, `len` will be 4, which means the vector storing the string “Hola”
-is 4 bytes long. Each of these letters takes 1 byte when encoded in UTF-8. But
-what about the following line? (Note that this line begins with the capital
-Cyrillic letter Ze, not the Arabic number 3.)
-
-```
-let len = String::from("Здравствуйте").len();
-```
-
-Asked how long the string is, you might say 12. However, Rust’s answer is 24:
-that’s the number of bytes it takes to encode “Здравствуйте” in UTF-8, because
-each Unicode scalar value takes 2 bytes of storage. Therefore, an index into
-the string’s bytes will not always correlate to a valid Unicode scalar value.
-To demonstrate, consider this invalid Rust code:
-
-```
-let hello = "Здравствуйте";
-let answer = &hello[0];
-```
-
-What should the value of `answer` be? Should it be `З`, the first letter? When
-encoded in UTF-8, the first byte of `З` is `208` and the second is `151`, so
-`answer` should in fact be `208`, but `208` is not a valid character on its
-own. Returning `208` is likely not what a user would want if they asked for the
-first letter of this string; however, that’s the only data that Rust has at
-byte index 0. Users generally don’t want the byte value returned, even if the
-string contains only Latin letters: if `&"hello"[0]` were valid code that
-returned the byte value, it would return `104`, not `h`. To avoid returning an
-unexpected value and causing bugs that might not be discovered immediately,
-Rust doesn’t compile this code at all and prevents misunderstandings early in
-the development process.
-
-#### Bytes and Scalar Values and Grapheme Clusters! Oh My!
-
-Another point about UTF-8 is that there are actually three relevant ways to
-look at strings from Rust’s perspective: as bytes, scalar values, and grapheme
-clusters (the closest thing to what we would call *letters*).
-
-If we look at the Hindi word “नमस्ते” written in the Devanagari script, it is
-stored as a vector of `u8` values that looks like this:
-
-```
-[224, 164, 168, 224, 164, 174, 224, 164, 184, 224, 165, 141, 224, 164, 164,
-224, 165, 135]
-```
-
-That’s 18 bytes and is how computers ultimately store this data. If we look at
-them as Unicode scalar values, which are what Rust’s `char` type is, those
-bytes look like this:
-
-```
-['न', 'म', 'स', '्', 'त', 'े']
-```
-
-There are six `char` values here, but the fourth and sixth are not letters:
-they’re diacritics that don’t make sense on their own. Finally, if we look at
-them as grapheme clusters, we’d get what a person would call the four letters
-that make up the Hindi word:
-
-```
-["न", "म", "स्", "ते"]
-```
-
-Rust provides different ways of interpreting the raw string data that computers
-store so that each program can choose the interpretation it needs, no matter
-what human language the data is in.
-
-A final reason Rust doesn’t allow us to index into a `String` to get a
-character is that indexing operations are expected to always take constant time
-(O(1)). But it isn’t possible to guarantee that performance with a `String`,
-because Rust would have to walk through the contents from the beginning to the
-index to determine how many valid characters there were.
-
-### Slicing Strings
-
-Indexing into a string is often a bad idea because it’s not clear what the
-return type of the string-indexing operation should be: a byte value, a
-character, a grapheme cluster, or a string slice. Therefore, Rust asks you to
-be more specific if you really need to use indices to create string slices. To
-be more specific in your indexing and indicate that you want a string slice,
-rather than indexing using `[]` with a single number, you can use `[]` with a
-range to create a string slice containing particular bytes:
-
-```
-let hello = "Здравствуйте";
-
-let s = &hello[0..4];
-```
-
-Here, `s` will be a `&str` that contains the first 4 bytes of the string.
-Earlier, we mentioned that each of these characters was 2 bytes, which means
-`s` will be `Зд`.
-
-What would happen if we used `&hello[0..1]`? The answer: Rust would panic at
-runtime in the same way as if an invalid index were accessed in a vector:
-
-```
-thread 'main' panicked at 'byte index 1 is not a char boundary; it is inside 'З' (bytes 0..2) of `Здравствуйте`', src/libcore/str/mod.rs:2188:4
-```
-
-You should use ranges to create string slices with caution, because doing so
-can crash your program.
-
-### Methods for Iterating Over Strings
-
-Fortunately, you can access elements in a string in other ways.
-
-If you need to perform operations on individual Unicode scalar values, the best
-way to do so is to use the `chars` method. Calling `chars` on “नमस्ते” separates
-out and returns six values of type `char`, and you can iterate over the result
-in order to access each element:
-
-```
-for c in "नमस्ते".chars() {
-    println!("{}", c);
-}
-```
-
-This code will print the following:
-
-```
-न
-म
-स
-्
-त
-े
-```
-
-The `bytes` method returns each raw byte, which might be appropriate for your
-domain:
-
-```
-for b in "नमस्ते".bytes() {
-    println!("{}", b);
-}
-```
-
-This code will print the 18 bytes that make up this `String`:
-
-```
-224
-164
-// --snip--
-165
-135
-```
-
-But be sure to remember that valid Unicode scalar values may be made up of more
-than 1 byte.
-
-Getting grapheme clusters from strings is complex, so this functionality is not
-provided by the standard library. Crates are available on
-crates.io at *https://crates.io* if this is the functionality you need.
-
-### Strings Are Not So Simple
-
-To summarize, strings are complicated. Different programming languages make
-different choices about how to present this complexity to the programmer. Rust
-has chosen to make the correct handling of `String` data the default behavior
-for all Rust programs, which means programmers have to put more thought into
-handling UTF-8 data upfront. This trade-off exposes more of the complexity of
-strings than is apparent in other programming languages, but it prevents you
-from having to handle errors involving non-ASCII characters later in your
-development life cycle.
-
-Let’s switch to something a bit less complex: hash maps!
-
-## Storing Keys with Associated Values in Hash Maps
-
-The last of our common collections is the *hash map*. The type `HashMap`
-stores a mapping of keys of type `K` to values of type `V`. It does this via a
-*hashing function*, which determines how it places these keys and values into
-memory. Many programming languages support this kind of data structure, but
-they often use a different name, such as hash, map, object, hash table, or
-associative array, just to name a few.
-
-Hash maps are useful when you want to look up data not by using an index, as
-you can with vectors, but by using a key that can be of any type. For example,
-in a game, you could keep track of each team’s score in a hash map in which
-each key is a team’s name and the values are each team’s score. Given a team
-name, you can retrieve its score.
-
-We’ll go over the basic API of hash maps in this section, but many more goodies
-are hiding in the functions defined on `HashMap` by the standard library.
-As always, check the standard library documentation for more information.
-
-### Creating a New Hash Map
-
-You can create an empty hash map with `new` and add elements with `insert`. In
-Listing 8-20, we’re keeping track of the scores of two teams whose names are
-Blue and Yellow. The Blue team starts with 10 points, and the Yellow team
-starts with 50:
-
-```
-use std::collections::HashMap;
-
-let mut scores = HashMap::new();
-
-scores.insert(String::from("Blue"), 10);
-scores.insert(String::from("Yellow"), 50);
-```
-
-Listing 8-20: Creating a new hash map and inserting some keys and values
-
-Note that we need to first `use` the `HashMap` from the collections portion of
-the standard library. Of our three common collections, this one is the least
-often used, so it’s not included in the features brought into scope
-automatically in the prelude. Hash maps also have less support from the
-standard library; there’s no built-in macro to construct them, for example.
-
-Just like vectors, hash maps store their data on the heap. This `HashMap` has
-keys of type `String` and values of type `i32`. Like vectors, hash maps are
-homogeneous: all of the keys must have the same type, and all of the values
-must have the same type.
-
-Another way of constructing a hash map is by using the `collect` method on a
-vector of tuples, where each tuple consists of a key and its value. The
-`collect` method gathers data into a number of collection types, including
-`HashMap`. For example, if we had the team names and initial scores in two
-separate vectors, we could use the `zip` method to create a vector of tuples
-where “Blue” is paired with 10, and so forth. Then we could use the `collect`
-method to turn that vector of tuples into a hash map, as shown in Listing 8-21:
-
-```
-use std::collections::HashMap;
-
-let teams  = vec![String::from("Blue"), String::from("Yellow")];
-let initial_scores = vec![10, 50];
-
-let scores: HashMap<_, _> = teams.iter().zip(initial_scores.iter()).collect();
-```
-
-Listing 8-21: Creating a hash map from a list of teams and a list of scores
-
-The type annotation `HashMap<_, _>` is needed here because it’s possible to
-`collect` into many different data structures and Rust doesn’t know which you
-want unless you specify. For the parameters for the key and value types,
-however, we use underscores, and Rust can infer the types that the hash map
-contains based on the types of the data in the vectors.
-
-### Hash Maps and Ownership
-
-For types that implement the `Copy` trait, like `i32`, the values are copied
-into the hash map. For owned values like `String`, the values will be moved and
-the hash map will be the owner of those values, as demonstrated in Listing 8-22:
-
-```
-use std::collections::HashMap;
-
-let field_name = String::from("Favorite color");
-let field_value = String::from("Blue");
-
-let mut map = HashMap::new();
-map.insert(field_name, field_value);
-// field_name and field_value are invalid at this point, try using them and
-// see what compiler error you get!
-```
-
-Listing 8-22: Showing that keys and values are owned by the hash map once
-they’re inserted
-
-We aren’t able to use the variables `field_name` and `field_value` after
-they’ve been moved into the hash map with the call to `insert`.
-
-If we insert references to values into the hash map, the values won’t be moved
-into the hash map. The values that the references point to must be valid for at
-least as long as the hash map is valid. We’ll talk more about these issues in
-the “Validating References with Lifetimes” section in Chapter 10.
-
-### Accessing Values in a Hash Map
-
-We can get a value out of the hash map by providing its key to the `get`
-method, as shown in Listing 8-23:
-
-```
-use std::collections::HashMap;
-
-let mut scores = HashMap::new();
-
-scores.insert(String::from("Blue"), 10);
-scores.insert(String::from("Yellow"), 50);
-
-let team_name = String::from("Blue");
-let score = scores.get(&team_name);
-```
-
-Listing 8-23: Accessing the score for the Blue team stored in the hash map
-
-Here, `score` will have the value that’s associated with the Blue team, and the
-result will be `Some(&10)`. The result is wrapped in `Some` because `get`
-returns an `Option<&V>`; if there’s no value for that key in the hash map,
-`get` will return `None`. The program will need to handle the `Option` in one
-of the ways that we covered in Chapter 6.
-
-We can iterate over each key/value pair in a hash map in a similar manner as we
-do with vectors, using a `for` loop:
-
-```
-use std::collections::HashMap;
-
-let mut scores = HashMap::new();
-
-scores.insert(String::from("Blue"), 10);
-scores.insert(String::from("Yellow"), 50);
-
-for (key, value) in &scores {
-    println!("{}: {}", key, value);
-}
-```
-
-This code will print each pair in an arbitrary order:
-
-```
-Yellow: 50
-Blue: 10
-```
-
-### Updating a Hash Map
-
-Although the number of keys and values is growable, each key can only have one
-value associated with it at a time. When you want to change the data in a hash
-map, you have to decide how to handle the case when a key already has a value
-assigned. You could replace the old value with the new value, completely
-disregarding the old value. You could keep the old value and ignore the new
-value, only adding the new value if the key *doesn’t* already have a value. Or
-you could combine the old value and the new value. Let’s look at how to do each
-of these!
-
-#### Overwriting a Value
-
-If we insert a key and a value into a hash map and then insert that same key
-with a different value, the value associated with that key will be replaced.
-Even though the code in Listing 8-24 calls `insert` twice, the hash map will
-only contain one key/value pair because we’re inserting the value for the Blue
-team’s key both times:
-
-```
-use std::collections::HashMap;
-
-let mut scores = HashMap::new();
-
-scores.insert(String::from("Blue"), 10);
-scores.insert(String::from("Blue"), 25);
-
-println!("{:?}", scores);
-```
-
-Listing 8-24: Replacing a value stored with a particular key
-
-This code will print `{"Blue": 25}`. The original value of `10` has been
-overwritten.
-
-#### Only Inserting a Value If the Key Has No Value
-
-It’s common to check whether a particular key has a value and, if it doesn’t,
-insert a value for it. Hash maps have a special API for this called `entry`
-that takes the key you want to check as a parameter. The return value of the
-`entry` function is an enum called `Entry` that represents a value that might
-or might not exist. Let’s say we want to check whether the key for the Yellow
-team has a value associated with it. If it doesn’t, we want to insert the value
-50, and the same for the Blue team. Using the `entry` API, the code looks like
-Listing 8-25:
-
-```
-use std::collections::HashMap;
-
-let mut scores = HashMap::new();
-scores.insert(String::from("Blue"), 10);
-
-scores.entry(String::from("Yellow")).or_insert(50);
-scores.entry(String::from("Blue")).or_insert(50);
-
-println!("{:?}", scores);
-```
-
-Listing 8-25: Using the `entry` method to only insert if the key does not
-already have a value
-
-The `or_insert` method on `Entry` is defined to return a mutable reference to
-the value for the corresponding `Entry` key if that key exists, and if not,
-inserts the parameter as the new value for this key and returns a mutable
-reference to the new value. This technique is much cleaner than writing the
-logic ourselves and, in addition, plays more nicely with the borrow checker.
-
-Running the code in Listing 8-25 will print `{"Yellow": 50, "Blue": 10}`. The
-first call to `entry` will insert the key for the Yellow team with the value
-`50` because the Yellow team doesn’t have a value already. The second call to
-`entry` will not change the hash map because the Blue team already has the
-value `10`.
-
-#### Updating a Value Based on the Old Value
-
-Another common use case for hash maps is to look up a key’s value and then
-update it based on the old value. For instance, Listing 8-26 shows code that
-counts how many times each word appears in some text. We use a hash map with
-the words as keys and increment the value to keep track of how many times we’ve
-seen that word. If it’s the first time we’ve seen a word, we’ll first insert
-the value `0`:
-
-```
-use std::collections::HashMap;
-
-let text = "hello world wonderful world";
-
-let mut map = HashMap::new();
-
-for word in text.split_whitespace() {
-    let count = map.entry(word).or_insert(0);
-    *count += 1;
-}
-
-println!("{:?}", map);
-```
-
-Listing 8-26: Counting occurrences of words using a hash map that stores words
-and counts
-
-This code will print `{"world": 2, "hello": 1, "wonderful": 1}`. The
-`or_insert` method actually returns a mutable reference (`&mut V`) to the value
-for this key. Here we store that mutable reference in the `count` variable, so
-in order to assign to that value, we must first dereference `count` using the
-asterisk (`*`). The mutable reference goes out of scope at the end of the `for`
-loop, so all of these changes are safe and allowed by the borrowing rules.
-
-### Hashing Functions
-
-By default, `HashMap` uses a cryptographically secure hashing function that can
-provide resistance to Denial of Service (DoS) attacks. This is not the fastest
-hashing algorithm available, but the trade-off for better security that comes
-with the drop in performance is worth it. If you profile your code and find
-that the default hash function is too slow for your purposes, you can switch to
-another function by specifying a different *hasher*. A hasher is a type that
-implements the `BuildHasher` trait. We’ll talk about traits and how to
-implement them in Chapter 10. You don’t necessarily have to implement your own
-hasher from scratch; crates.io at *https://crates.io* has libraries shared by
-other Rust users that provide hashers implementing many common hashing
-algorithms.
-
-## Summary
-
-Vectors, strings, and hash maps will provide a large amount of functionality
-necessary in programs when you need to store, access, and modify data. Here are
-some exercises you should now be equipped to solve:
-
-* Given a list of integers, use a vector and return the mean (the average
-  value), median (when sorted, the value in the middle position), and mode (the
-  value that occurs most often; a hash map will be helpful here) of the list.
-* Convert strings to pig latin. The first consonant of each word is moved to
-  the end of the word and “ay” is added, so “first” becomes “irst-fay.” Words
-  that start with a vowel have “hay” added to the end instead (“apple” becomes
-  “apple-hay”). Keep in mind the details about UTF-8 encoding!
-* Using a hash map and vectors, create a text interface to allow a user to add
-  employee names to a department in a company. For example, “Add Sally to
-  Engineering” or “Add Amir to Sales.” Then let the user retrieve a list of all
-  people in a department or all people in the company by department, sorted
-  alphabetically.
-
-The standard library API documentation describes methods that vectors, strings,
-and hash maps have that will be helpful for these exercises!
-
-We’re getting into more complex programs in which operations can fail, so, it’s
-a perfect time to discuss error handling. We’ll do that next!
diff --git a/src/doc/book/second-edition/nostarch/chapter09.md b/src/doc/book/second-edition/nostarch/chapter09.md
deleted file mode 100644
index cc0823df69..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter09.md
+++ /dev/null
@@ -1,938 +0,0 @@
-
-[TOC]
-
-# Error Handling
-
-Rust’s commitment to reliability extends to error handling. Errors are a fact
-of life in software, so Rust has a number of features for handling situations
-in which something goes wrong. In many cases, Rust requires you to acknowledge
-the possibility of an error and take some action before your code will compile.
-This requirement makes your program more robust by ensuring that you’ll
-discover errors and handle them appropriately before you’ve deployed your code
-to production!
-
-Rust groups errors into two major categories: *recoverable* and *unrecoverable*
-errors. For a recoverable error, such as a file not found error, it’s
-reasonable to report the problem to the user and retry the operation.
-Unrecoverable errors are always symptoms of bugs, like trying to access a
-location beyond the end of an array.
-
-Most languages don’t distinguish between these two kinds of errors and handle
-both in the same way, using mechanisms such as exceptions. Rust doesn’t have
-exceptions. Instead, it has the type `Result` for recoverable errors and
-the `panic!` macro that stops execution when the program encounters an
-unrecoverable error. This chapter covers calling `panic!` first and then talks
-about returning `Result` values. Additionally, we’ll explore
-considerations when deciding whether to try to recover from an error or to stop
-execution.
-
-## Unrecoverable Errors with `panic!`
-
-Sometimes, bad things happen in your code, and there’s nothing you can do about
-it. In these cases, Rust has the `panic!` macro. When the `panic!` macro
-executes, your program will print a failure message, unwind and clean up the
-stack, and then quit. This most commonly occurs when a bug of some kind has
-been detected and it’s not clear to the programmer how to handle the error.
-
-> ### Unwinding the Stack or Aborting in Response to a Panic
->
-> By default, when a panic occurs, the program starts *unwinding*, which
-> means Rust walks back up the stack and cleans up the data from each function
-> it encounters. But this walking back and cleanup is a lot of work. The
-> alternative is to immediately *abort*, which ends the program without
-> cleaning up. Memory that the program was using will then need to be cleaned
-> up by the operating system. If in your project you need to make the resulting
-> binary as small as possible, you can switch from unwinding to aborting upon a
-> panic by adding `panic = 'abort'` to the appropriate `[profile]` sections in
-> your *Cargo.toml* file. For example, if you want to abort on panic in release
-> mode, add this:
->
-> ```
-> [profile.release]
-> panic = 'abort'
-> ```
-
-Let’s try calling `panic!` in a simple program:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    panic!("crash and burn");
-}
-```
-
-When you run the program, you’ll see something like this:
-
-```
-$ cargo run
-   Compiling panic v0.1.0 (file:///projects/panic)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.25 secs
-     Running `target/debug/panic`
-thread 'main' panicked at 'crash and burn', src/main.rs:2:4
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-```
-
-The call to `panic!` causes the error message contained in the last three
-lines. The first line shows our panic message and the place in our source code
-where the panic occurred: *src/main.rs:2:4* indicates that it’s the second
-line, fourth character of our *src/main.rs* file.
-
-In this case, the line indicated is part of our code, and if we go to that
-line, we see the `panic!` macro call. In other cases, the `panic!` call might
-be in code that our code calls, and the filename and line number reported by
-the error message will be someone else’s code where the `panic!` macro is
-called, not the line of our code that eventually led to the `panic!` call. We
-can use the backtrace of the functions the `panic!` call came from to figure
-out the part of our code that is causing the problem. We’ll discuss what a
-backtrace is in more detail next.
-
-### Using a `panic!` Backtrace
-
-Let’s look at another example to see what it’s like when a `panic!` call comes
-from a library because of a bug in our code instead of from our code calling
-the macro directly. Listing 9-1 has some code that attempts to access an
-element by index in a vector:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let v = vec![1, 2, 3];
-
-    v[99];
-}
-```
-
-Listing 9-1: Attempting to access an element beyond the end of a vector, which
-will cause a `panic!`
-
-Here, we’re attempting to access the hundredth element of our vector (which is
-at index 99 because indexing starts at zero), but it has only three elements.
-In this situation, Rust will panic. Using `[]` is supposed to return an
-element, but if you pass an invalid index, there’s no element that Rust could
-return here that would be correct.
-
-Other languages, like C, will attempt to give you exactly what you asked for in
-this situation, even though it isn’t what you want: you’ll get whatever is at
-the location in memory that would correspond to that element in the vector,
-even though the memory doesn’t belong to the vector. This is called a *buffer
-overread* and can lead to security vulnerabilities if an attacker is able to
-manipulate the index in such a way as to read data they shouldn’t be allowed to
-that is stored after the array.
-
-To protect your program from this sort of vulnerability, if you try to read an
-element at an index that doesn’t exist, Rust will stop execution and refuse to
-continue. Let’s try it and see:
-
-```
-$ cargo run
-   Compiling panic v0.1.0 (file:///projects/panic)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.27 secs
-     Running `target/debug/panic`
-thread 'main' panicked at 'index out of bounds: the len is 3 but the index is
-99', /checkout/src/liballoc/vec.rs:1555:10
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-```
-
-This error points at a file we didn’t write, *vec.rs*. That’s the
-implementation of `Vec` in the standard library. The code that gets run when
-we use `[]` on our vector `v` is in *vec.rs*, and that is where the `panic!` is
-actually happening.
-
-The next note line tells us that we can set the `RUST_BACKTRACE` environment
-variable to get a backtrace of exactly what happened to cause the error. A
-*backtrace* is a list of all the functions that have been called to get to this
-point. Backtraces in Rust work as they do in other languages: the key to
-reading the backtrace is to start from the top and read until you see files you
-wrote. That’s the spot where the problem originated. The lines above the lines
-mentioning your files are code that your code called; the lines below are code
-that called your code. These lines might include core Rust code, standard
-library code, or crates that you’re using. Let’s try getting a backtrace by
-setting the `RUST_BACKTRACE` environment variable to any value except 0.
-Listing 9-2 shows output similar to what you’ll see:
-
-```
-$ RUST_BACKTRACE=1 cargo run
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target/debug/panic`
-thread 'main' panicked at 'index out of bounds: the len is 3 but the index is
-99', /checkout/src/liballoc/vec.rs:1555:10
-stack backtrace:
-   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
-             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
-   1: std::sys_common::backtrace::_print
-             at /checkout/src/libstd/sys_common/backtrace.rs:71
-   2: std::panicking::default_hook::{{closure}}
-             at /checkout/src/libstd/sys_common/backtrace.rs:60
-             at /checkout/src/libstd/panicking.rs:381
-   3: std::panicking::default_hook
-             at /checkout/src/libstd/panicking.rs:397
-   4: std::panicking::rust_panic_with_hook
-             at /checkout/src/libstd/panicking.rs:611
-   5: std::panicking::begin_panic
-             at /checkout/src/libstd/panicking.rs:572
-   6: std::panicking::begin_panic_fmt
-             at /checkout/src/libstd/panicking.rs:522
-   7: rust_begin_unwind
-             at /checkout/src/libstd/panicking.rs:498
-   8: core::panicking::panic_fmt
-             at /checkout/src/libcore/panicking.rs:71
-   9: core::panicking::panic_bounds_check
-             at /checkout/src/libcore/panicking.rs:58
-  10:  as core::ops::index::Index>::index
-             at /checkout/src/liballoc/vec.rs:1555
-  11: panic::main
-             at src/main.rs:4
-  12: __rust_maybe_catch_panic
-             at /checkout/src/libpanic_unwind/lib.rs:99
-  13: std::rt::lang_start
-             at /checkout/src/libstd/panicking.rs:459
-             at /checkout/src/libstd/panic.rs:361
-             at /checkout/src/libstd/rt.rs:61
-  14: main
-  15: __libc_start_main
-  16: 
-```
-
-Listing 9-2: The backtrace generated by a call to `panic!` displayed when the
-environment variable `RUST_BACKTRACE` is set
-
-That’s a lot of output! The exact output you see might be different depending
-on your operating system and Rust version. In order to get backtraces with this
-information, debug symbols must be enabled. Debug symbols are enabled by
-default when using `cargo build` or `cargo run` without the `--release` flag,
-as we have here.
-
-In the output in Listing 9-2, line 11 of the backtrace points to the line in
-our project that’s causing the problem: line 4 of *src/main.rs*. If we don’t
-want our program to panic, the location pointed to by the first line mentioning
-a file we wrote is where we should start investigating. In Listing 9-1, where
-we deliberately wrote code that would panic in order to demonstrate how to use
-backtraces, the way to fix the panic is to not request an element at index 99
-from a vector that only contains 3 items. When your code panics in the future,
-you’ll need to figure out what action the code is taking with what values to
-cause the panic and what the code should do instead.
-
-We’ll come back to `panic!` and when we should and should not use `panic!` to
-handle error conditions in the “To `panic!` or Not to `panic!`” section later
-in this chapter. Next, we’ll look at how to recover from an error using
-`Result`.
-
-## Recoverable Errors with `Result`
-
-Most errors aren’t serious enough to require the program to stop entirely.
-Sometimes, when a function fails, it’s for a reason that you can easily
-interpret and respond to. For example, if you try to open a file and that
-operation fails because the file doesn’t exist, you might want to create the
-file instead of terminating the process.
-
-Recall from “Handling Potential Failure with the `Result` Type” in Chapter 2
-that the `Result` enum is defined as having two variants, `Ok` and `Err`, as
-follows:
-
-```
-enum Result {
-    Ok(T),
-    Err(E),
-}
-```
-
-The `T` and `E` are generic type parameters: we’ll discuss generics in more
-detail in Chapter 10. What you need to know right now is that `T` represents
-the type of the value that will be returned in a success case within the `Ok`
-variant, and `E` represents the type of the error that will be returned in a
-failure case within the `Err` variant. Because `Result` has these generic type
-parameters, we can use the `Result` type and the functions that the standard
-library has defined on it in many different situations where the successful
-value and error value we want to return may differ.
-
-Let’s call a function that returns a `Result` value because the function could
-fail. In Listing 9-3 we try to open a file:
-
-Filename: src/main.rs
-
-```
-use std::fs::File;
-
-fn main() {
-    let f = File::open("hello.txt");
-}
-```
-
-Listing 9-3: Opening a file
-
-How do we know `File::open` returns a `Result`? We could look at the standard
-library API documentation, or we could ask the compiler! If we give `f` a type
-annotation that we know is *not* the return type of the function and then try
-to compile the code, the compiler will tell us that the types don’t match. The
-error message will then tell us what the type of `f` *is*. Let’s try it! We
-know that the return type of `File::open` isn’t of type `u32`, so let’s change
-the `let f` statement to this:
-
-```
-let f: u32 = File::open("hello.txt");
-```
-
-Attempting to compile now gives us the following output:
-
-```
-error[E0308]: mismatched types
- --> src/main.rs:4:18
-  |
-4 |     let f: u32 = File::open("hello.txt");
-  |                  ^^^^^^^^^^^^^^^^^^^^^^^ expected u32, found enum
-`std::result::Result`
-  |
-  = note: expected type `u32`
-             found type `std::result::Result`
-```
-
-This tells us the return type of the `File::open` function is a `Result`.
-The generic parameter `T` has been filled in here with the type of the success
-value, `std::fs::File`, which is a file handle. The type of `E` used in the
-error value is `std::io::Error`.
-
-This return type means the call to `File::open` might succeed and return a file
-handle that we can read from or write to. The function call also might fail:
-for example, the file might not exist, or we might not have permission to
-access the file. The `File::open` function needs to have a way to tell us
-whether it succeeded or failed and at the same time give us either the file
-handle or error information. This information is exactly what the `Result` enum
-conveys.
-
-In the case where `File::open` succeeds, the value in the variable `f` will be
-an instance of `Ok` that contains a file handle. In the case where it fails,
-the value in `f` will be an instance of `Err` that contains more information
-about the kind of error that happened.
-
-We need to add to the code in Listing 9-3 to take different actions depending
-on the value `File::open` returns. Listing 9-4 shows one way to handle the
-`Result` using a basic tool, the `match` expression that we discussed in
-Chapter 6.
-
-Filename: src/main.rs
-
-```
-use std::fs::File;
-
-fn main() {
-    let f = File::open("hello.txt");
-
-    let f = match f {
-        Ok(file) => file,
-        Err(error) => {
-            panic!("There was a problem opening the file: {:?}", error)
-        },
-    };
-}
-```
-
-Listing 9-4: Using a `match` expression to handle the `Result` variants that
-might be returned
-
-Note that, like the `Option` enum, the `Result` enum and its variants have been
-imported in the prelude, so we don’t need to specify `Result::` before the `Ok`
-and `Err` variants in the `match` arms.
-
-Here we tell Rust that when the result is `Ok`, return the inner `file` value
-out of the `Ok` variant, and we then assign that file handle value to the
-variable `f`. After the `match`, we can use the file handle for reading or
-writing.
-
-The other arm of the `match` handles the case where we get an `Err` value from
-`File::open`. In this example, we’ve chosen to call the `panic!` macro. If
-there’s no file named *hello.txt* in our current directory and we run this
-code, we’ll see the following output from the `panic!` macro:
-
-```
-thread 'main' panicked at 'There was a problem opening the file: Error { repr:
-Os { code: 2, message: "No such file or directory" } }', src/main.rs:9:12
-```
-
-As usual, this output tells us exactly what has gone wrong.
-
-### Matching on Different Errors
-
-The code in Listing 9-4 will `panic!` no matter why `File::open` failed. What
-we want to do instead is take different actions for different failure reasons:
-if `File::open` failed because the file doesn’t exist, we want to create the
-file and return the handle to the new file. If `File::open` failed for any
-other reason—for example, because we didn’t have permission to open the file—we
-still want the code to `panic!` in the same way as it did in Listing 9-4. Look
-at Listing 9-5, which adds another arm to the `match`:
-
-Filename: src/main.rs
-
-
-
-```
-use std::fs::File;
-use std::io::ErrorKind;
-
-fn main() {
-    let f = File::open("hello.txt");
-
-    let f = match f {
-        Ok(file) => file,
-        Err(ref error) if error.kind() == ErrorKind::NotFound => {
-            match File::create("hello.txt") {
-                Ok(fc) => fc,
-                Err(e) => {
-                    panic!(
-                        "Tried to create file but there was a problem: {:?}",
-                        e
-                    )
-                },
-            }
-        },
-        Err(error) => {
-            panic!(
-                "There was a problem opening the file: {:?}",
-                error
-            )
-        },
-    };
-}
-```
-
-Listing 9-5: Handling different kinds of errors in different ways
-
-The type of the value that `File::open` returns inside the `Err` variant is
-`io::Error`, which is a struct provided by the standard library. This struct
-has a method `kind` that we can call to get an `io::ErrorKind` value. The enum
-`io::ErrorKind` is provided by the standard library and has variants
-representing the different kinds of errors that might result from an `io`
-operation. The variant we want to use is `ErrorKind::NotFound`, which indicates
-the file we’re trying to open doesn’t exist yet.
-
-The condition `if error.kind() == ErrorKind::NotFound` is called a *match
-guard*: it’s an extra condition on a `match` arm that further refines the arm’s
-pattern. This condition must be true for that arm’s code to be run; otherwise,
-the pattern matching will move on to consider the next arm in the `match`. The
-`ref` in the pattern is needed so `error` is not moved into the guard condition
-but is merely referenced by it. The reason you use `ref` to create a reference
-in a pattern instead of `&` will be covered in detail in Chapter 18. In short,
-in the context of a pattern, `&` matches a reference and gives you its value,
-but `ref` matches a value and gives you a reference to it.
-
-The condition we want to check in the match guard is whether the value returned
-by `error.kind()` is the `NotFound` variant of the `ErrorKind` enum. If it is,
-we try to create the file with `File::create`. However, because `File::create`
-could also fail, we need to add an inner `match` statement as well. When the
-file can’t be opened, a different error message will be printed. The last arm
-of the outer `match` stays the same so the program panics on any error besides
-the missing file error.
-
-### Shortcuts for Panic on Error: `unwrap` and `expect`
-
-Using `match` works well enough, but it can be a bit verbose and doesn’t always
-communicate intent well. The `Result` type has many helper methods
-defined on it to do various tasks. One of those methods, called `unwrap`, is a
-shortcut method that is implemented just like the `match` statement we wrote in
-Listing 9-4. If the `Result` value is the `Ok` variant, `unwrap` will return
-the value inside the `Ok`. If the `Result` is the `Err` variant, `unwrap` will
-call the `panic!` macro for us. Here is an example of `unwrap` in action:
-
-Filename: src/main.rs
-
-```
-use std::fs::File;
-
-fn main() {
-    let f = File::open("hello.txt").unwrap();
-}
-```
-
-If we run this code without a *hello.txt* file, we’ll see an error message from
-the `panic!` call that the `unwrap` method makes:
-
-```
-thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error {
-repr: Os { code: 2, message: "No such file or directory" } }',
-src/libcore/result.rs:906:4
-```
-
-Another method, `expect`, which is similar to `unwrap`, lets us also choose the
-`panic!` error message. Using `expect` instead of `unwrap` and providing good
-error messages can convey your intent and make tracking down the source of a
-panic easier. The syntax of `expect` looks like this:
-
-Filename: src/main.rs
-
-```
-use std::fs::File;
-
-fn main() {
-    let f = File::open("hello.txt").expect("Failed to open hello.txt");
-}
-```
-
-We use `expect` in the same way as `unwrap`: to return the file handle or call
-the `panic!` macro. The error message used by `expect` in its call to `panic!`
-will be the parameter that we pass to `expect`, rather than the default
-`panic!` message that `unwrap` uses. Here’s what it looks like:
-
-```
-thread 'main' panicked at 'Failed to open hello.txt: Error { repr: Os { code:
-2, message: "No such file or directory" } }', src/libcore/result.rs:906:4
-```
-
-Because this error message starts with the text we specified, `Failed to open
-hello.txt`, it will be easier to find where in the code this error message is
-coming from. If we use `unwrap` in multiple places, it can take more time to
-figure out exactly which `unwrap` is causing the panic because all `unwrap`
-calls that panic print the same message.
-
-### Propagating Errors
-
-When you’re writing a function whose implementation calls something that might
-fail, instead of handling the error within this function, you can return the
-error to the calling code so that it can decide what to do. This is known as
-*propagating* the error and gives more control to the calling code, where there
-might be more information or logic that dictates how the error should be
-handled than what you have available in the context of your code.
-
-For example, Listing 9-6 shows a function that reads a username from a file. If
-the file doesn’t exist or can’t be read, this function will return those errors
-to the code that called this function:
-
-Filename: src/main.rs
-
-```
-use std::io;
-use std::io::Read;
-use std::fs::File;
-
-fn read_username_from_file() -> Result {
-    let f = File::open("hello.txt");
-
-    let mut f = match f {
-        Ok(file) => file,
-        Err(e) => return Err(e),
-    };
-
-    let mut s = String::new();
-
-    match f.read_to_string(&mut s) {
-        Ok(_) => Ok(s),
-        Err(e) => Err(e),
-    }
-}
-```
-
-Listing 9-6: A function that returns errors to the calling code using `match`
-
-Let’s look at the return type of the function first: `Result`. This means the function is returning a value of the type
-`Result` where the generic parameter `T` has been filled in with the
-concrete type `String`, and the generic type `E` has been filled in with the
-concrete type `io::Error`. If this function succeeds without any problems, the
-code that calls this function will receive an `Ok` value that holds a
-`String`—the username that this function read from the file. If this function
-encounters any problems, the code that calls this function will receive an
-`Err` value that holds an instance of `io::Error` that contains more
-information about what the problems were. We chose `io::Error` as the return
-type of this function because that happens to be the type of the error value
-returned from both of the operations we’re calling in this function’s body that
-might fail: the `File::open` function and the `read_to_string` method.
-
-The body of the function starts by calling the `File::open` function. Then we
-handle the `Result` value returned with a `match` similar to the `match` in
-Listing 9-4, only instead of calling `panic!` in the `Err` case, we return
-early from this function and pass the error value from `File::open` back to the
-calling code as this function’s error value. If `File::open` succeeds, we store
-the file handle in the variable `f` and continue.
-
-Then we create a new `String` in variable `s` and call the `read_to_string`
-method on the file handle in `f` to read the contents of the file into `s`. The
-`read_to_string` method also returns a `Result` because it might fail, even
-though `File::open` succeeded. So we need another `match` to handle that
-`Result`: if `read_to_string` succeeds, then our function has succeeded, and we
-return the username from the file that’s now in `s` wrapped in an `Ok`. If
-`read_to_string` fails, we return the error value in the same way that we
-returned the error value in the `match` that handled the return value of
-`File::open`. However, we don’t need to explicitly say `return`, because this
-is the last expression in the function.
-
-The code that calls this code will then handle getting either an `Ok` value
-that contains a username or an `Err` value that contains an `io::Error`. We
-don’t know what the calling code will do with those values. If the calling code
-gets an `Err` value, it could call `panic!` and crash the program, use a
-default username, or look up the username from somewhere other than a file, for
-example. We don’t have enough information on what the calling code is actually
-trying to do, so we propagate all the success or error information upward for
-it to handle appropriately.
-
-This pattern of propagating errors is so common in Rust that Rust provides the
-question mark operator `?` to make this easier.
-
-#### A Shortcut for Propagating Errors: the `?` Operator
-
-Listing 9-7 shows an implementation of `read_username_from_file` that has the
-same functionality as it had in Listing 9-6, but this implementation uses the
-question mark operator:
-
-Filename: src/main.rs
-
-```
-use std::io;
-use std::io::Read;
-use std::fs::File;
-
-fn read_username_from_file() -> Result {
-    let mut f = File::open("hello.txt")?;
-    let mut s = String::new();
-    f.read_to_string(&mut s)?;
-    Ok(s)
-}
-```
-
-Listing 9-7: A function that returns errors to the calling code using `?`
-
-The `?` placed after a `Result` value is defined to work in almost the same way
-as the `match` expressions we defined to handle the `Result` values in Listing
-9-6. If the value of the `Result` is an `Ok`, the value inside the `Ok` will
-get returned from this expression, and the program will continue. If the value
-is an `Err`, the value inside the `Err` will be returned from the whole
-function as if we had used the `return` keyword so the error value gets
-propagated to the calling code.
-
-There is a difference between what the `match` expression from Listing 9-6 and
-`?` do: error values used with `?` go through the `from` function, defined in
-the `From` trait in the standard library, which is used to convert errors from
-one type into another. When `?` calls the `from` function, the error type
-received is converted into the error type defined in the return type of the
-current function. This is useful when a function returns one error type to
-represent all the ways a function might fail, even if parts might fail for many
-different reasons. As long as each error type implements the `from` function to
-define how to convert itself to the returned error type, `?` takes care of the
-conversion automatically.
-
-In the context of Listing 9-7, the `?` at the end of the `File::open` call will
-return the value inside an `Ok` to the variable `f`. If an error occurs, `?`
-will return early out of the whole function and give any `Err` value to the
-calling code. The same thing applies to the `?` at the end of the
-`read_to_string` call.
-
-The `?` operator eliminates a lot of boilerplate and makes this function’s
-implementation simpler. We could even shorten this code further by chaining
-method calls immediately after the `?`, as shown in Listing 9-8:
-
-Filename: src/main.rs
-
-```
-use std::io;
-use std::io::Read;
-use std::fs::File;
-
-fn read_username_from_file() -> Result {
-    let mut s = String::new();
-
-    File::open("hello.txt")?.read_to_string(&mut s)?;
-
-    Ok(s)
-}
-```
-
-Listing 9-8: Chaining method calls after `?`
-
-We’ve moved the creation of the new `String` in `s` to the beginning of the
-function; that part hasn’t changed. Instead of creating a variable `f`, we’ve
-chained the call to `read_to_string` directly onto the result of
-`File::open("hello.txt")?`. We still have a `?` at the end of the
-`read_to_string` call, and we still return an `Ok` value containing the
-username in `s` when both `File::open` and `read_to_string` succeed rather than
-returning errors. The functionality is again the same as in Listing 9-6 and
-Listing 9-7; this is just a different, more ergonomic way to write it.
-
-#### The `?` Operator Can Only Be Used in Functions That Return `Result`
-
-The `?` operator can only be used in functions that have a return type of
-`Result`, because it is defined to work in the same way as the `match`
-expression we defined in Listing 9-6. The part of the `match` that requires a
-return type of `Result` is `return Err(e)`, so the return type of the function
-must be a `Result` to be compatible with this `return`.
-
-Let’s look at what happens if we use `?` in the `main` function, which you’ll
-recall has a return type of `()`:
-
-```
-use std::fs::File;
-
-fn main() {
-    let f = File::open("hello.txt")?;
-}
-```
-
-When we compile this code, we get the following error message:
-
-```
-error[E0277]: the trait bound `(): std::ops::Try` is not satisfied
- --> src/main.rs:4:13
-  |
-4 |     let f = File::open("hello.txt")?;
-  |             ------------------------
-  |             |
-  |             the `?` operator can only be used in a function that returns
-  `Result` (or another type that implements `std::ops::Try`)
-  |             in this macro invocation
-  |
-  = help: the trait `std::ops::Try` is not implemented for `()`
-  = note: required by `std::ops::Try::from_error`
-```
-
-This error points out that we’re only allowed to use `?` in a function that
-returns `Result`. In functions that don’t return `Result`, when you call other
-functions that return `Result`, you’ll need to use a `match` or one of the
-`Result` methods to handle the `Result` instead of using `?` to potentially
-propagate the error to the calling code.
-
-Now that we’ve discussed the details of calling `panic!` or returning `Result`,
-let’s return to the topic of how to decide which is appropriate to use in which
-cases.
-
-## To `panic!` or Not to `panic!`
-
-So how do you decide when you should call `panic!` and when you should return
-`Result`? When code panics, there’s no way to recover. You could call `panic!`
-for any error situation, whether there’s a possible way to recover or not, but
-then you’re making the decision on behalf of the code calling your code that a
-situation is unrecoverable. When you choose to return a `Result` value, you
-give the calling code options rather than making the decision for it. The
-calling code could choose to attempt to recover in a way that’s appropriate for
-its situation, or it could decide that an `Err` value in this case is
-unrecoverable, so it can call `panic!` and turn your recoverable error into an
-unrecoverable one. Therefore, returning `Result` is a good default choice when
-you’re defining a function that might fail.
-
-In rare situations, it’s more appropriate to write code that panics instead of
-returning a `Result`. Let’s explore why it’s appropriate to panic in examples,
-prototype code, and tests. Then we’ll discuss situations in which the compiler
-can’t tell that failure is impossible, but you as a human can. The chapter will
-conclude with some general guidelines on how to decide whether to panic in
-library code.
-
-### Examples, Prototype Code, and Tests
-
-When you’re writing an example to illustrate some concept, having robust
-error-handling code in the example as well can make the example less clear. In
-examples, it’s understood that a call to a method like `unwrap` that could
-panic is meant as a placeholder for the way you’d want your application to
-handle errors, which can differ based on what the rest of your code is doing.
-
-Similarly, the `unwrap` and `expect` methods are very handy when prototyping,
-before you’re ready to decide how to handle errors. They leave clear markers in
-your code for when you’re ready to make your program more robust.
-
-If a method call fails in a test, you’d want the whole test to fail, even if
-that method isn’t the functionality under test. Because `panic!` is how a test
-is marked as a failure, calling `unwrap` or `expect` is exactly what should
-happen.
-
-### Cases in Which You Have More Information Than the Compiler
-
-It would also be appropriate to call `unwrap` when you have some other logic
-that ensures the `Result` will have an `Ok` value, but the logic isn’t
-something the compiler understands. You’ll still have a `Result` value that you
-need to handle: whatever operation you’re calling still has the possibility of
-failing in general, even though it’s logically impossible in your particular
-situation. If you can ensure by manually inspecting the code that you’ll never
-have an `Err` variant, it’s perfectly acceptable to call `unwrap`. Here’s an
-example:
-
-```
-use std::net::IpAddr;
-
-let home: IpAddr = "127.0.0.1".parse().unwrap();
-```
-
-We’re creating an `IpAddr` instance by parsing a hardcoded string. We can see
-that `127.0.0.1` is a valid IP address, so it’s acceptable to use `unwrap`
-here. However, having a hardcoded, valid string doesn’t change the return type
-of the `parse` method: we still get a `Result` value, and the compiler will
-still make us handle the `Result` as if the `Err` variant is a possibility
-because the compiler isn’t smart enough to see that this string is always a
-valid IP address. If the IP address string came from a user rather than being
-hardcoded into the program and therefore *did* have a possibility of failure,
-we’d definitely want to handle the `Result` in a more robust way instead.
-
-### Guidelines for Error Handling
-
-It’s advisable to have your code panic when it’s possible that your code
-could end up in a bad state. In this context, a *bad state* is when some
-assumption, guarantee, contract, or invariant has been broken, such as when
-invalid values, contradictory values, or missing values are passed to your
-code—plus one or more of the following:
-
-* The bad state is not something that’s *expected* to happen occasionally.
-* Your code after this point needs to rely on not being in this bad state.
-* There’s not a good way to encode this information in the types you use.
-
-If someone calls your code and passes in values that don’t make sense, the best
-choice might be to call `panic!` and alert the person using your library to the
-bug in their code so they can fix it during development. Similarly, `panic!` is
-often appropriate if you’re calling external code that is out of your control
-and it returns an invalid state that you have no way of fixing.
-
-When a bad state is reached, but it’s expected to happen no matter how well you
-write your code, it’s still more appropriate to return a `Result` rather than
-to make a `panic!` call. Examples include a parser being given malformed data
-or an HTTP request returning a status that indicates you have hit a rate limit.
-In these cases, you should indicate that failure is an expected possibility by
-returning a `Result` to propagate these bad states upward so the calling code
-can decide how to handle the problem. To call `panic!` wouldn’t be the best way
-to handle these cases.
-
-When your code performs operations on values, your code should verify the
-values are valid first and panic if the values aren’t valid. This is mostly for
-safety reasons: attempting to operate on invalid data can expose your code to
-vulnerabilities. This is the main reason the standard library will call
-`panic!` if you attempt an out-of-bounds memory access: trying to access memory
-that doesn’t belong to the current data structure is a common security problem.
-Functions often have *contracts*: their behavior is only guaranteed if the
-inputs meet particular requirements. Panicking when the contract is violated
-makes sense because a contract violation always indicates a caller-side bug and
-it’s not a kind of error you want the calling code to have to explicitly
-handle. In fact, there’s no reasonable way for calling code to recover; the
-calling *programmers* need to fix the code. Contracts for a function,
-especially when a violation will cause a panic, should be explained in the API
-documentation for the function.
-
-However, having lots of error checks in all of your functions would be verbose
-and annoying. Fortunately, you can use Rust’s type system (and thus the type
-checking the compiler does) to do many of the checks for you. If your function
-has a particular type as a parameter, you can proceed with your code’s logic
-knowing that the compiler has already ensured you have a valid value. For
-example, if you have a type rather than an `Option`, your program expects to
-have *something* rather than *nothing*. Your code then doesn’t have to handle
-two cases for the `Some` and `None` variants: it will only have one case for
-definitely having a value. Code trying to pass nothing to your function won’t
-even compile, so your function doesn’t have to check for that case at runtime.
-Another example is using an unsigned integer type such as `u32`, which ensures
-the parameter is never negative.
-
-Let’s take the idea of using Rust’s type system to ensure we have a valid value
-one step further and look at creating a custom type for validation. Recall the
-guessing game in Chapter 2 in which our code asked the user to guess a number
-between 1 and 100. We never validated that the user’s guess was between those
-numbers before checking it against our secret number; we only validated that
-the guess was positive. In this case, the consequences were not very dire: our
-output of “Too high” or “Too low” would still be correct. But it would be a
-useful enhancement to guide the user toward valid guesses and have different
-behavior when a user guesses a number that’s out of range versus when a user
-types, for example, letters instead.
-
-One way to do this would be to parse the guess as an `i32` instead of only a
-`u32` to allow potentially negative numbers, and then add a check for the
-number being in range, like so:
-
-```
-loop {
-    // --snip--
-
-    let guess: i32 = match guess.trim().parse() {
-        Ok(num) => num,
-        Err(_) => continue,
-    };
-
-    if guess < 1 || guess > 100 {
-        println!("The secret number will be between 1 and 100.");
-        continue;
-    }
-
-    match guess.cmp(&secret_number) {
-    // --snip--
-}
-```
-
-The `if` expression checks whether our value is out of range, tells the user
-about the problem, and calls `continue` to start the next iteration of the loop
-and ask for another guess. After the `if` expression, we can proceed with the
-comparisons between `guess` and the secret number knowing that `guess` is
-between 1 and 100.
-
-However, this is not an ideal solution: if it was absolutely critical that the
-program only operated on values between 1 and 100, and it had many functions
-with this requirement, having a check like this in every function would be
-tedious (and might impact performance).
-
-Instead, we can make a new type and put the validations in a function to create
-an instance of the type rather than repeating the validations everywhere. That
-way, it’s safe for functions to use the new type in their signatures and
-confidently use the values they receive. Listing 9-9 shows one way to define a
-`Guess` type that will only create an instance of `Guess` if the `new` function
-receives a value between 1 and 100:
-
-```
-pub struct Guess {
-    value: u32,
-}
-
-impl Guess {
-    pub fn new(value: u32) -> Guess {
-        if value < 1 || value > 100 {
-            panic!("Guess value must be between 1 and 100, got {}.", value);
-        }
-
-        Guess {
-            value
-        }
-    }
-
-    pub fn value(&self) -> u32 {
-        self.value
-    }
-}
-```
-
-Listing 9-9: A `Guess` type that will only continue with values between 1 and
-100
-
-First, we define a struct named `Guess` that has a field named `value` that
-holds a `u32`. This is where the number will be stored.
-
-Then we implement an associated function named `new` on `Guess` that creates
-instances of `Guess` values. The `new` function is defined to have one
-parameter named `value` of type `u32` and to return a `Guess`. The code in the
-body of the `new` function tests `value` to make sure it’s between 1 and 100.
-If `value` doesn’t pass this test, we make a `panic!` call, which will alert
-the programmer who is writing the calling code that they have a bug they need
-to fix, because creating a `Guess` with a `value` outside this range would
-violate the contract that `Guess::new` is relying on. The conditions in which
-`Guess::new` might panic should be discussed in its public-facing API
-documentation; we’ll cover documentation conventions indicating the possibility
-of a `panic!` in the API documentation that you create in Chapter 14. If
-`value` does pass the test, we create a new `Guess` with its `value` field set
-to the `value` parameter and return the `Guess`.
-
-Next, we implement a method named `value` that borrows `self`, doesn’t have any
-other parameters, and returns a `u32`. This kind of method is sometimes called
-a *getter*, because its purpose is to get some data from its fields and return
-it. This public method is necessary because the `value` field of the `Guess`
-struct is private. It’s important that the `value` field be private so code
-using the `Guess` struct is not allowed to set `value` directly: code outside
-the module *must* use the `Guess::new` function to create an instance of
-`Guess`, thereby ensuring there’s no way for a `Guess` to have a `value` that
-hasn’t been checked by the conditions in the `Guess::new` function.
-
-A function that has a parameter or returns only numbers between 1 and 100 could
-then declare in its signature that it takes or returns a `Guess` rather than a
-`u32` and wouldn’t need to do any additional checks in its body.
-
-## Summary
-
-Rust’s error handling features are designed to help you write more robust code.
-The `panic!` macro signals that your program is in a state it can’t handle and
-lets you tell the process to stop instead of trying to proceed with invalid or
-incorrect values. The `Result` enum uses Rust’s type system to indicate that
-operations might fail in a way that your code could recover from. You can use
-`Result` to tell code that calls your code that it needs to handle potential
-success or failure as well. Using `panic!` and `Result` in the appropriate
-situations will make your code more reliable in the face of inevitable problems.
-
-Now that you’ve seen useful ways that the standard library uses generics with
-the `Option` and `Result` enums, we’ll talk about how generics work and how you
-can use them in your code.
-
diff --git a/src/doc/book/second-edition/nostarch/chapter10.md b/src/doc/book/second-edition/nostarch/chapter10.md
deleted file mode 100644
index 3883a089b7..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter10.md
+++ /dev/null
@@ -1,1882 +0,0 @@
-
-[TOC]
-
-# Generic Types, Traits, and Lifetimes
-
-Every programming language has tools for effectively handling the duplication
-of concepts. In Rust, one such tool is *generics*. Generics are abstract
-stand-ins for concrete types or other properties. When we’re writing code, we
-can express the behavior of generics or how they relate to other generics
-without knowing what will be in their place when compiling and running the code.
-
-Similar to the way a function takes parameters with unknown values to run the
-same code on multiple concrete values, functions can take parameters of some
-generic type instead of a concrete type, like `i32` or `String`. In fact, we’ve
-already used generics in Chapter 6 with `Option`, Chapter 8 with `Vec`
-and `HashMap`, and Chapter 9 with `Result`. In this chapter, you’ll
-explore how to define your own types, functions, and methods with generics!
-
-First, we’ll review how to extract a function to reduce code duplication. Next,
-we’ll use the same technique to make a generic function from two functions that
-only differ in the types of their parameters. We’ll also explain how to use
-generic types in struct and enum definitions.
-
-Then you’ll learn how to use *traits* to define behavior in a generic way. You
-can then combine traits with generic types to constrain a generic type to only
-those types that have a particular behavior, as opposed to just any type.
-
-Finally, we’ll discuss *lifetimes*, a variety of generics that give the
-compiler information about how references relate to each other. Lifetimes allow
-us to borrow values in many situations while still enabling the compiler to
-check that the references are valid.
-
-## Removing Duplication by Extracting a Function
-
-Before diving into generics syntax, let’s first look at how to remove
-duplication that doesn’t involve generic types by extracting a function. Then
-we’ll apply this technique to extract a generic function! In the same way that
-you recognize duplicated code to extract into a function, you’ll start to
-recognize duplicated code that can use generics.
-
-Consider a short program that finds the largest number in a list, as shown in
-Listing 10-1:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let number_list = vec![34, 50, 25, 100, 65];
-
-    let mut largest = number_list[0];
-
-    for number in number_list {
-        if number > largest {
-            largest = number;
-        }
-    }
-
-    println!("The largest number is {}", largest);
-}
-```
-
-Listing 10-1: Code to find the largest number in a list of numbers
-
-This code stores a list of integers in the variable `number_list` and places
-the first number in the list in a variable named `largest`. Then it iterates
-through all the numbers in the list, and if the current number is greater than
-the number stored in `largest`, it replaces the number in that variable.
-However, if the current number is less than the largest number seen so far, the
-variable doesn’t change and the code moves on to the next number in the list.
-After considering all the numbers in the list, `largest` should hold the
-largest number, which in this case is 100.
-
-To find the largest number in two different lists of numbers, we can duplicate
-the code in Listing 10-1 and use the same logic at two different places in the
-program, as shown in Listing 10-2:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let number_list = vec![34, 50, 25, 100, 65];
-
-    let mut largest = number_list[0];
-
-    for number in number_list {
-        if number > largest {
-            largest = number;
-        }
-    }
-
-    println!("The largest number is {}", largest);
-
-    let number_list = vec![102, 34, 6000, 89, 54, 2, 43, 8];
-
-    let mut largest = number_list[0];
-
-    for number in number_list {
-        if number > largest {
-            largest = number;
-        }
-    }
-
-    println!("The largest number is {}", largest);
-}
-```
-
-Listing 10-2: Code to find the largest number in *two* lists of numbers
-
-Although this code works, duplicating code is tedious and error prone. We also
-have to update the code in multiple places to change it.
-
-To eliminate this duplication, we can create an abstraction by defining a
-function that operates on any list of integers given to it in a parameter. This
-solution makes our code clearer and lets us express the concept of finding the
-largest number in a list abstractly.
-
-In Listing 10-3, we extracted the code that finds the largest number into a
-function named `largest`. Unlike the code in Listing 10-1, which can find the
-largest number in only one particular list, this program can find the largest
-number in two different lists:
-
-Filename: src/main.rs
-
-```
-fn largest(list: &[i32]) -> i32 {
-    let mut largest = list[0];
-
-    for &item in list.iter() {
-        if item > largest {
-            largest = item;
-        }
-    }
-
-    largest
-}
-
-fn main() {
-    let number_list = vec![34, 50, 25, 100, 65];
-
-    let result = largest(&number_list);
-    println!("The largest number is {}", result);
-
-    let number_list = vec![102, 34, 6000, 89, 54, 2, 43, 8];
-
-    let result = largest(&number_list);
-    println!("The largest number is {}", result);
-}
-```
-
-Listing 10-3: Abstracted code to find the largest number in two lists
-
-The `largest` function has a parameter called `list`, which represents any
-concrete slice of `i32` values that we might pass into the function. As a
-result, when we call the function, the code runs on the specific values that we
-pass in.
-
-In sum, here are the steps we took to change the code from Listing 10-2 to
-Listing 10-3:
-
-1. Identify duplicate code.
-2. Extract the duplicate code into the body of the function, and specify the
-   inputs and return values of that code in the function signature.
-3. Update the two instances of duplicated code to call the function instead.
-
-Next, we’ll use these same steps with generics to reduce code duplication in
-different ways. In the same way that the function body can operate on an
-abstract `list` instead of specific values, generics allow code to operate on
-abstract types.
-
-For example, say we had two functions: one that finds the largest item in a
-slice of `i32` values and one that finds the largest item in a slice of `char`
-values. How would we eliminate that duplication? Let’s find out!
-
-## Generic Data Types
-
-We can use generics to create definitions for items like function signatures or
-structs, which we can then use with many different concrete data types. Let’s
-first look at how to define functions, structs, enums, and methods using
-generics. Then we’ll discuss how generics affect code performance.
-
-### In Function Definitions
-
-When defining a function that uses generics, we place the generics in the
-signature of the function where we would usually specify the data types of the
-parameters and return value. Doing so makes our code more flexible and provides
-more functionality to callers of our function while preventing code duplication.
-
-Continuing with our `largest` function, Listing 10-4 shows two functions that
-both find the largest value in a slice:
-
-Filename: src/main.rs
-
-```
-fn largest_i32(list: &[i32]) -> i32 {
-    let mut largest = list[0];
-
-    for &item in list.iter() {
-        if item > largest {
-            largest = item;
-        }
-    }
-
-    largest
-}
-
-fn largest_char(list: &[char]) -> char {
-    let mut largest = list[0];
-
-    for &item in list.iter() {
-        if item > largest {
-            largest = item;
-        }
-    }
-
-    largest
-}
-
-fn main() {
-    let number_list = vec![34, 50, 25, 100, 65];
-
-    let result = largest_i32(&number_list);
-    println!("The largest number is {}", result);
-
-    let char_list = vec!['y', 'm', 'a', 'q'];
-
-    let result = largest_char(&char_list);
-    println!("The largest char is {}", result);
-}
-```
-
-Listing 10-4: Two functions that differ only in their names and the types in
-their signatures
-
-The `largest_i32` function is the one we extracted in 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.
-
-To parameterize the types in the new function we’ll define, we need to name the
-type parameter, just like we do for the value parameters to a function. You can
-use any identifier as a type parameter name. But we’ll use `T` because, by
-convention, parameter names in Rust are short, often just a letter, and Rust’s
-type naming convention is CamelCase. Short for “type,” `T` is the default
-choice of most Rust programmers.
-
-When we use a parameter in the body of the function, we have to declare the
-parameter name in the signature so that the compiler knows what that name
-means. Similarly, when we use a type parameter name in a function signature, we
-have to declare the type parameter name before we use it. To define the generic
-`largest` function, place type name declarations inside angle brackets (`<>`)
-between the name of the function and the parameter list, like this:
-
-```
-fn largest(list: &[T]) -> T {
-```
-
-We read this definition as: the function `largest` is generic over some type
-`T`. This function has one parameter named `list`, which is a slice of values
-of type `T`. The `largest` function will return a value of the same type `T`.
-
-Listing 10-5 shows the combined `largest` function definition using the generic
-data type in its signature. The listing also shows how we can call the function
-with either a slice of `i32` values or `char` values. Note that this code won’t
-compile yet, but we’ll fix it later in this chapter.
-
-Filename: src/main.rs
-
-```
-fn largest(list: &[T]) -> T {
-    let mut largest = list[0];
-
-    for &item in list.iter() {
-        if item > largest {
-            largest = item;
-        }
-    }
-
-    largest
-}
-
-fn main() {
-    let number_list = vec![34, 50, 25, 100, 65];
-
-    let result = largest(&number_list);
-    println!("The largest number is {}", result);
-
-    let char_list = vec!['y', 'm', 'a', 'q'];
-
-    let result = largest(&char_list);
-    println!("The largest char is {}", result);
-}
-```
-
-Listing 10-5: A definition of the `largest` function that uses generic type
-parameters but doesn’t compile yet
-
-If we compile this code right now, we’ll get this error:
-
-```
-error[E0369]: binary operation `>` cannot be applied to type `T`
- --> src/main.rs:5:12
-  |
-5 |         if item > largest {
-  |            ^^^^^^^^^^^^^^
-  |
-  = note: an implementation of `std::cmp::PartialOrd` might be missing for `T`
-```
-
-The note mentions `std::cmp::PartialOrd`, which is a *trait*. We’ll talk about
-traits in the next section. For now, this error states that the body of
-`largest` won’t work for all possible types that `T` could be. Because we want
-to compare values of type `T` in the body, we can only use types whose values
-can be ordered. To enable comparisons, the standard library has the
-`std::cmp::PartialOrd` trait that you can implement on types (see Appendix C,
-“Derivable Traits,” for more on this trait). You’ll learn how to specify that a
-generic type has a particular trait in the “Trait Bounds” section, but let’s
-first explore other ways of using generic type parameters.
-
-### In Struct Definitions
-
-We can also define structs to use a generic type parameter in one or more
-fields using the `<>` syntax. Listing 10-6 shows how to define a `Point`
-struct to hold `x` and `y` coordinate values of any type:
-
-Filename: src/main.rs
-
-```
-struct Point {
-    x: T,
-    y: T,
-}
-
-fn main() {
-    let integer = Point { x: 5, y: 10 };
-    let float = Point { x: 1.0, y: 4.0 };
-}
-```
-
-Listing 10-6: A `Point` struct that holds `x` and `y` values of type `T`
-
-The syntax for using generics in struct definitions is similar to that used in
-function definitions. First, we declare the name of the type parameter inside
-angle brackets just after the name of the struct. Then we can use the generic
-type in the struct definition where we would otherwise specify concrete data
-types.
-
-Note that because we’ve only used one generic type to define `Point`, this
-definition says that the `Point` struct is generic over some type `T`, and
-the fields `x` and `y` are *both* that same type, whatever that type may be. If
-we create an instance of a `Point` that has values of different types, as in
-Listing 10-7, our code won’t compile:
-
-Filename: src/main.rs
-
-```
-struct Point {
-    x: T,
-    y: T,
-}
-
-fn main() {
-    let wont_work = Point { x: 5, y: 4.0 };
-}
-```
-
-Listing 10-7: The fields `x` and `y` must be the same type because both have
-the same generic data type `T`
-
-In this example, when we assign the integer value `5` to `x`, we let the
-compiler know that the generic type `T` will be an integer for this instance of
-`Point`. Then when we specify `4.0` for `y`, which we’ve defined to have the
-same type as `x`, we’ll get a type mismatch error like this:
-
-```
-error[E0308]: mismatched types
- --> src/main.rs:7:38
-  |
-7 |     let wont_work = Point { x: 5, y: 4.0 };
-  |                                      ^^^ expected integral variable, found
-floating-point variable
-  |
-  = note: expected type `{integer}`
-             found type `{float}`
-```
-
-To define a `Point` struct where `x` and `y` are both generics but could have
-different types, we can use multiple generic type parameters. For example, in
-Listing 10-8, we can change the definition of `Point` to be generic over types
-`T` and `U` where `x` is of type `T` and `y` is of type `U`:
-
-Filename: src/main.rs
-
-```
-struct Point {
-    x: T,
-    y: U,
-}
-
-fn main() {
-    let both_integer = Point { x: 5, y: 10 };
-    let both_float = Point { x: 1.0, y: 4.0 };
-    let integer_and_float = Point { x: 5, y: 4.0 };
-}
-```
-
-Listing 10-8: A `Point` generic over two types so that `x` and `y` can be
-values of different types
-
-Now all the instances of `Point` shown are allowed! You can use as many generic
-type parameters in a definition as you want, but using more than a few makes
-your code hard to read. When you need lots of generic types in your code, it
-could indicate that your code needs restructuring into smaller pieces.
-
-### In Enum Definitions
-
-As we did with structs, we can define enums to hold generic data types in their
-variants. Let’s take another look at the `Option` enum that the standard
-library provides that we used in Chapter 6:
-
-```
-enum Option {
-    Some(T),
-    None,
-}
-```
-
-This definition should now make more sense to you. As you can see, `Option`
-is an enum that is generic over type `T` and has two variants: `Some`, which
-holds one value of type `T`, and a `None` variant that doesn’t hold any value.
-By using the `Option` enum, we can express the abstract concept of having an
-optional value, and because `Option` is generic, we can use this abstraction
-no matter what the type of the optional value is.
-
-Enums can use multiple generic types as well. The definition of the `Result`
-enum that we used in Chapter 9 is one example:
-
-```
-enum Result {
-    Ok(T),
-    Err(E),
-}
-```
-
-The `Result` enum is generic over two types, `T` and `E`, and has two variants:
-`Ok`, which holds a value of type `T`, and `Err`, which holds a value of type
-`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 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.
-
-When you recognize situations in your code with multiple struct or enum
-definitions that differ only in the types of the values they hold, you can
-avoid duplication by using generic types instead.
-
-### In Method Definitions
-
-As we did in Chapter 5, we can implement methods on structs and enums that have
-generic types in their definitions. Listing 10-9 shows the `Point` struct we
-defined in Listing 10-6 with a method named `x` implemented on it:
-
-Filename: src/main.rs
-
-```
-struct Point {
-    x: T,
-    y: T,
-}
-
-impl Point {
-    fn x(&self) -> &T {
-        &self.x
-    }
-}
-
-fn main() {
-    let p = Point { x: 5, y: 10 };
-
-    println!("p.x = {}", p.x());
-}
-```
-
-Listing 10-9: Implementing a method named `x` on the `Point` struct that
-will return a reference to the `x` field of type `T`
-
-Here, we’ve defined a method named `x` on `Point` that returns a reference
-to the data in the field `x`.
-
-Note that we have to declare `T` just after `impl` so we can use it to specify
-that we’re implementing methods on the type `Point`.  By declaring `T` as a
-generic type after `impl`, Rust can identify that the type in the angle
-brackets in `Point` is a generic type rather than a concrete type.
-
-We could, for example, implement methods only on `Point` instances rather
-than on `Point` instances with any generic type. In Listing 10-10 we use the
-concrete type `f32`, meaning we don’t declare any types after `impl`:
-
-```
-impl Point {
-    fn distance_from_origin(&self) -> f32 {
-        (self.x.powi(2) + self.y.powi(2)).sqrt()
-    }
-}
-```
-
-Listing 10-10: An `impl` block that only applies to a struct with a particular
-concrete type for the generic type parameter `T`
-
-This code means the type `Point` will have a method named
-`distance_from_origin`, and other instances of `Point` where `T` is not of
-type `f32` will not have this method defined. The method measures how far our
-point is from the point at coordinates (0.0, 0.0) and uses mathematical
-operations that are only available for floating point types.
-
-Generic type parameters in a struct definition aren’t always the same as those
-you use in that struct’s method signatures. For example, Listing 10-11 defines
-the method `mixup` on the `Point` struct from Listing 10-8. The method
-takes another `Point` as a parameter, which might have different types than the
-`self` `Point` we’re calling `mixup` on. The method creates a new `Point`
-instance with the `x` value from the `self` `Point` (of type `T`) and the `y`
-value from the passed-in `Point` (of type `W`):
-
-Filename: src/main.rs
-
-```
-struct Point {
-    x: T,
-    y: U,
-}
-
-impl Point {
-    fn mixup(self, other: Point) -> Point {
-        Point {
-            x: self.x,
-            y: other.y,
-        }
-    }
-}
-
-fn main() {
-    let p1 = Point { x: 5, y: 10.4 };
-    let p2 = Point { x: "Hello", y: 'c'};
-
-    let p3 = p1.mixup(p2);
-
-    println!("p3.x = {}, p3.y = {}", p3.x, p3.y);
-}
-```
-
-Listing 10-11: A method that uses different generic types than its struct’s
-definition
-
-In `main`, we’ve defined a `Point` that has an `i32` for `x` (with value `5`)
-and an `f64` for `y` (with value `10.4`). The `p2` variable is a `Point` struct
-that has a string slice for `x` (with value `"Hello"`) and a `char` for `y`
-(with value `c`). Calling `mixup` on `p1` with the argument `p2` gives us `p3`,
-which will have an `i32` for `x`, because `x` came from `p1`. The `p3` variable
-will have a `char` for `y`, because `y` came from `p2`. The `println!` macro
-call will print `p3.x = 5, p3.y = c`.
-
-The purpose of this example is to demonstrate a situation in which some generic
-parameters are declared with `impl` and some are declared with the method
-definition. Here, the generic parameters `T` and `U` are declared after `impl`,
-because they go with the struct definition. The generic parameters `V` and `W`
-are declared after `fn mixup`, because they’re only relevant to the method.
-
-### Performance of Code Using Generics
-
-You might be wondering whether there is a runtime cost when you’re using
-generic type parameters. The good news is that Rust implements generics in such
-a way that your code doesn’t run any slower using generic types than it would
-with concrete types.
-
-Rust accomplishes this by performing monomorphization of the code that is using
-generics at compile time. *Monomorphization* is the process of turning generic
-code into specific code by filling in the concrete types that are used when
-compiled.
-
-In this process, the compiler does the opposite of the steps we used to create
-the generic function in Listing 10-5: the compiler looks at all the places
-where generic code is called and generates code for the concrete types the
-generic code is called with.
-
-Let’s look at how this works with an example that uses the standard library’s
-`Option` enum:
-
-```
-let integer = Some(5);
-let float = Some(5.0);
-```
-
-When Rust compiles this code, it performs monomorphization. During that
-process, the compiler reads the values that have been used in the instances of
-`Option` and identifies two kinds of `Option`: one is `i32` and the other
-is `f64`. As such, it expands the generic definition of `Option` into
-`Option_i32` and `Option_f64`, thereby replacing the generic definition with
-the specific ones.
-
-The monomorphized version of the code looks like the following. The generic
-`Option` is replaced with the specific definitions created by the compiler:
-
-Filename: src/main.rs
-
-```
-enum Option_i32 {
-    Some(i32),
-    None,
-}
-
-enum Option_f64 {
-    Some(f64),
-    None,
-}
-
-fn main() {
-    let integer = Option_i32::Some(5);
-    let float = Option_f64::Some(5.0);
-}
-```
-
-Because Rust compiles generic code into code that specifies the type in each
-instance, we pay no runtime cost for using generics. When the code runs, it
-performs just like it would if we had duplicated each definition by hand. The
-process of monomorphization makes Rust’s generics extremely efficient at
-runtime.
-
-## Traits: Defining Shared Behavior
-
-A *trait* tells the Rust compiler about functionality a particular type has and
-can share with other types. We can use traits to define shared behavior in an
-abstract way. We can use trait bounds to specify that a generic can be any type
-that has certain behavior.
-
-> Note: Traits are similar to a feature often called *interfaces* in other
-> languages, although with some differences.
-
-### Defining a Trait
-
-A type’s behavior consists of the methods we can call on that type. Different
-types share the same behavior if we can call the same methods on all of those
-types. Trait definitions are a way to group method signatures together to
-define a set of behaviors necessary to accomplish some purpose.
-
-For example, let’s say we have multiple structs that hold various kinds and
-amounts of text: a `NewsArticle` struct that holds a news story filed in a
-particular location and a `Tweet` that can have at most 280 characters along
-with metadata that indicates whether it was a new tweet, a retweet, or a reply
-to another tweet.
-
-We want to make a media aggregator library that can display summaries of data
-that might be stored in a `NewsArticle` or `Tweet` instance. To do this, we
-need a summary from each type, and we need to request that summary by calling a
-`summarize` method on an instance. Listing 10-12 shows the definition of a
-`Summary` trait that expresses this behavior:
-
-Filename: src/lib.rs
-
-```
-pub trait Summary {
-    fn summarize(&self) -> String;
-}
-```
-
-Listing 10-12: A `Summary` trait that consists of the behavior provided by a
-`summarize` method
-
-Here, we declare a trait using the `trait` keyword and then the trait’s name,
-which is `Summary` in this case. Inside the curly brackets we declare the
-method signatures that describe the behaviors of the types that implement this
-trait, which in this case is `fn summarize(&self) -> String`.
-
-After the method signature, instead of providing an implementation within curly
-brackets, we use a semicolon. Each type implementing this trait must provide
-its own custom behavior for the body of the method. The compiler will enforce
-that any type that has the `Summary` trait will have the method `summarize`
-defined with this signature exactly.
-
-A trait can have multiple methods in its body: the method signatures are listed
-one per line and each line ends in a semicolon.
-
-### Implementing a Trait on a Type
-
-Now that we’ve defined the desired behavior using the `Summary` trait, we can
-implement it on the types in our media aggregator. Listing 10-13 shows an
-implementation of the `Summary` trait on the `NewsArticle` struct that uses the
-headline, the author, and the location to create the return value of
-`summarize`. For the `Tweet` struct, we define `summarize` as the username
-followed by the entire text of the tweet, assuming that tweet content is
-already limited to 280 characters.
-
-Filename: src/lib.rs
-
-```
-pub struct NewsArticle {
-    pub headline: String,
-    pub location: String,
-    pub author: String,
-    pub content: String,
-}
-
-impl Summary for NewsArticle {
-    fn summarize(&self) -> String {
-        format!("{}, by {} ({})", self.headline, self.author, self.location)
-    }
-}
-
-pub struct Tweet {
-    pub username: String,
-    pub content: String,
-    pub reply: bool,
-    pub retweet: bool,
-}
-
-impl Summary for Tweet {
-    fn summarize(&self) -> String {
-        format!("{}: {}", self.username, self.content)
-    }
-}
-```
-
-Listing 10-13: Implementing the `Summary` trait on the `NewsArticle` and
-`Tweet` types
-
-Implementing a trait on a type is similar to implementing regular methods. The
-difference is that after `impl`, we put the trait name that we want to
-implement, then use the `for` keyword, and then specify the name of the type we
-want to implement the trait for. Within the `impl` block, we put the method
-signatures that the trait definition has defined. Instead of adding a semicolon
-after each signature, we use curly brackets and fill in the method body with
-the specific behavior that we want the methods of the trait to have for the
-particular type.
-
-After implementing the trait, we can call the methods on instances of
-`NewsArticle` and `Tweet` in the same way we call regular methods, like this:
-
-```
-let tweet = Tweet {
-    username: String::from("horse_ebooks"),
-    content: String::from("of course, as you probably already know, people"),
-    reply: false,
-    retweet: false,
-};
-
-println!("1 new tweet: {}", tweet.summarize());
-```
-
-This code prints `1 new tweet: horse_ebooks: of course, as you probably already
-know, people`.
-
-Note that because we defined the `Summary` trait and the `NewsArticle` and
-`Tweet` types in the same *lib.rs* in Listing 10-13, they’re all in the same
-scope. Let’s say this *lib.rs* is for a crate we’ve called `aggregator`, and
-someone else wants to use our crate’s functionality to implement the `Summary`
-trait on a struct defined within their library’s scope. They would need to
-import the trait into their scope first. They would do so by specifying `use
-aggregator::Summary;`, which then enables them to implement `Summary` for their
-type. The `Summary` trait would also need to be a public trait for another
-crate to implement it, which it is because we put the `pub` keyword before
-`trait` in Listing 10-12.
-
-One restriction to note with trait implementations is that we can implement a
-trait on a type only if either the trait or the type is local to our crate.
-For example, we can implement standard library traits like `Display` on a
-custom type like `Tweet` as part of our `aggregator` crate functionality,
-because the type `Tweet` is local to our `aggregator` crate. We can also
-implement `Summary` on `Vec` in our `aggregator` crate, because the
-trait `Summary` is local to our `aggregator` crate.
-
-But we can’t implement external traits on external types. For example, we can’t
-implement the `Display` trait on `Vec` within our `aggregator` crate,
-because `Display` and `Vec` are defined in the standard library and aren’t
-local to our `aggregator` crate. This restriction is part of a property of
-programs called *coherence*, and more specifically the *orphan rule*, so named
-because the parent type is not present. This rule ensures that other people’s
-code can’t break your code and vice versa. Without the rule, two crates could
-implement the same trait for the same type, and Rust wouldn’t know which
-implementation to use.
-
-### Default Implementations
-
-Sometimes it’s useful to have default behavior for some or all of the methods
-in a trait instead of requiring implementations for all methods on every type.
-Then, as we implement the trait on a particular type, we can keep or override
-each method’s default behavior.
-
-Listing 10-14 shows how to specify a default string for the `summarize` method
-of the `Summary` trait instead of only defining the method signature, like we
-did in Listing 10-12:
-
-Filename: src/lib.rs
-
-```
-pub trait Summary {
-    fn summarize(&self) -> String {
-        String::from("(Read more...)")
-    }
-}
-```
-
-Listing 10-14: Definition of a `Summary` trait with a default implementation of
-the `summarize` method
-
-To use a default implementation to summarize instances of `NewsArticle` instead
-of defining a custom implementation, we specify an empty `impl` block with
-`impl Summary for NewsArticle {}`.
-
-Even though we’re no longer defining the `summarize` method on `NewsArticle`
-directly, we’ve provided a default implementation and specified that
-`NewsArticle` implements the `Summary` trait. As a result, we can still call
-the `summarize` method on an instance of `NewsArticle`, like this:
-
-```
-let article = NewsArticle {
-    headline: String::from("Penguins win the Stanley Cup Championship!"),
-    location: String::from("Pittsburgh, PA, USA"),
-    author: String::from("Iceburgh"),
-    content: String::from("The Pittsburgh Penguins once again are the best
-    hockey team in the NHL."),
-};
-
-println!("New article available! {}", article.summarize());
-```
-
-This code prints `New article available! (Read more...)`.
-
-Creating a default implementation for `summarize` doesn’t require us to change
-anything about the implementation of `Summary` on `Tweet` in Listing 10-13. The
-reason is that the syntax for overriding a default implementation is the same
-as the syntax for implementing a trait method that doesn’t have a default
-implementation.
-
-Default implementations can call other methods in the same trait, even if those
-other methods don’t have a default implementation. In this way, a trait can
-provide a lot of useful functionality and only require implementors to specify
-a small part of it. For example, we could define the `Summary` trait to have a
-`summarize_author` method whose implementation is required, and then define a
-`summarize` method that has a default implementation that calls the
-`summarize_author` method:
-
-```
-pub trait Summary {
-    fn summarize_author(&self) -> String;
-
-    fn summarize(&self) -> String {
-        format!("(Read more from {}...)", self.summarize_author())
-    }
-}
-```
-
-To use this version of `Summary`, we only need to define `summarize_author`
-when we implement the trait on a type:
-
-```
-impl Summary for Tweet {
-    fn summarize_author(&self) -> String {
-        format!("@{}", self.username)
-    }
-}
-```
-
-After we define `summarize_author`, we can call `summarize` on instances of the
-`Tweet` struct, and the default implementation of `summarize` will call the
-definition of `summarize_author` that we’ve provided. Because we’ve implemented
-`summarize_author`, the `Summary` trait has given us the behavior of the
-`summarize` method without requiring us to write any more code.
-
-```
-let tweet = Tweet {
-    username: String::from("horse_ebooks"),
-    content: String::from("of course, as you probably already know, people"),
-    reply: false,
-    retweet: false,
-};
-
-println!("1 new tweet: {}", tweet.summarize());
-```
-
-This code prints `1 new tweet: (Read more from @horse_ebooks...)`.
-
-Note that it isn’t possible to call the default implementation from an
-overriding implementation of that same method.
-
-### Trait Bounds
-
-Now that you know how to define traits and implement those traits on types, we
-can explore how to use traits with generic type parameters. We can use *trait
-bounds* to constrain generic types to ensure the type will be limited to those
-that implement a particular trait and behavior.
-
-For example, in Listing 10-13, we implemented the `Summary` trait on the types
-`NewsArticle` and `Tweet`. We can define a function `notify` that calls the
-`summarize` method on its parameter `item`, which is of the generic type `T`.
-To be able to call `summarize` on `item` without getting an error telling us
-that the generic type `T` doesn’t implement the method `summarize`, we can use
-trait bounds on `T` to specify that `item` must be of a type that implements
-the `Summary` trait:
-
-```
-pub fn notify(item: T) {
-    println!("Breaking news! {}", item.summarize());
-}
-```
-
-We place trait bounds with the declaration of the generic type parameter, after
-a colon and inside angle brackets. Because of the trait bound on `T`, we can
-call `notify` and pass in any instance of `NewsArticle` or `Tweet`. Code that
-calls the function with any other type, like a `String` or an `i32`, won’t
-compile, because those types don’t implement `Summary`.
-
-We can specify multiple trait bounds on a generic type using the `+` syntax.
-For example, to use display formatting on the type `T` in a function as well as
-the `summarize` method, we can use `T: Summary + Display` to say `T` can be any
-type that implements `Summary` and `Display`.
-
-However, there are downsides to using too many trait bounds. Each generic has
-its own trait bounds; so functions with multiple generic type parameters can
-have lots of trait bound information between a function’s name and its
-parameter list, making the function signature hard to read. For this reason,
-Rust has alternate syntax for specifying trait bounds inside a `where` clause
-after the function signature. So instead of writing this:
-
-```
-fn some_function(t: T, u: U) -> i32 {
-```
-
-we can use a `where` clause, like this:
-
-```
-fn some_function(t: T, u: U) -> i32
-    where T: Display + Clone,
-          U: Clone + Debug
-{
-```
-
-This function’s signature is less cluttered in that the function name,
-parameter list, and return type are close together, similar to a function
-without lots of trait bounds.
-
-### Fixing the `largest` Function with Trait Bounds
-
-Now that you know how to specify the behavior you want to use using the generic
-type parameter’s bounds, let’s return to Listing 10-5 to fix the definition of
-the `largest` function that uses a generic type parameter! Last time we tried
-to run that code, we received this error:
-
-```
-error[E0369]: binary operation `>` cannot be applied to type `T`
- --> src/main.rs:5:12
-  |
-5 |         if item > largest {
-  |            ^^^^^^^^^^^^^^
-  |
-  = note: an implementation of `std::cmp::PartialOrd` might be missing for `T`
-```
-
-In the body of `largest` we wanted to compare two values of type `T` using the
-greater-than (`>`) operator. Because that operator is defined as a default
-method on the standard library trait `std::cmp::PartialOrd`, we need to specify
-`PartialOrd` in the trait bounds for `T` so the `largest` function can work on
-slices of any type that we can compare. We don’t need to bring `PartialOrd`
-into scope because it’s in the prelude. Change the signature of `largest` to
-look like this:
-
-```
-fn largest(list: &[T]) -> T {
-```
-
-This time when we compile the code, we get a different set of errors:
-
-```
-error[E0508]: cannot move out of type `[T]`, a non-copy slice
- --> src/main.rs:2:23
-  |
-2 |     let mut largest = list[0];
-  |                       ^^^^^^^
-  |                       |
-  |                       cannot move out of here
-  |                       help: consider using a reference instead: `&list[0]`
-
-error[E0507]: cannot move out of borrowed content
- --> src/main.rs:4:9
-  |
-4 |     for &item in list.iter() {
-  |         ^----
-  |         ||
-  |         |hint: to prevent move, use `ref item` or `ref mut item`
-  |         cannot move out of borrowed content
-```
-
-The key line in this error is `cannot move out of type [T], a non-copy slice`.
-With our non-generic versions of the `largest` function, we were only trying to
-find the largest `i32` or `char`. As discussed in the “Stack-Only Data: Copy”
-section in Chapter 4, types like `i32` and `char` that have a known size can be
-stored on the stack, so they implement the `Copy` trait. But when we made the
-`largest` function generic, it became possible for the `list` parameter to have
-types in it that don’t implement the `Copy` trait. Consequently, we wouldn’t be
-able to move the value out of `list[0]` and into the `largest` variable,
-resulting in this error.
-
-To call this code with only those types that implement the `Copy` trait, we can
-add `Copy` to the trait bounds of `T`! Listing 10-15 shows the complete code of
-a generic `largest` function that will compile as long as the types of the
-values in the slice that we pass into the function implement the `PartialOrd`
-*and* `Copy` traits, like `i32` and `char` do:
-
-Filename: src/main.rs
-
-```
-fn largest(list: &[T]) -> T {
-    let mut largest = list[0];
-
-    for &item in list.iter() {
-        if item > largest {
-            largest = item;
-        }
-    }
-
-    largest
-}
-
-fn main() {
-    let number_list = vec![34, 50, 25, 100, 65];
-
-    let result = largest(&number_list);
-    println!("The largest number is {}", result);
-
-    let char_list = vec!['y', 'm', 'a', 'q'];
-
-    let result = largest(&char_list);
-    println!("The largest char is {}", result);
-}
-```
-
-Listing 10-15: A working definition of the `largest` function that works on any
-generic type that implements the `PartialOrd` and `Copy` traits
-
-If we don’t want to restrict the `largest` function to the types that implement
-the `Copy` trait, we could specify that `T` has the trait bound `Clone` instead
-of `Copy`. Then we could clone each value in the slice when we want the
-`largest` function to have ownership. Using the `clone` function means we’re
-potentially making more heap allocations in the case of types that own heap
-data like `String`, and heap allocations can be slow if we’re working with
-large amounts of data.
-
-Another way we could implement `largest` is for the function to return a
-reference to a `T` value in the slice. If we change the return type to `&T`
-instead of `T`, thereby changing the body of the function to return a
-reference, we wouldn’t need the `Clone` or `Copy` trait bounds and we could
-avoid heap allocations. Try implementing these alternate solutions on your own!
-
-### Using Trait Bounds to Conditionally Implement Methods
-
-By using a trait bound with an `impl` block that uses generic type parameters,
-we can implement methods conditionally for types that implement the specified
-traits. For example, the type `Pair` in Listing 10-16 always implements the
-`new` function. But `Pair` only implements the `cmp_display` method if its
-inner type `T` implements the `PartialOrd` trait that enables comparison *and*
-the `Display` trait that enables printing:
-
-```
-use std::fmt::Display;
-
-struct Pair {
-    x: T,
-    y: T,
-}
-
-impl Pair {
-    fn new(x: T, y: T) -> Self {
-        Self {
-            x,
-            y,
-        }
-    }
-}
-
-impl Pair {
-    fn cmp_display(&self) {
-        if self.x >= self.y {
-            println!("The largest member is x = {}", self.x);
-        } else {
-            println!("The largest member is y = {}", self.y);
-        }
-    }
-}
-```
-
-Listing 10-16: Conditionally implement methods on a generic type depending on
-trait bounds
-
-We can also conditionally implement a trait for any type that implements
-another trait. Implementations of a trait on any type that satisfies the trait
-bounds are called *blanket implementations* and are extensively used in the
-Rust standard library. For example, the standard library implements the
-`ToString` trait on any type that implements the `Display` trait. The `impl`
-block in the standard library looks similar to this code:
-
-```
-impl ToString for T {
-    // --snip--
-}
-```
-
-Because the standard library has this blanket implementation, we can call the
-`to_string` method defined by the `ToString` trait on any type that implements
-the `Display` trait. For example, we can turn integers into their corresponding
-`String` values like this because integers implement `Display`:
-
-```
-let s = 3.to_string();
-```
-
-Blanket implementations appear in the documentation for the trait in the
-“Implementors” section.
-
-Traits and trait bounds let us write code that uses generic type parameters to
-reduce duplication but also specify to the compiler that we want the generic
-type to have particular behavior. The compiler can then use the trait bound
-information to check that all the concrete types used with our code provide the
-correct behavior. In dynamically typed languages, we would get an error at
-runtime if we called a method on a type that the type didn’t implement. But
-Rust moves these errors to compile time so we’re forced to fix the problems
-before our code is even able to run. Additionally, we don’t have to write code
-that checks for behavior at runtime because we’ve already checked at compile
-time. Doing so improves performance without having to give up the flexibility
-of generics.
-
-Another kind of generic that we’ve already been using is called *lifetimes*.
-Rather than ensuring that a type has the behavior we want, lifetimes ensure
-that references are valid as long as we need them to be. Let’s look at how
-lifetimes do that.
-
-## Validating References with Lifetimes
-
-One detail we didn’t discuss in the “References and Borrowing” section in
-Chapter 4 is that every reference in Rust has a *lifetime*, which is the scope
-for which that reference is valid. Most of the time lifetimes are implicit and
-inferred, just like most of the time types are inferred. We must annotate types
-when multiple types are possible. In a similar way, we must annotate lifetimes
-when the lifetimes of references could be related in a few different ways. Rust
-requires us to annotate the relationships using generic lifetime parameters to
-ensure the actual references used at runtime will definitely be valid.
-
-The concept of lifetimes is somewhat different from tools in other programming
-languages, arguably making lifetimes Rust’s most distinctive feature. Although
-we won’t cover lifetimes in their entirety in this chapter, we’ll discuss
-common ways you might encounter lifetime syntax so you can become familiar with
-the concepts. See the “Advanced Lifetimes” section in Chapter 19 for more
-detailed information.
-
-### Lifetimes Prevent Dangling References
-
-The main aim of lifetimes is to prevent dangling references, which cause a
-program to reference data other than the data it’s intended to reference.
-Consider the program in Listing 10-17, which has an outer scope and an inner
-scope:
-
-```
-{
-    let r;
-
-    {
-        let x = 5;
-        r = &x;
-    }
-
-    println!("r: {}", r);
-}
-```
-
-Listing 10-17: An attempt to use a reference whose value has gone out of scope
-
-> Note: The example in Listing 10-17 and the next few examples declare
-> variables without giving them an initial value, so the variable name exists
-> in the outer scope. At first glance, this might appear to be in conflict with
-> Rust having no null values. However, if we try to use a variable before
-> giving it a value, we’ll get a compile time error, which shows that Rust
-> indeed does not allow null values.
-
-The outer scope declares a variable named `r` with no initial value, and the
-inner scope declares a variable named `x` with the initial value of `5`. Inside
-the inner scope, we attempt to set the value of `r` as a reference to `x`. Then
-the inner scope ends, and we attempt to print the value in `r`. This code won’t
-compile because the value `r` is referring to has gone out of scope before we
-try to use it. Here is the error message:
-
-```
-error[E0597]: `x` does not live long enough
-  --> src/main.rs:7:5
-   |
-6  |         r = &x;
-   |              - borrow occurs here
-7  |     }
-   |     ^ `x` dropped here while still borrowed
-...
-10 | }
-   | - borrowed value needs to live until here
-```
-
-The variable `x` doesn’t “live long enough.” The reason is that `x` will be out
-of scope when the inner scope ends on line 7. But `r` is still valid for the
-outer scope; because its scope is larger, we say that it “lives longer.” If
-Rust allowed this code to work, `r` would be referencing memory that was
-deallocated when `x` went out of scope, and anything we tried to do with `r`
-wouldn’t work correctly. So how does Rust determine that this code is invalid?
-It uses a borrow checker.
-
-### The Borrow Checker
-
-The Rust compiler has a *borrow checker* that compares scopes to determine that
-all borrows are valid. Listing 10-18 shows the same code as Listing 10-17 but
-with annotations showing the lifetimes of the variables:
-
-```
-{
-    let r;                // ---------+-- 'a
-                          //          |
-    {                     //          |
-        let x = 5;        // -+-- 'b  |
-        r = &x;           //  |       |
-    }                     // -+       |
-                          //          |
-    println!("r: {}", r); //          |
-}                         // ---------+
-```
-
-Listing 10-18: Annotations of the lifetimes of `r` and `x`, named `'a` and
-`'b`, respectively
-
-Here, we’ve annotated the lifetime of `r` with `'a` and the lifetime of `x`
-with `'b`. As you can see, the inner `'b` block is much smaller than the outer
-`'a` lifetime block. At compile time, Rust compares the size of the two
-lifetimes and sees that `r` has a lifetime of `'a` but that it refers to memory
-with a lifetime of `'b`. The program is rejected because `'b` is shorter than
-`'a`: the subject of the reference doesn’t live as long as the reference.
-
-Listing 10-19 fixes the code so it doesn’t have a dangling reference and
-compiles without any errors:
-
-```
-{
-    let x = 5;            // ----------+-- 'b
-                          //           |
-    let r = &x;           // --+-- 'a  |
-                          //   |       |
-    println!("r: {}", r); //   |       |
-                          // --+       |
-}                         // ----------+
-```
-
-Listing 10-19: A valid reference because the data has a longer lifetime than
-the reference
-
-Here, `x` has the lifetime `'b`, which in this case is larger than `'a`. This
-means `r` can reference `x` because Rust knows that the reference in `r` will
-always be valid while `x` is valid.
-
-Now that you know where the lifetimes of references are and how Rust analyzes
-lifetimes to ensure references will always be valid, let’s explore generic
-lifetimes of parameters and return values in the context of functions.
-
-### Generic Lifetimes in Functions
-
-Let’s write a function that returns the longer of two string slices. This
-function will take two string slices and return a string slice. After we’ve
-implemented the `longest` function, the code in Listing 10-20 should print `The
-longest string is abcd`:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let string1 = String::from("abcd");
-    let string2 = "xyz";
-
-    let result = longest(string1.as_str(), string2);
-    println!("The longest string is {}", result);
-}
-```
-
-Listing 10-20: A `main` function that calls the `longest` function to find the
-longer of two string slices
-
-Note that we want the function to take string slices, which are references,
-because we don’t want the `longest` function to take ownership of its
-parameters. We want to allow the function to accept slices of a `String` (the
-type stored in the variable `string1`) as well as string literals (which is
-what variable `string2` contains).
-
-Refer to the “String Slices as Parameters” section in Chapter 4 for more
-discussion about why the parameters we use in Listing 10-20 are the ones we
-want.
-
-If we try to implement the `longest` function as shown in Listing 10-21, it
-won’t compile:
-
-Filename: src/main.rs
-
-```
-fn longest(x: &str, y: &str) -> &str {
-    if x.len() > y.len() {
-        x
-    } else {
-        y
-    }
-}
-```
-
-Listing 10-21: An implementation of the `longest` function that returns the
-longer of two string slices but does not yet compile
-
-Instead, we get the following error that talks about lifetimes:
-
-```
-error[E0106]: missing lifetime specifier
- --> src/main.rs:1:33
-  |
-1 | fn longest(x: &str, y: &str) -> &str {
-  |                                 ^ expected lifetime parameter
-  |
-  = help: this function's return type contains a borrowed value, but the
-signature does not say whether it is borrowed from `x` or `y`
-```
-
-The help text reveals that the return type needs a generic lifetime parameter
-on it because Rust can’t tell whether the reference being returned refers to
-`x` or `y`. Actually, we don’t know either, because the `if` block in the body
-of this function returns a reference to `x` and the `else` block returns a
-reference to `y`!
-
-When we’re defining this function, we don’t know the concrete values that will
-be passed into this function, so we don’t know whether the `if` case or the
-`else` case will execute. We also don’t know the concrete lifetimes of the
-references that will be passed in, so we can’t look at the scopes like we did
-in Listings 10-18 and 10-19 to determine that the reference we return will
-always be valid. The borrow checker can’t determine this either, because it
-doesn’t know how the lifetimes of `x` and `y` relate to the lifetime of the
-return value. To fix this error, we’ll add generic lifetime parameters that
-define the relationship between the references so the borrow checker can
-perform its analysis.
-
-### Lifetime Annotation Syntax
-
-Lifetime annotations don’t change how long any of the references live. Just
-like functions can accept any type when the signature specifies a generic type
-parameter, functions can accept references with any lifetime by specifying a
-generic lifetime parameter. Lifetime annotations describe the relationships of
-the lifetimes of multiple references to each other without affecting the
-lifetimes.
-
-Lifetime annotations have a slightly unusual syntax: the names of lifetime
-parameters must start with an apostrophe `'` and are usually all lowercase and
-very short, like generic types. Most people use the name `'a`. We place
-lifetime parameter annotations after the `&` of a reference, using a space to
-separate the annotation from the reference’s type.
-
-Here are some examples: a reference to an `i32` without a lifetime parameter, a
-reference to an `i32` that has a lifetime parameter named `'a`, and a mutable
-reference to an `i32` that also has the lifetime `'a`.
-
-```
-&i32        // a reference
-&'a i32     // a reference with an explicit lifetime
-&'a mut i32 // a mutable reference with an explicit lifetime
-```
-
-One lifetime annotation by itself doesn’t have much meaning because the
-annotations are meant to tell Rust how generic lifetime parameters of multiple
-references relate to each other. For example, let’s say we have a function with
-the parameter `first` that is a reference to an `i32` with lifetime `'a`. The
-function also has another parameter named `second` that is another reference to
-an `i32` that also has the lifetime `'a`. The lifetime annotations indicate
-that the references `first` and `second` must both live as long as that generic
-lifetime.
-
-### Lifetime Annotations in Function Signatures
-
-Now let’s examine lifetime annotations in the context of the `longest`
-function. As with generic type parameters, we need to declare generic lifetime
-parameters inside angle brackets between the function name and the parameter
-list. The constraint we want to express in this signature is that all the
-references in the parameters and the return value must have the same lifetime.
-We’ll name the lifetime `'a`, and then add it to each reference, as shown in
-Listing 10-22:
-
-Filename: src/main.rs
-
-```
-fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
-    if x.len() > y.len() {
-        x
-    } else {
-        y
-    }
-}
-```
-
-Listing 10-22: The `longest` function definition specifying that all the
-references in the signature must have the same lifetime `'a`
-
-This code should compile and produce the result we want when we use it with the
-`main` function in Listing 10-20.
-
-The function signature now tells Rust that for some lifetime `'a`, the function
-takes two parameters, both of which are string slices that live at least as
-long as lifetime `'a`. The function signature also tells Rust that the string
-slice returned from the function will live at least as long as lifetime `'a`.
-These constraints are what we want Rust to enforce. Remember, when we specify
-the lifetime parameters in this function signature, we’re not changing the
-lifetimes of any values passed in or returned. Rather, we’re specifying that
-the borrow checker should reject any values that don’t adhere to these
-constraints. Note that the `longest` function doesn’t need to know exactly how
-long `x` and `y` will live, only that some scope can be substituted for `'a`
-that will satisfy this signature.
-
-When annotating lifetimes in functions, the annotations go in the function
-signature, not in the function body. Rust can analyze the code within the
-function without any help. However, when a function has references to or from
-code outside that function, it becomes almost impossible for Rust to figure out
-the lifetimes of the parameters or return values on its own. The lifetimes
-might be different each time the function is called. This is why we need to
-annotate the lifetimes manually.
-
-When we pass concrete references to `longest`, the concrete lifetime that is
-substituted for `'a` is the part of the scope of `x` that overlaps with the
-scope of `y`. In other words, the generic lifetime `'a` will get the concrete
-lifetime that is equal to the smaller of the lifetimes of `x` and `y`. Because
-we’ve annotated the returned reference with the same lifetime parameter `'a`,
-the returned reference will also be valid for the length of the smaller of the
-lifetimes of `x` and `y`.
-
-Let’s look at how the lifetime annotations restrict the `longest` function by
-passing in references that have different concrete lifetimes. Listing 10-23 is
-a straightforward example:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let string1 = String::from("long string is long");
-
-    {
-        let string2 = String::from("xyz");
-        let result = longest(string1.as_str(), string2.as_str());
-        println!("The longest string is {}", result);
-    }
-}
-```
-
-Listing 10-23: Using the `longest` function with references to `String` values
-that have different concrete lifetimes
-
-In this example, `string1` is valid until the end of the outer scope, `string2`
-is valid until the end of the inner scope, and `result` references something
-that is valid until the end of the inner scope. Run this code, and you’ll see
-that the borrow checker approves of this code; it will compile and print `The
-longest string is long string is long`.
-
-Next, let’s try an example that shows that the lifetime of the reference in
-`result` must be the smaller lifetime of the two arguments. We’ll move the
-declaration of the `result` variable outside the inner scope but leave the
-assignment of the value to the `result` variable inside the scope with
-`string2`. Then we’ll move the `println!` that uses `result` outside the inner
-scope, after the inner scope has ended. The code in Listing 10-24 will not
-compile:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let string1 = String::from("long string is long");
-    let result;
-    {
-        let string2 = String::from("xyz");
-        result = longest(string1.as_str(), string2.as_str());
-    }
-    println!("The longest string is {}", result);
-}
-```
-
-Listing 10-24: Attempting to use `result` after `string2` has gone out of
-scope; the code won’t compile
-
-When we try to compile this code, we’ll get this error:
-
-```
-error[E0597]: `string2` does not live long enough
-  --> src/main.rs:15:5
-   |
-14 |         result = longest(string1.as_str(), string2.as_str());
-   |                                            ------- borrow occurs here
-15 |     }
-   |     ^ `string2` dropped here while still borrowed
-16 |     println!("The longest string is {}", result);
-17 | }
-   | - borrowed value needs to live until here
-```
-
-The error shows that for `result` to be valid for the `println!` statement,
-`string2` would need to be valid until the end of the outer scope. Rust knows
-this because we annotated the lifetimes of the function parameters and return
-values using the same lifetime parameter `'a`.
-
-As humans, we can look at this code and see that `string1` is longer than
-`string2`, and therefore `result` will contain a reference to `string1`.
-Because `string1` has not gone out of scope yet, a reference to `string1` will
-still be valid for the `println!` statement. However, the compiler can’t see
-that the reference is valid in this case. We’ve told Rust that the lifetime of
-the reference returned by the `longest` function is the same as the smaller of
-the lifetimes of the references passed in. Therefore, the borrow checker
-disallows the code in Listing 10-24 as possibly having an invalid reference.
-
-Try designing more experiments that vary the values and lifetimes of the
-references passed in to the `longest` function and how the returned reference
-is used. Make hypotheses about whether or not your experiments will pass the
-borrow checker before you compile; then check to see if you’re right!
-
-### Thinking in Terms of Lifetimes
-
-The way in which you need to specify lifetime parameters depends on what your
-function is doing. For example, if we changed the implementation of the
-`longest` function to always return the first parameter rather than the longest
-string slice, we wouldn’t need to specify a lifetime on the `y` parameter. The
-following code will compile:
-
-Filename: src/main.rs
-
-```
-fn longest<'a>(x: &'a str, y: &str) -> &'a str {
-    x
-}
-```
-
-In this example, we’ve specified a lifetime parameter `'a` for the parameter
-`x` and the return type, but not for the parameter `y`, because the lifetime of
-`y` does not have any relationship with the lifetime of `x` or the return value.
-
-When returning a reference from a function, the lifetime parameter for the
-return type needs to match the lifetime parameter for one of the parameters. If
-the reference returned does *not* refer to one of the parameters, it must refer
-to a value created within this function, which would be a dangling reference
-because the value will go out of scope at the end of the function. Consider
-this attempted implementation of the `longest` function that won’t compile:
-
-Filename: src/main.rs
-
-```
-fn longest<'a>(x: &str, y: &str) -> &'a str {
-    let result = String::from("really long string");
-    result.as_str()
-}
-```
-
-Here, even though we’ve specified a lifetime parameter `'a` for the return
-type, this implementation will fail to compile because the return value
-lifetime is not related to the lifetime of the parameters at all. Here is the
-error message we get:
-
-```
-error[E0597]: `result` does not live long enough
- --> src/main.rs:3:5
-  |
-3 |     result.as_str()
-  |     ^^^^^^ does not live long enough
-4 | }
-  | - borrowed value only lives until here
-  |
-note: borrowed value must be valid for the lifetime 'a as defined on the
-function body at 1:1...
- --> src/main.rs:1:1
-  |
-1 | / fn longest<'a>(x: &str, y: &str) -> &'a str {
-2 | |     let result = String::from("really long string");
-3 | |     result.as_str()
-4 | | }
-  | |_^
-```
-
-The problem is that `result` goes out of scope and gets cleaned up at the end
-of the `longest` function. We’re also trying to return a reference to `result`
-from the function. There is no way we can specify lifetime parameters that
-would change the dangling reference, and Rust won’t let us create a dangling
-reference. In this case, the best fix would be to return an owned data type
-rather than a reference so the calling function is then responsible for
-cleaning up the value.
-
-Ultimately, lifetime syntax is about connecting the lifetimes of various
-parameters and return values of functions. Once they’re connected, Rust has
-enough information to allow memory-safe operations and disallow operations that
-would create dangling pointers or otherwise violate memory safety.
-
-### Lifetime Annotations in Struct Definitions
-
-So far, we’ve only defined structs to hold owned types. It’s possible for
-structs to hold references, but in that case we would need to add a lifetime
-annotation on every reference in the struct’s definition. Listing 10-25 has a
-struct named `ImportantExcerpt` that holds a string slice:
-
-Filename: src/main.rs
-
-```
-struct ImportantExcerpt<'a> {
-    part: &'a str,
-}
-
-fn main() {
-    let novel = String::from("Call me Ishmael. Some years ago...");
-    let first_sentence = novel.split('.')
-        .next()
-        .expect("Could not find a '.'");
-    let i = ImportantExcerpt { part: first_sentence };
-}
-```
-
-Listing 10-25: A struct that holds a reference, so its definition needs a
-lifetime annotation
-
-This struct has one field, `part`, that holds a string slice, which is a
-reference. As with generic data types, we declare the name of the generic
-lifetime parameter inside angle brackets after the name of the struct so we can
-use the lifetime parameter in the body of the struct definition. This
-annotation means an instance of `ImportantExcerpt` can’t outlive the reference
-it holds in its `part` field.
-
-The `main` function here creates an instance of the `ImportantExcerpt` struct
-that holds a reference to the first sentence of the `String` owned by the
-variable `novel`. The data in `novel` exists before the `ImportantExcerpt`
-instance is created. In addition, `novel` doesn’t go out of scope until after
-the `ImportantExcerpt` goes out of scope, so the reference in the
-`ImportantExcerpt` instance is valid.
-
-### Lifetime Elision
-
-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, in
-Chapter 4 we had a function in the “String Slices” section, which is shown again
-in Listing 10-26, that compiled without lifetime annotations:
-
-Filename: src/lib.rs
-
-```
-fn first_word(s: &str) -> &str {
-    let bytes = s.as_bytes();
-
-    for (i, &item) in bytes.iter().enumerate() {
-        if item == b' ' {
-            return &s[0..i];
-        }
-    }
-
-    &s[..]
-}
-```
-
-Listing 10-26: A function we defined in Chapter 4 that compiled without
-lifetime annotations, even though the parameter and return type are references
-
-The reason this function compiles without lifetime annotations is historical:
-in early versions (pre-1.0) of Rust, this code wouldn’t have compiled because
-every reference needed an explicit lifetime. At that time, the function
-signature would have been written like this:
-
-```
-fn first_word<'a>(s: &'a str) -> &'a str {
-```
-
-After writing a lot of Rust code, the Rust team found that Rust programmers
-were entering the same lifetime annotations over and over in particular
-situations. These situations were predictable and followed a few deterministic
-patterns. The developers programmed these patterns into the compiler’s code so
-the borrow checker could infer the lifetimes in these situations and not need
-explicit annotations.
-
-This piece of Rust history is relevant because it’s possible that more
-deterministic patterns will emerge and be added to the compiler. In the future,
-even fewer lifetime annotations might be required.
-
-The patterns programmed into Rust’s analysis of references are called the
-*lifetime elision rules*. These aren’t rules for programmers to follow; they’re
-a set of particular cases that the compiler will consider, and if your code
-fits these cases, you don’t need to write the lifetimes explicitly.
-
-The elision rules don’t provide full inference. If Rust deterministically
-applies the rules but there is still ambiguity as to what lifetimes the
-references have, the compiler won’t guess what the lifetime of the remaining
-references should be. In this case, instead of guessing, the compiler will give
-you an error that you can resolve by adding the lifetime annotations that
-specify how the references relate to each other.
-
-Lifetimes on function or method parameters are called *input lifetimes*, and
-lifetimes on return values are called *output lifetimes*.
-
-The compiler uses three rules to figure out what lifetimes references have when
-there aren’t explicit annotations. The first rule applies to input lifetimes,
-and the second and third rules apply to output lifetimes. If the compiler gets
-to the end of the three rules and there are still references for which it can’t
-figure out lifetimes, the compiler will stop with an error.
-
-The first rule is that each parameter that is a reference gets its own lifetime
-parameter. In other words, a function with one parameter gets one lifetime
-parameter: `fn foo<'a>(x: &'a i32)`; a function with two parameters gets two
-separate lifetime parameters: `fn foo<'a, 'b>(x: &'a i32, y: &'b i32)`; and so
-on.
-
-The second rule is if there is exactly one input lifetime parameter, that
-lifetime is assigned to all output lifetime parameters: `fn foo<'a>(x: &'a i32)
--> &'a i32`.
-
-The third rule is if there are multiple input lifetime parameters, but one of
-them is `&self` or `&mut self` because this is a method, the lifetime of `self`
-is assigned to all output lifetime parameters. This third rule makes methods
-much nicer to read and write because fewer symbols are necessary.
-
-Let’s pretend we’re the compiler. We’ll apply these rules to figure out what
-the lifetimes of the references in the signature of the `first_word` function
-in Listing 10-26 are. The signature starts without any lifetimes associated
-with the references:
-
-```
-fn first_word(s: &str) -> &str {
-```
-
-Then the compiler applies the first rule, which specifies that each parameter
-gets its own lifetime. We’ll call it `'a` as usual, so now the signature is:
-
-```
-fn first_word<'a>(s: &'a str) -> &str {
-```
-
-The second rule applies because there is exactly one input lifetime. The second
-rule specifies that the lifetime of the one input parameter gets assigned to
-the output lifetime, so the signature is now this:
-
-```
-fn first_word<'a>(s: &'a str) -> &'a str {
-```
-
-Now all the references in this function signature have lifetimes, and the
-compiler can continue its analysis without needing the programmer to annotate
-the lifetimes in this function signature.
-
-Let’s look at another example, this time using the `longest` function that had
-no lifetime parameters when we started working with it in Listing 10-21:
-
-```
-fn longest(x: &str, y: &str) -> &str {
-```
-
-Let’s apply the first rule: each parameter gets its own lifetime. This time we
-have two parameters instead of one, so we have two lifetimes:
-
-```
-fn longest<'a, 'b>(x: &'a str, y: &'b str) -> &str {
-```
-
-You can see that the second rule doesn’t apply because there is more than one
-input lifetime. The third rule doesn’t apply either, because `longest` is a
-function rather than a method, so none of the parameters are `self`. After
-working through all three rules, we still haven’t figured out what the return
-type’s lifetime is. This is why we got an error trying to compile the code in
-Listing 10-21: the compiler worked through the lifetime elision rules but still
-couldn’t figure out all the lifetimes of the references in the signature.
-
-Because the third rule really only applies in method signatures, we’ll look at
-lifetimes in that context next to see why the third rule means we don’t have to
-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 shown in 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.
-
-Lifetime names for struct fields always need to be declared after the `impl`
-keyword and then used after the struct’s name, because those lifetimes are part
-of the struct’s type.
-
-In method signatures inside the `impl` block, references might be tied to the
-lifetime of references in the struct’s fields, or they might be independent. In
-addition, the lifetime elision rules often make it so that lifetime annotations
-aren’t necessary in method signatures. Let’s look at some examples using the
-struct named `ImportantExcerpt` that we defined in Listing 10-25.
-
-First, we’ll use a method named `level` whose only parameter is a reference to
-`self` and whose return value is an `i32`, which is not a reference to anything:
-
-```
-impl<'a> ImportantExcerpt<'a> {
-    fn level(&self) -> i32 {
-        3
-    }
-}
-```
-
-The lifetime parameter declaration after `impl` and use after the type name is
-required, but we’re not required to annotate the lifetime of the reference to
-`self` because of the first elision rule.
-
-Here is an example where the third lifetime elision rule applies:
-
-```
-impl<'a> ImportantExcerpt<'a> {
-    fn announce_and_return_part(&self, announcement: &str) -> &str {
-        println!("Attention please: {}", announcement);
-        self.part
-    }
-}
-```
-
-There are two input lifetimes, so Rust applies the first lifetime elision rule
-and gives both `&self` and `announcement` their own lifetimes. Then, because
-one of the parameters is `&self`, the return type gets the lifetime of `&self`,
-and all lifetimes have been accounted for.
-
-### The Static Lifetime
-
-One special lifetime we need to discuss is `'static`, which denotes the entire
-duration of the program. All string literals have the `'static` lifetime, which
-we can annotate as follows: `let s: &'static str = "I have a static
-lifetime.";`.
-
-The text of this string is stored directly in the binary of your program, which
-is always available. Therefore, the lifetime of all string literals is
-`'static`.
-
-You might see suggestions to use the `'static` lifetime in error messages. But
-before specifying `'static` as the lifetime for a reference, think about
-whether the reference you have actually lives the entire lifetime of your
-program or not. You might consider whether you want it to live that long, even
-if it could. Most of the time, the problem results from attempting to create a
-dangling reference or a mismatch of the available lifetimes. In such cases, the
-solution is fixing those problems, not specifying the `'static` lifetime.
-
-## Generic Type Parameters, Trait Bounds, and Lifetimes Together
-
-Let’s briefly look at the syntax of specifying generic type parameters, trait
-bounds, and lifetimes all in one function!
-
-```
-use std::fmt::Display;
-
-fn longest_with_an_announcement<'a, T>(x: &'a str, y: &'a str, ann: T) -> &'a
-str
-    where T: Display
-{
-    println!("Announcement! {}", ann);
-    if x.len() > y.len() {
-        x
-    } else {
-        y
-    }
-}
-```
-
-This is the `longest` function from Listing 10-22 that returns the longer of
-two string slices. But now it has an extra parameter named `ann` of the generic
-type `T`, which can be filled in by any type that implements the `Display`
-trait as specified by the `where` clause. This extra parameter will be printed
-before the function compares the lengths of the string slices, which is why the
-`Display` trait bound is necessary. Because lifetimes are a type of generic,
-the declarations of the lifetime parameter `'a` and the generic type parameter
-`T` go in the same list inside the angle brackets after the function name.
-
-## Summary
-
-We covered a lot in this chapter! Now that you know about generic type
-parameters, traits and trait bounds, and generic lifetime parameters, you’re
-ready to write code without repetition that works in many different situations.
-Generic type parameters let you apply the code to different types. Traits and
-trait bounds ensure that even though the types are generic, they’ll have the
-behavior the code needs. You learned how to use lifetime annotations to ensure
-that this flexible code won’t have any dangling references. And all of this
-analysis happens at compile time, which doesn’t affect runtime performance!
-
-Believe it or not, there is much more to learn on the topics we discussed in
-this chapter: Chapter 17 discusses trait objects, which are another way to use
-traits. Chapter 19 covers more complex scenarios involving lifetime annotations
-as well as some advanced type system features. But in the next chapter, you’ll
-learn how to write tests in Rust so you can make sure your code is working the
-way it should.
diff --git a/src/doc/book/second-edition/nostarch/chapter11.md b/src/doc/book/second-edition/nostarch/chapter11.md
deleted file mode 100644
index b05c05ea80..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter11.md
+++ /dev/null
@@ -1,1442 +0,0 @@
-
-[TOC]
-
-# Writing Automated Tests
-
-In his 1972 essay “The Humble Programmer,” Edsger W. Dijkstra said that
-“Program testing can be a very effective way to show the presence of bugs, but
-it is hopelessly inadequate for showing their absence.” That doesn’t mean we
-shouldn’t try to test as much as we can!
-
-Correctness in our programs is the extent to which our code does what we intend
-it to do. Rust is designed with a high degree of concern about the correctness
-of programs, but correctness is complex and not easy to prove. Rust’s type
-system shoulders a huge part of this burden, but the type system cannot catch
-every kind of incorrectness. As such, Rust includes support for writing
-automated software tests within the language.
-
-As an example, say we write a function called `add_two` that adds 2 to whatever
-number is passed to it. This function’s signature accepts an integer as a
-parameter and returns an integer as a result. When we implement and compile
-that function, Rust does all the type checking and borrow checking that you’ve
-learned so far to ensure that, for instance, we aren’t passing a `String` value
-or an invalid reference to this function. But Rust *can’t* check that this
-function will do precisely what we intend, which is return the parameter plus 2
-rather than, say, the parameter plus 10 or the parameter minus 50! That’s where
-tests come in.
-
-We can write tests that assert, for example, that when we pass `3` to the
-`add_two` function, the returned value is `5`. We can run these tests whenever
-we make changes to our code to make sure any existing correct behavior has not
-changed.
-
-Testing is a complex skill: although we can’t cover every detail about how to
-write good tests in one chapter, we’ll discuss the mechanics of Rust’s testing
-facilities. We’ll talk about the annotations and macros available to you when
-writing your tests, the default behavior and options provided for running your
-tests, and how to organize tests into unit tests and integration tests.
-
-## How to Write Tests
-
-Tests are Rust functions that verify that the non-test code is functioning in
-the expected manner. The bodies of test functions typically perform these three
-actions:
-
-1. Set up any needed data or state.
-2. Run the code you want to test.
-3. Assert the results are what you expect.
-
-Let’s look at the features Rust provides specifically for writing tests that
-take these actions, which include the `test` attribute, a few macros, and the
-`should_panic` attribute.
-
-### The Anatomy of a Test Function
-
-At its simplest, a test in Rust is a function that’s annotated with the `test`
-attribute. Attributes are metadata about pieces of Rust code; one example is
-the `derive` attribute we used with structs in Chapter 5. To change a function
-into a test function, add `#[test]` on the line before `fn`. When you run your
-tests with the `cargo test` command, Rust builds a test runner binary that runs
-the functions annotated with the `test` attribute and reports on whether each
-test function passes or fails.
-
-In Chapter 7, we saw that when we make a new library project with Cargo, a test
-module with a test function in it is automatically generated for us. This
-module helps you start writing your tests so you don’t have to look up the
-exact structure and syntax of test functions every time you start a new
-project. You can add as many additional test functions and as many test modules
-as you want!
-
-We’ll explore some aspects of how tests work by experimenting with the template
-test generated for us without actually testing any code. Then we’ll write some
-real-world tests that call some code that we’ve written and assert that its
-behavior is correct.
-
-Let’s create a new library project called `adder`:
-
-```
-$ cargo new adder --lib
-     Created library `adder` project
-$ cd adder
-```
-
-The contents of the *src/lib.rs* file in your `adder` library should look like
-Listing 11-1:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn it_works() {
-        assert_eq!(2 + 2, 4);
-    }
-}
-```
-
-Listing 11-1: The test module and function generated automatically by `cargo
-new`
-
-For now, let’s ignore the top two lines and focus on the function to see how it
-works. Note the `#[test]` annotation before the `fn` line: this attribute
-indicates this is a test function, so the test runner knows to treat this
-function as a test. We could also have non-test functions in the `tests` module
-to help set up common scenarios or perform common operations, so we need to
-indicate which functions are tests by using the `#[test]` attribute.
-
-The function body uses the `assert_eq!` macro to assert that 2 + 2 equals 4.
-This assertion serves as an example of the format for a typical test. Let’s run
-it to see that this test passes.
-
-The `cargo test` command runs all tests in our project, as shown in Listing
-11-2:
-
-```
-$ cargo test
-   Compiling adder v0.1.0 (file:///projects/adder)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.22 secs
-     Running target/debug/deps/adder-ce99bcc2479f4607
-
-running 1 test
-test tests::it_works ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-   Doc-tests adder
-
-running 0 tests
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Listing 11-2: The output from running the automatically generated test
-
-Cargo compiled and ran the test. After the `Compiling`, `Finished`, and
-`Running` lines is the line `running 1 test`. The next line shows the name
-of the generated test function, called `it_works`, and the result of running
-that test, `ok`. The overall summary of running the tests appears next. The
-text `test result: ok.` means that all the tests passed, and the portion that
-reads `1 passed; 0 failed` totals the number of tests that passed or failed.
-
-Because we don’t have any tests we’ve marked as ignored, the summary shows `0
-ignored`. We also haven’t filtered the tests being run, so the end of the
-summary shows `0 filtered out`. We’ll talk about ignoring and filtering out
-tests in the next section, “Controlling How Tests Are Run.”
-
-The `0 measured` statistic is for benchmark tests that measure performance.
-Benchmark tests are, as of this writing, only available in nightly Rust. See
-the documentation about benchmark tests at
-*https://doc.rust-lang.org/nightly/unstable-book/library-features/test.html* to
-learn more.
-
-The next part of the test output, which starts with `Doc-tests adder`, is for
-the results of any documentation tests. We don’t have any documentation tests
-yet, but Rust can compile any code examples that appear in our API
-documentation. This feature helps us keep our docs and our code in sync! We’ll
-discuss how to write documentation tests in the “Documentation Comments”
-section of Chapter 14. For now, we’ll ignore the `Doc-tests` output.
-
-Let’s change the name of our test to see how that changes the test output.
-Change the `it_works` function to a different name, such as `exploration`, like
-so:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn exploration() {
-        assert_eq!(2 + 2, 4);
-    }
-}
-```
-
-Then run `cargo test` again. The output now shows `exploration` instead of
-`it_works`:
-
-```
-running 1 test
-test tests::exploration ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Let’s add another test, but this time we’ll make a test that fails! Tests fail
-when something in the test function panics. Each test is run in a new thread,
-and when the main thread sees that a test thread has died, the test is marked
-as failed. We talked about the simplest way to cause a panic in Chapter 9,
-which is to call the `panic!` macro. Enter the new test, `another`, so your
-*src/lib.rs* file looks like Listing 11-3:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn exploration() {
-        assert_eq!(2 + 2, 4);
-    }
-
-    #[test]
-    fn another() {
-        panic!("Make this test fail");
-    }
-}
-```
-
-Listing 11-3: Adding a second test that will fail because we call the `panic!`
-macro
-
-Run the tests again using `cargo test`. The output should look like Listing
-11-4, which shows that our `exploration` test passed and `another` failed:
-
-```
-running 2 tests
-test tests::exploration ... ok
-test tests::another ... FAILED
-
-failures:
-
----- tests::another stdout ----
-    thread 'tests::another' panicked at 'Make this test fail', src/lib.rs:10:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-
-failures:
-    tests::another
-
-test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-
-error: test failed
-```
-
-Listing 11-4: Test results when one test passes and one test fails
-
-Instead of `ok`, the line `test tests::another` shows `FAILED`. Two new
-sections appear between the individual results and the summary: the first
-section displays the detailed reason for each test failure. In this case,
-`another` failed because it `panicked at 'Make this test fail'`, which happened
-on line 10 in the *src/lib.rs* file. The next section lists just the names of
-all the failing tests, which is useful when there are lots of tests and lots of
-detailed failing test output. We can use the name of a failing test to run just
-that test to more easily debug it; we’ll talk more about ways to run tests in
-the “Controlling How Tests Are Run” section.
-
-The summary line displays at the end: overall, our test result is `FAILED`.
-We had one test pass and one test fail.
-
-Now that you’ve seen what the test results look like in different scenarios,
-let’s look at some macros other than `panic!` that are useful in tests.
-
-### Checking Results with the `assert!` Macro
-
-The `assert!` macro, provided by the standard library, is useful when you want
-to ensure that some condition in a test evaluates to `true`. We give the
-`assert!` macro an argument that evaluates to a Boolean. If the value is
-`true`, `assert!` does nothing and the test passes. If the value is `false`,
-the `assert!` macro calls the `panic!` macro, which causes 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, we used a `Rectangle` struct and a `can_hold`
-method, which are repeated here in Listing 11-5. Let’s put this code in the
-*src/lib.rs* file and write some tests for it using the `assert!` macro.
-
-Filename: src/lib.rs
-
-```
-#[derive(Debug)]
-pub struct Rectangle {
-    length: u32,
-    width: u32,
-}
-
-impl Rectangle {
-    pub fn can_hold(&self, other: &Rectangle) -> bool {
-        self.length > other.length && self.width > other.width
-    }
-}
-```
-
-Listing 11-5: Using the `Rectangle` struct and its `can_hold` method from
-Chapter 5
-
-The `can_hold` method returns a Boolean, which means it’s a perfect use case
-for the `assert!` macro. In Listing 11-6, we write a test that exercises the
-`can_hold` method by creating a `Rectangle` instance that has a length of 8 and
-a width of 7 and asserting that it can hold another `Rectangle` instance that
-has a length of 5 and a width of 1:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn larger_can_hold_smaller() {
-        let larger = Rectangle { length: 8, width: 7 };
-        let smaller = Rectangle { length: 5, width: 1 };
-
-        assert!(larger.can_hold(&smaller));
-    }
-}
-```
-
-Listing 11-6: A test for `can_hold` that checks whether a larger rectangle can
-indeed hold a smaller rectangle
-
-Note that we’ve added a new line inside the `tests` module: `use super::*;`.
-The `tests` module is a regular module that follows the usual visibility rules
-we covered in Chapter 7 in the “Privacy Rules” section. Because the `tests`
-module is an inner module, we need to bring the code under test in the outer
-module into the scope of the inner module. We use a glob here so anything we
-define in the outer module is available to this `tests` module.
-
-We’ve named our test `larger_can_hold_smaller`, and we’ve created the two
-`Rectangle` instances that we need. Then we called the `assert!` macro and
-passed it the result of calling `larger.can_hold(&smaller)`. This expression
-is supposed to return `true`, so our test should pass. Let’s find out!
-
-```
-running 1 test
-test tests::larger_can_hold_smaller ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-It does pass! Let’s add another test, this time asserting that a smaller
-rectangle cannot hold a larger rectangle:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn larger_can_hold_smaller() {
-        // --snip--
-    }
-
-    #[test]
-    fn smaller_cannot_hold_larger() {
-        let larger = Rectangle { length: 8, width: 7 };
-        let smaller = Rectangle { length: 5, width: 1 };
-
-        assert!(!smaller.can_hold(&larger));
-    }
-}
-```
-
-Because the correct result of the `can_hold` function in this case is `false`,
-we need to negate that result before we pass it to the `assert!` macro. As a
-result, our test will pass if `can_hold` returns `false`:
-
-```
-running 2 tests
-test tests::smaller_cannot_hold_larger ... ok
-test tests::larger_can_hold_smaller ... ok
-
-test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Two tests that pass! Now let’s see what happens to our test results when we
-introduce a bug in our code. Let’s change the implementation of the `can_hold`
-method by replacing the greater-than sign with a less-than sign when it
-compares the lengths:
-
-```
-// --snip--
-
-impl Rectangle {
-    pub fn can_hold(&self, other: &Rectangle) -> bool {
-        self.length < other.length && self.width > other.width
-    }
-}
-```
-
-Running the tests now produces the following:
-
-```
-running 2 tests
-test tests::smaller_cannot_hold_larger ... ok
-test tests::larger_can_hold_smaller ... FAILED
-
-failures:
-
----- tests::larger_can_hold_smaller stdout ----
-    thread 'tests::larger_can_hold_smaller' panicked at 'assertion failed:
-    larger.can_hold(&smaller)', src/lib.rs:22:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-
-failures:
-    tests::larger_can_hold_smaller
-
-test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Our tests caught the bug! Because `larger.length` is 8 and `smaller.length` is
-5, the comparison of the lengths in `can_hold` now returns `false`: 8 is not
-less than 5.
-
-### Testing Equality with the `assert_eq!` and `assert_ne!` Macros
-
-A common way to test functionality is to compare the result of the code under
-test to the value you expect the code to return to make sure they’re equal. You
-could do this using the `assert!` macro and passing it an expression using the
-`==` operator. However, this is such a common test that the standard library
-provides a pair of macros—`assert_eq!` and `assert_ne!`—to perform this test
-more conveniently. These macros compare two arguments for equality or
-inequality, respectively. They’ll also print the two values if the assertion
-fails, which makes it easier to see *why* the test failed; conversely, the
-`assert!` macro only indicates that it got a `false` value for the `==`
-expression, not the values that lead to the `false` value.
-
-In Listing 11-7, we write a function named `add_two` that adds `2` to its
-parameter and returns the result. Then we test this function using the
-`assert_eq!` macro.
-
-Filename: src/lib.rs
-
-```
-pub fn add_two(a: i32) -> i32 {
-    a + 2
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn it_adds_two() {
-        assert_eq!(4, add_two(2));
-    }
-}
-```
-
-Listing 11-7: Testing the function `add_two` using the `assert_eq!` macro
-
-Let’s check that it passes!
-
-```
-running 1 test
-test tests::it_adds_two ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-The first argument we gave to the `assert_eq!` macro, `4`, is equal to the
-result of calling `add_two(2)`. The line for this test is `test
-tests::it_adds_two ... ok`, and the `ok` text indicates that our test passed!
-
-Let’s introduce a bug into our code to see what it looks like when a test that
-uses `assert_eq!` fails. Change the implementation of the `add_two` function to
-instead add `3`:
-
-```
-pub fn add_two(a: i32) -> i32 {
-    a + 3
-}
-```
-
-Run the tests again:
-
-```
-running 1 test
-test tests::it_adds_two ... FAILED
-
-failures:
-
----- tests::it_adds_two stdout ----
-        thread 'tests::it_adds_two' panicked at 'assertion failed: `(left == right)`
-  left: `4`,
- right: `5`', src/lib.rs:11:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-
-failures:
-    tests::it_adds_two
-
-test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Our test caught the bug! The `it_adds_two` test failed, displaying the message
-`` assertion failed: `(left == right)` `` and showing that `left` was `4` and
-`right` was `5`. This message is useful and helps us start debugging: it means
-the `left` argument to `assert_eq!` was `4` but the `right` argument, where we
-had `add_two(2)`, was `5`.
-
-Note that in some languages and test frameworks, the parameters to the
-functions that assert two values are equal are called `expected` and `actual`,
-and the order in which we specify the arguments matters. However, in Rust,
-they’re called `left` and `right`, and the order in which we specify the value
-we expect and the value that the code under test produces doesn’t matter. We
-could write the assertion in this test as `assert_eq!(add_two(2), 4)`, which
-would result in a failure message that displays `` assertion failed: `(left ==
-right)` `` and that `left` was `5` and `right` was `4`.
-
-The `assert_ne!` macro will pass if the two values we give it are not equal and
-fail if they’re equal. This macro is most useful for cases when we’re not sure
-what a value *will* be, but we know what the value definitely *won’t* be if our
-code is functioning as we intend. For example, if we’re testing a function that
-is guaranteed to change its input in some way, but the way in which the input
-is changed depends on the day of the week that we run our tests, the best thing
-to assert might be that the output of the function is not equal to the input.
-
-Under the surface, the `assert_eq!` and `assert_ne!` macros use the operators
-`==` and `!=`, respectively. When the assertions fail, these macros print their
-arguments using debug formatting, which means the values being compared must
-implement the `PartialEq` and `Debug` traits. All the primitive types and most
-of the standard library types implement these traits. For structs and enums
-that you define, you’ll need to implement `PartialEq` to assert that values of
-those types are equal or not equal. You’ll need to implement `Debug` to print
-the values when the assertion fails. Because both traits are derivable traits,
-as mentioned in 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,” for more details about these
-and other derivable traits.
-
-### Adding Custom Failure Messages
-
-You can also add a custom message to be printed with the failure message as
-optional arguments to the `assert!`, `assert_eq!`, and `assert_ne!` macros. Any
-arguments specified after the one required argument to `assert!` or the two
-required arguments to `assert_eq!` and `assert_ne!` are passed along to the
-`format!` macro (discussed in Chapter 8 in the “Concatenation with the `+`
-Operator or the `format!` Macro” section), so you can pass a format string that
-contains `{}` placeholders and values to go in those placeholders. Custom
-messages are useful to document what an assertion means; when a test fails,
-you’ll have a better idea of what the problem is with the code.
-
-For example, let’s say we have a function that greets people by name and we
-want to test that the name we pass into the function appears in the output:
-
-Filename: src/lib.rs
-
-```
-pub fn greeting(name: &str) -> String {
-    format!("Hello {}!", name)
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn greeting_contains_name() {
-        let result = greeting("Carol");
-        assert!(result.contains("Carol"));
-    }
-}
-```
-
-The requirements for this program haven’t been agreed upon yet, and we’re
-pretty sure the `Hello` text at the beginning of the greeting will change. We
-decided we don’t want to have to update the test when the requirements change,
-so instead of checking for exact equality to the value returned from the
-`greeting` function, we’ll just assert that the output contains the text of the
-input parameter.
-
-Let’s introduce a bug into this code by changing `greeting` to not include
-`name` to see what this test failure looks like:
-
-```
-pub fn greeting(name: &str) -> String {
-    String::from("Hello!")
-}
-```
-
-Running this test produces the following:
-
-```
-running 1 test
-test tests::greeting_contains_name ... FAILED
-
-failures:
-
----- tests::greeting_contains_name stdout ----
-        thread 'tests::greeting_contains_name' panicked at 'assertion failed:
-result.contains("Carol")', src/lib.rs:12:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-
-failures:
-    tests::greeting_contains_name
-```
-
-This result just indicates that the assertion failed and which line the
-assertion is on. A more useful failure message in this case would print the
-value we got from the `greeting` function. Let’s change the test function,
-giving it a custom failure message made from a format string with a placeholder
-filled in with the actual value we got from the `greeting` function:
-
-```
-#[test]
-fn greeting_contains_name() {
-    let result = greeting("Carol");
-    assert!(
-        result.contains("Carol"),
-        "Greeting did not contain name, value was `{}`", result
-    );
-}
-```
-
-Now when we run the test, we’ll get a more informative error message:
-
-```
----- tests::greeting_contains_name stdout ----
-        thread 'tests::greeting_contains_name' panicked at 'Greeting did not
-contain name, value was `Hello!`', src/lib.rs:12:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-```
-
-We can see the value we actually got in the test output, which would help us
-debug what happened instead of what we were expecting to happen.
-
-### Checking for Panics with `should_panic`
-
-In addition to checking that our code returns the correct values we expect,
-it’s also 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-9. 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.
-
-We do this by adding another attribute, `should_panic`, to our test function.
-This attribute makes a test pass if the code inside the function panics; the
-test will fail if the code inside the function doesn’t panic.
-
-Listing 11-8 shows a test that checks that the error conditions of `Guess::new`
-happen when we expect them to:
-
-Filename: src/lib.rs
-
-```
-pub struct Guess {
-    value: u32,
-}
-
-impl Guess {
-    pub fn new(value: u32) -> Guess {
-        if value < 1 || value > 100 {
-            panic!("Guess value must be between 1 and 100, got {}.", value);
-        }
-
-        Guess {
-            value
-        }
-    }
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    #[should_panic]
-    fn greater_than_100() {
-        Guess::new(200);
-    }
-}
-```
-
-Listing 11-8: Testing that a condition will cause a `panic!`
-
-We place the `#[should_panic]` attribute after the `#[test]` attribute and
-before the test function it applies to. Let’s look at the result when this test
-passes:
-
-```
-running 1 test
-test tests::greater_than_100 ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Looks good! Now let’s introduce a bug in our code by removing the condition
-that the `new` function will panic if the value is greater than 100:
-
-```
-// --snip--
-
-impl Guess {
-    pub fn new(value: u32) -> Guess {
-        if value < 1  {
-            panic!("Guess value must be between 1 and 100, got {}.", value);
-        }
-
-        Guess {
-            value
-        }
-    }
-}
-```
-
-When we run the test in Listing 11-8, it will fail:
-
-```
-running 1 test
-test tests::greater_than_100 ... FAILED
-
-failures:
-
-failures:
-    tests::greater_than_100
-
-test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-We don’t get a very helpful message in this case, but when we look at the test
-function, we see that it’s annotated with `#[should_panic]`. The failure we got
-means that the code in the test function did not cause a panic.
-
-Tests that use `should_panic` can be imprecise because they only indicate that
-the code has caused some panic. A `should_panic` test would pass even if the
-test panics for a different reason than the one we were expecting to happen. To
-make `should_panic` tests more precise, we can add an optional `expected`
-parameter to the `should_panic` attribute. The test harness will make sure that
-the failure message contains the provided text. For example, consider the
-modified code for `Guess` in Listing 11-9 where the `new` function panics with
-different messages depending on whether the value is too small or too large:
-
-Filename: src/lib.rs
-
-```
-// --snip--
-
-impl Guess {
-    pub fn new(value: u32) -> Guess {
-        if value < 1 {
-            panic!("Guess value must be greater than or equal to 1, got {}.",
-                   value);
-        } else if value > 100 {
-            panic!("Guess value must be less than or equal to 100, got {}.",
-                   value);
-        }
-
-        Guess {
-            value
-        }
-    }
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    #[should_panic(expected = "Guess value must be less than or equal to 100")]
-    fn greater_than_100() {
-        Guess::new(200);
-    }
-}
-```
-
-Listing 11-9: Testing that a condition will cause a `panic!` with a particular
-panic message
-
-This test will pass because the value we put in the `should_panic` attribute’s
-`expected` parameter is a substring of the message that the `Guess::new`
-function panics with. We could have specified the entire panic message that we
-expect, which in this case would be `Guess value must be less than or equal to
-100, got 200.` What you choose to specify in the expected parameter for
-`should_panic` depends on how much of the panic message is unique or dynamic
-and how precise you want your test to be. In this case, a substring of the
-panic message is enough to ensure that the code in the test function executes
-the `else if value > 100` case.
-
-To see what happens when a `should_panic` test with an `expected` message
-fails, let’s again introduce a bug into our code by swapping the bodies of the
-`if value < 1` and the `else if value > 100` blocks:
-
-```
-if value < 1 {
-    panic!("Guess value must be less than or equal to 100, got {}.", value);
-} else if value > 100 {
-    panic!("Guess value must be greater than or equal to 1, got {}.", value);
-}
-```
-
-This time when we run the `should_panic` test, it will fail:
-
-```
-running 1 test
-test tests::greater_than_100 ... FAILED
-
-failures:
-
----- tests::greater_than_100 stdout ----
-        thread 'tests::greater_than_100' panicked at 'Guess value must be
-greater than or equal to 1, got 200.', src/lib.rs:11:12
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-note: Panic did not include expected string 'Guess value must be less than or
-equal to 100'
-
-failures:
-    tests::greater_than_100
-
-test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-The failure message indicates that this test did indeed panic as we expected,
-but the panic message did not include the expected string `'Guess value must be
-less than or equal to 100'`. The panic message that we did get in this case was
-`Guess value must be greater than or equal to 1, got 200.` Now we can start
-figuring out where our bug is!
-
-Now that you know several ways to write tests, let’s look at what is happening
-when we run our tests and explore the different options we can use with `cargo
-test`.
-
-## Controlling How Tests Are Run
-
-Just as `cargo run` compiles your code and then runs the resulting binary,
-`cargo test` compiles your code in test mode and runs the resulting test
-binary. You can specify command line options to change the default behavior of
-`cargo test`. For example, the default behavior of the binary produced by
-`cargo test` is to run all the tests in parallel and capture output generated
-during test runs, preventing the output from being displayed and making it
-easier to read the output related to the test results.
-
-Some command line options go to `cargo test`, and some go to the resulting test
-binary. To separate these two types of arguments, you list the arguments that
-go to `cargo test` followed by the separator `--` and then the ones that go to
-the test binary. Running `cargo test --help` displays the options you can use
-with `cargo test`, and running `cargo test -- --help` displays the options you
-can use after the separator `--`.
-
-### Running Tests in Parallel or Consecutively
-
-When you run multiple tests, by default they run in parallel using threads.
-This means the tests will finish running faster so you can get feedback quicker
-on whether or not your code is working. Because the tests are running at the
-same time, make sure your tests don’t depend on each other or on any shared
-state, including a shared environment, such as the current working directory or
-environment variables.
-
-For example, say each of your tests runs some code that creates a file on disk
-named *test-output.txt* and writes some data to that file. Then each test reads
-the data in that file and asserts that the file contains a particular value,
-which is different in each test. Because the tests run at the same time, one
-test might overwrite the file between when another test writes and reads the
-file. The second test will then fail, not because the code is incorrect but
-because the tests have interfered with each other while running in parallel.
-One solution is to make sure each test writes to a different file; another
-solution is to run the tests one at a time.
-
-If you don’t want to run the tests in parallel or if you want more fine-grained
-control over the number of threads used, you can send the `--test-threads` flag
-and the number of threads you want to use to the test binary. Take a look at
-the following example:
-
-```
-$ cargo test -- --test-threads=1
-```
-
-We set the number of test threads to `1`, telling the program not to use any
-parallelism. Running the tests using one thread will take longer than running
-them in parallel, but the tests won’t interfere with each other if they share
-state.
-
-### Showing Function Output
-
-By default, if a test passes, Rust’s test library captures anything printed to
-standard output. For example, if we call `println!` in a test and the test
-passes, we won’t see the `println!` output in the terminal; we’ll see only the
-line that indicates the test passed. If a test fails, we’ll see whatever was
-printed to standard output with the rest of the failure message.
-
-As an example, Listing 11-10 has a silly function that prints the value of its
-parameter and returns 10, as well as a test that passes and a test that fails.
-
-Filename: src/lib.rs
-
-```
-fn prints_and_returns_10(a: i32) -> i32 {
-    println!("I got the value {}", a);
-    10
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn this_test_will_pass() {
-        let value = prints_and_returns_10(4);
-        assert_eq!(10, value);
-    }
-
-    #[test]
-    fn this_test_will_fail() {
-        let value = prints_and_returns_10(8);
-        assert_eq!(5, value);
-    }
-}
-```
-
-Listing 11-10: Tests for a function that calls `println!`
-
-When we run these tests with `cargo test`, we’ll see the following output:
-
-```
-running 2 tests
-test tests::this_test_will_pass ... ok
-test tests::this_test_will_fail ... FAILED
-
-failures:
-
----- tests::this_test_will_fail stdout ----
-        I got the value 8
-thread 'tests::this_test_will_fail' panicked at 'assertion failed: `(left == right)`
-  left: `5`,
- right: `10`', src/lib.rs:19:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-
-failures:
-    tests::this_test_will_fail
-
-test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Note that nowhere in this output do we see `I got the value 4`, which is what
-is printed when the test that passes runs. That output has been captured. The
-output from the test that failed, `I got the value 8`, appears in the section
-of the test summary output, which also shows the cause of the test failure.
-
-If we want to see printed values for passing tests as well, we can disable the
-output capture behavior by using the `--nocapture` flag:
-
-```
-$ cargo test -- --nocapture
-```
-
-When we run the tests in Listing 11-10 again with the `--nocapture` flag, we
-see the following output:
-
-```
-running 2 tests
-I got the value 4
-I got the value 8
-test tests::this_test_will_pass ... ok
-thread 'tests::this_test_will_fail' panicked at 'assertion failed: `(left == right)`
-  left: `5`,
- right: `10`', src/lib.rs:19:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-test tests::this_test_will_fail ... FAILED
-
-failures:
-
-failures:
-    tests::this_test_will_fail
-
-test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Note that the output for the tests and the test results are interleaved; the
-reason is that the tests are running in parallel, as we talked about in the
-previous section. Try using the `--test-threads=1` option and the `--nocapture`
-flag, and see what the output looks like then!
-
-### Running a Subset of Tests by Name
-
-Sometimes, running a full test suite can take a long time. If you’re working on
-code in a particular area, you might want to run only the tests pertaining to
-that code. You can choose which tests to run by passing `cargo test` the name
-or names of the test(s) you want to run as an argument.
-
-To demonstrate how to run a subset of tests, we’ll create three tests for our
-`add_two` function, as shown in Listing 11-11, and choose which ones to run:
-
-Filename: src/lib.rs
-
-```
-pub fn add_two(a: i32) -> i32 {
-    a + 2
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn add_two_and_two() {
-        assert_eq!(4, add_two(2));
-    }
-
-    #[test]
-    fn add_three_and_two() {
-        assert_eq!(5, add_two(3));
-    }
-
-    #[test]
-    fn one_hundred() {
-        assert_eq!(102, add_two(100));
-    }
-}
-```
-
-Listing 11-11: Three tests with three different names
-
-If we run the tests without passing any arguments, as we saw earlier, all the
-tests will run in parallel:
-
-```
-running 3 tests
-test tests::add_two_and_two ... ok
-test tests::add_three_and_two ... ok
-test tests::one_hundred ... ok
-
-test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-#### Running Single Tests
-
-We can pass the name of any test function to `cargo test` to run only that test:
-
-```
-$ cargo test one_hundred
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running target/debug/deps/adder-06a75b4a1f2515e9
-
-running 1 test
-test tests::one_hundred ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 2 filtered out
-```
-
-Only the test with the name `one_hundred` ran; the other two tests didn’t match
-that name. The test output lets us know we had more tests than what this
-command ran by displaying `2 filtered out` at the end of the summary line.
-
-We can’t specify the names of multiple tests in this way; only the first value
-given to `cargo test` will be used. But there is a way to run multiple tests.
-
-#### Filtering to Run Multiple Tests
-
-We can specify part of a test name, and any test whose name matches that value
-will be run. For example, because two of our tests’ names contain `add`, we can
-run those two by running `cargo test add`:
-
-```
-$ cargo test add
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running target/debug/deps/adder-06a75b4a1f2515e9
-
-running 2 tests
-test tests::add_two_and_two ... ok
-test tests::add_three_and_two ... ok
-
-test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out
-```
-
-This command ran all tests with `add` in the name and filtered out the test
-named `one_hundred`. Also note that the module in which tests appear becomes
-part of the test’s name, so we can run all the tests in a module by filtering
-on the module’s name.
-
-### Ignoring Some Tests Unless Specifically Requested
-
-Sometimes a few specific tests can be very time-consuming to execute, so you
-might want to exclude them during most runs of `cargo test`. Rather than
-listing as arguments all tests you do want to run, you can instead annotate the
-time-consuming tests using the `ignore` attribute to exclude them, as shown
-here:
-
-Filename: src/lib.rs
-
-```
-#[test]
-fn it_works() {
-    assert_eq!(2 + 2, 4);
-}
-
-#[test]
-#[ignore]
-fn expensive_test() {
-    // code that takes an hour to run
-}
-```
-
-After `#[test]` we add the `#[ignore]` line to the test we want to exclude. Now
-when we run our tests, `it_works` runs, but `expensive_test` doesn’t:
-
-```
-$ cargo test
-   Compiling adder v0.1.0 (file:///projects/adder)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.24 secs
-     Running target/debug/deps/adder-ce99bcc2479f4607
-
-running 2 tests
-test expensive_test ... ignored
-test it_works ... ok
-
-test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out
-```
-
-The `expensive_test` function is listed as `ignored`. If we want to run only
-the ignored tests, we can use `cargo test -- --ignored`:
-
-```
-$ cargo test -- --ignored
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running target/debug/deps/adder-ce99bcc2479f4607
-
-running 1 test
-test expensive_test ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out
-```
-
-By controlling which tests run, you can make sure your `cargo test` results
-will be fast. When you’re at a point where it makes sense to check the results
-of the `ignored` tests and you have time to wait for the results, you can run
-`cargo test -- --ignored` instead.
-
-## Test Organization
-
-As mentioned at the start of the chapter, testing is a complex discipline, and
-different people use different terminology and organization. The Rust community
-thinks about tests in terms of two main categories: *unit tests* and
-*integration tests*. Unit tests are small and more focused, testing one module
-in isolation at a time, and can test private interfaces. Integration tests are
-entirely external to your library and use your code in the same way any other
-external code would, using only the public interface and potentially exercising
-multiple modules per test.
-
-Writing both kinds of tests is important to ensure that the pieces of your
-library are doing what you expect them to separately and together.
-
-### Unit Tests
-
-The purpose of unit tests is to test each unit of code in isolation from the
-rest of the code to quickly pinpoint where code is and isn’t working as
-expected. You’ll put unit tests in the *src* directory in each file with the
-code that they’re testing. The convention is to create a module named `tests`
-in each file to contain the test functions and to annotate the module with
-`cfg(test)`.
-
-#### The Tests Module and `#[cfg(test)]`
-
-The `#[cfg(test)]` annotation on the tests module tells Rust to compile and run
-the test code only when you run `cargo test`, not when you run `cargo build`.
-This saves compile time when you only want to build the library and saves space
-in the resulting compiled artifact because the tests are not included. You’ll
-see that because integration tests go in a different directory, they don’t need
-the `#[cfg(test)]` annotation. However, because unit tests go in the same files
-as the code, you’ll use `#[cfg(test)]` to specify that they shouldn’t be
-included in the compiled result.
-
-Recall that when we generated the new `adder` project in the first section of
-this chapter, Cargo generated this code for us:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    #[test]
-    fn it_works() {
-        assert_eq!(2 + 2, 4);
-    }
-}
-```
-
-This code is the automatically generated test module. The attribute `cfg`
-stands for *configuration* and tells Rust that the following item should only
-be included given a certain configuration option. In this case, the
-configuration option is `test`, which is provided by Rust for compiling and
-running tests. By using the `cfg` attribute, Cargo compiles our test code only
-if we actively run the tests with `cargo test`. This includes any helper
-functions that might be within this module, in addition to the functions
-annotated with `#[test]`.
-
-#### Testing Private Functions
-
-There’s debate within the testing community about whether or not private
-functions should be tested directly, and other languages make it difficult or
-impossible to test private functions. Regardless of which testing ideology you
-adhere to, Rust’s privacy rules do allow you to test private functions.
-Consider the code in Listing 11-12 with the private function `internal_adder`:
-
-Filename: src/lib.rs
-
-```
-pub fn add_two(a: i32) -> i32 {
-    internal_adder(a, 2)
-}
-
-fn internal_adder(a: i32, b: i32) -> i32 {
-    a + b
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn internal() {
-        assert_eq!(4, internal_adder(2, 2));
-    }
-}
-```
-
-Listing 11-12: Testing a private function
-
-Note that the `internal_adder` function is not marked as `pub`, but because
-tests are just Rust code and the `tests` module is just another module, you can
-import and call `internal_adder` in a test just fine. If you don’t think
-private functions should be tested, there’s nothing in Rust that will compel
-you to do so.
-
-### Integration Tests
-
-In Rust, integration tests are entirely external to your library. They use your
-library in the same way any other code would, which means they can only call
-functions that are part of your library’s public API. Their purpose is to test
-whether many parts of your library work together correctly. Units of code that
-work correctly on their own could have problems when integrated, so test
-coverage of the integrated code is important as well. To create integration
-tests, you first need a *tests* directory.
-
-#### The *tests* Directory
-
-We create a *tests* directory at the top level of our project directory, next
-to *src*. Cargo knows to look for integration test files in this directory. We
-can then make as many test files as we want to in this directory, and Cargo
-will compile each of the files as an individual crate.
-
-Let’s create an integration test. With the code in Listing 11-12 still in the
-*src/lib.rs* file, make a *tests* directory, create a new file named
-*tests/integration_test.rs*, and enter the code in Listing 11-13:
-
-Filename: tests/integration_test.rs
-
-```
-extern crate adder;
-
-#[test]
-fn it_adds_two() {
-    assert_eq!(4, adder::add_two(2));
-}
-```
-
-Listing 11-13: An integration test of a function in the `adder` crate
-
-We’ve added `extern crate adder` at the top of the code, which we didn’t need
-in the unit tests. The reason is that each test in the `tests` directory is a
-separate crate, so we need to import our library into each of them.
-
-We don’t need to annotate any code in *tests/integration_test.rs* with
-`#[cfg(test)]`. Cargo treats the `tests` directory specially and compiles files
-in this directory only when we run `cargo test`. Run `cargo test` now:
-
-```
-$ cargo test
-   Compiling adder v0.1.0 (file:///projects/adder)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
-     Running target/debug/deps/adder-abcabcabc
-
-running 1 test
-test tests::internal ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-     Running target/debug/deps/integration_test-ce99bcc2479f4607
-
-running 1 test
-test it_adds_two ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-   Doc-tests adder
-
-running 0 tests
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-The three sections of output include the unit tests, the integration test, and
-the doc tests. The first section for the unit tests is the same as we’ve been
-seeing: one line for each unit test (one named `internal` that we added in
-Listing 11-12) and then a summary line for the unit tests.
-
-The integration tests section starts with the line `Running
-target/debug/deps/integration-test-ce99bcc2479f4607` (the hash at the end of
-your output will be different). Next, there is a line for each test function in
-that integration test and a summary line for the results of the integration
-test just before the `Doc-tests adder` section starts.
-
-Similarly to how adding more unit test functions adds more result lines to the
-unit tests section, adding more test functions to the integration test file
-adds more result lines to this integration test file’s section. Each
-integration test file has its own section, so if we add more files in the
-*tests* directory, there will be more integration test sections.
-
-We can still run a particular integration test function by specifying the test
-function’s name as an argument to `cargo test`. To run all the tests in a
-particular integration test file, use the `--test` argument of `cargo test`
-followed by the name of the file:
-
-```
-$ cargo test --test integration_test
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running target/debug/integration_test-952a27e0126bb565
-
-running 1 test
-test it_adds_two ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-This command runs only the tests in the *tests/integration_test.rs* file.
-
-#### Submodules in Integration Tests
-
-As you add more integration tests, you might want to make more than one file in
-the *tests* directory to help organize them; for example, you can group the
-test functions by the functionality they’re testing. As mentioned earlier, each
-file in the *tests* directory is compiled as its own separate crate.
-
-Treating each integration test file as its own crate is useful to create
-separate scopes that are more like the way end users will be using your crate.
-However, this means files in the *tests* directory don’t share the same
-behavior as files in *src* do, as you learned in Chapter 7 regarding how to
-separate code into modules and files.
-
-The different behavior of files in the *tests* directory is most noticeable
-when you have a set of helper functions that would be useful in multiple
-integration test files and you try to follow the steps in the “Moving Modules
-to Other Files” section of Chapter 7 to extract them into a common module. For
-example, if we create *tests/common.rs* and place a function named `setup` in
-it, we can add some code to `setup` that we want to call from multiple test
-functions in multiple test files:
-
-Filename: tests/common.rs
-
-```
-pub fn setup() {
-    // setup code specific to your library's tests would go here
-}
-```
-
-When we run the tests again, we’ll see a new section in the test output for the
-*common.rs* file, even though this file doesn’t contain any test functions nor
-did we call the `setup` function from anywhere:
-
-```
-running 1 test
-test tests::internal ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-     Running target/debug/deps/common-b8b07b6f1be2db70
-
-running 0 tests
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-     Running target/debug/deps/integration_test-d993c68b431d39df
-
-running 1 test
-test it_adds_two ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-   Doc-tests adder
-
-running 0 tests
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Having `common` appear in the test results with `running 0 tests` displayed for
-it is not what we wanted. We just wanted to share some code with the other
-integration test files.
-
-To avoid having `common` appear in the test output, instead of creating
-*tests/common.rs*, we’ll create *tests/common/mod.rs*. In the “Rules of Module
-Filesystems” section of Chapter 7, we used the naming convention
-*module_name/mod.rs* for files of modules that have submodules. We don’t have
-submodules for `common` here, but naming the file this way tells Rust not to
-treat the `common` module as an integration test file. When we move the `setup`
-function code into *tests/common/mod.rs* and delete the *tests/common.rs* file,
-the section in the test output will no longer appear. Files in subdirectories
-of the *tests* directory don’t get compiled as separate crates or have sections
-in the test output.
-
-After we’ve created *tests/common/mod.rs*, we can use it from any of the
-integration test files as a module. Here’s an example of calling the `setup`
-function from the `it_adds_two` test in *tests/integration_test.rs*:
-
-Filename: tests/integration_test.rs
-
-```
-extern crate adder;
-
-mod common;
-
-#[test]
-fn it_adds_two() {
-    common::setup();
-    assert_eq!(4, adder::add_two(2));
-}
-```
-
-Note that the `mod common;` declaration is the same as the module declarations
-we demonstrated in Listing 7-4. Then in the test function, we can call the
-`common::setup()` function.
-
-#### Integration Tests for Binary Crates
-
-If our project is a binary crate that only contains a *src/main.rs* file and
-doesn’t have a *src/lib.rs* file, we can’t create integration tests in the
-*tests* directory and use `extern crate` to import functions defined in the
-*src/main.rs* file. Only library crates expose functions that other crates can
-call and use; binary crates are meant to be run on their own.
-
-This is one of the reasons Rust projects that provide a binary have a
-straightforward *src/main.rs* file that calls logic that lives in the
-*src/lib.rs* file. Using that structure, integration tests *can* test the
-library crate by using `extern crate` to exercise the important functionality.
-If the important functionality works, the small amount of code in the
-*src/main.rs* file will work as well, and that small amount of code doesn’t
-need to be tested.
-
-## Summary
-
-Rust’s testing features provide a way to specify how code should function to
-ensure it continues to work as you expect, even as you make changes. Unit tests
-exercise different parts of a library separately and can test private
-implementation details. Integration tests check that many parts of the library
-work together correctly, and they use the library’s public API to test the code
-in the same way external code will use it. Even though Rust’s type system and
-ownership rules help prevent some kinds of bugs, tests are still important to
-reduce logic bugs having to do with how your code is expected to behave.
-
-Let’s combine the knowledge you learned in this chapter and in previous
-chapters to work on a project!
diff --git a/src/doc/book/second-edition/nostarch/chapter12.md b/src/doc/book/second-edition/nostarch/chapter12.md
deleted file mode 100644
index a8e5b0b168..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter12.md
+++ /dev/null
@@ -1,1688 +0,0 @@
-
-[TOC]
-
-# An I/O Project: Building a Command Line Program
-
-This chapter is a recap of the many skills you’ve learned so far and an
-exploration of a few more standard library features. We’ll build a command line
-tool that interacts with file and command line input/output to practice some of
-the Rust concepts you now have under your belt.
-
-Rust’s speed, safety, single binary output, and cross-platform support make it
-an ideal language for creating command line tools, so for our project, we’ll
-make our own version of the classic command line tool `grep` (**g**lobally
-search a **r**egular **e**xpression and **p**rint). In the simplest use case,
-`grep` searches a specified file for a specified string. To do so, `grep` takes
-as its arguments a filename and a string. Then it reads the file, finds lines
-in that file that contain the string argument, and prints those lines.
-
-Along the way, we’ll show how to make our command line tool use features of the
-terminal that many 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 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.
-
-One Rust community member, Andrew Gallant, has already created a fully
-featured, very fast version of `grep`, called `ripgrep`. By comparison, our
-version of `grep` will be fairly simple, but this chapter will give you some of
-the background knowledge you need to understand a real-world project such as
-`ripgrep`.
-
-Our `grep` project will combine a number of concepts you’ve learned so far:
-
-* Organizing code (using what you learned in modules, Chapter 7)
-* Using vectors and strings (collections, Chapter 8)
-* Handling errors (Chapter 9)
-* Using traits and lifetimes where appropriate (Chapter 10)
-* Writing tests (Chapter 11)
-
-We’ll also briefly introduce closures, iterators, and trait objects, which
-Chapters 13 and 17 will cover in detail.
-
-## Accepting Command Line Arguments
-
-Let’s create a new project with, as always, `cargo new`. We’ll call our project
-`minigrep` to distinguish it from the `grep` tool that you might already have
-on your system.
-
-```
-$ cargo new --bin minigrep
-     Created binary (application) `minigrep` project
-$ cd minigrep
-```
-
-The first task is to make `minigrep` accept its two command line arguments: the
-filename and a string to search for. That is, we want to be able to run our
-program with `cargo run`, a string to search for, and a path to a file to
-search in, like so:
-
-```
-$ cargo run searchstring example-filename.txt
-```
-
-Right now, the program generated by `cargo new` cannot process arguments we
-give it. Some existing libraries on Crates.io at *https://crates.io/* can help
-with writing a program that accepts command line arguments, but because you’re
-just learning this concept, let’s implement this capability ourselves.
-
-### Reading the Argument Values
-
-To enable `minigrep` to read the values of command line arguments we pass to
-it, we’ll need a function provided in Rust’s standard library, which is
-`std::env::args`. This function returns an *iterator* of the command line
-arguments that were given to `minigrep`. We haven’t discussed iterators yet
-(we’ll cover them fully in Chapter 13), but for now, you only need to know two
-details about iterators: iterators produce a series of values, and we can call
-the `collect` method on an iterator to turn it into a collection, such as a
-vector, containing all the elements the iterator produces.
-
-Use the code in Listing 12-1 to allow your `minigrep` program to read any
-command line arguments passed to it and then collect the values into a vector:
-
-Filename: src/main.rs
-
-```
-use std::env;
-
-fn main() {
-    let args: Vec = env::args().collect();
-    println!("{:?}", args);
-}
-```
-
-Listing 12-1: Collecting the command line arguments into a vector and printing
-them
-
-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, in cases where
-the desired function is nested in more than one module, it’s conventional to
-bring the parent module into scope rather than the function. By doing so, we
-can easily use other functions from `std::env`. It’s also less ambiguous than
-adding `use std::env::args` and then calling the function with just `args`,
-because `args` might easily be mistaken for a function that’s defined in the
-current module.
-
-> ### The `args` Function and Invalid Unicode
->
-> Note that `std::env::args` will panic if any argument contains invalid
-> 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.
-
-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
-Rust, `collect` is one function you do often need to annotate because Rust
-isn’t able to infer the kind of collection you want.
-
-Finally, we print the vector using the debug formatter, `:?`. Let’s try running
-the code first with no arguments and then with two arguments:
-
-```
-$ cargo run
---snip--
-["target/debug/minigrep"]
-
-$ cargo run needle haystack
---snip--
-["target/debug/minigrep", "needle", "haystack"]
-```
-
-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
-chapter, we’ll ignore it and save only the two arguments we need.
-
-### Saving the Argument Values in Variables
-
-Printing the value of the vector of arguments illustrated that the program is
-able to access the values specified as command line arguments. Now we need to
-save the values of the two arguments in variables so we can use the values
-throughout the rest of the program. We do that in Listing 12-2:
-
-Filename: src/main.rs
-
-```
-use std::env;
-
-fn main() {
-    let args: Vec = env::args().collect();
-
-    let query = &args[1];
-    let filename = &args[2];
-
-    println!("Searching for {}", query);
-    println!("In file {}", filename);
-}
-```
-
-Listing 12-2: Creating variables to hold the query argument and filename
-argument
-
-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 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 filename, so we put a reference to the second argument in the
-variable `filename`.
-
-We temporarily print the values of these variables to prove that the code is
-working as we intend. Let’s run this program again with the arguments `test`
-and `sample.txt`:
-
-```
-$ cargo run test sample.txt
-   Compiling minigrep v0.1.0 (file:///projects/minigrep)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target/debug/minigrep test sample.txt`
-Searching for test
-In file sample.txt
-```
-
-Great, the program is working! The values of the arguments we need are being
-saved into the right variables. Later we’ll add some error handling to deal
-with certain potential erroneous situations, such as when the user provides no
-arguments; for now, we’ll ignore that situation and work on adding file-reading
-capabilities instead.
-
-## Reading a File
-
-Now we’ll add functionality to read the file that is specified in the
-`filename` command line argument. First, we need a sample file to test it with:
-the best kind of file to use to make sure `minigrep` is working is one 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?”
-
-Filename: poem.txt
-
-```
-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!
-```
-
-Listing 12-3: A poem by Emily Dickinson makes a good test case
-
-With the text in place, edit *src/main.rs* and add code to open the file, as
-shown in Listing 12-4:
-
-Filename: src/main.rs
-
-```
-use std::env;
-use std::fs::File;
-use std::io::prelude::*;
-
-fn main() {
-    // --snip--
-    println!("In file {}", filename);
-
-    let mut f = File::open(filename).expect("file not found");
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)
-        .expect("something went wrong reading the file");
-
-    println!("With text:\n{}", contents);
-}
-```
-
-Listing 12-4: Reading the contents of the file specified by the second argument
-
-First, we add some more `use` statements to bring in relevant parts of the
-standard library: we need `std::fs::File` to handle files, and
-`std::io::prelude::*` contains various useful traits for doing I/O, including
-file I/O. In the same way that Rust has a general prelude that brings certain
-types and functions into scope automatically, the `std::io` module has its own
-prelude of common types and functions you’ll need when working with I/O. Unlike
-with the default prelude, we must explicitly add a `use` statement for the
-prelude from `std::io`.
-
-In `main`, we’ve added three statements: first, we get a mutable handle to the
-file by calling the `File::open` function and passing it the value of the
-`filename` variable. Second, we create a variable called `contents` and set it
-to a mutable, empty `String`. This will hold the content of the file after we
-read it in. Third, we call `read_to_string` on our file handle and pass a
-mutable reference to `contents` as an argument.
-
-After those lines, we’ve again added a temporary `println!` statement that
-prints the value of `contents` after the file is read, so we can check that the
-program is working so far.
-
-Let’s run this code with any string as the first command line argument (because
-we haven’t implemented the searching part yet) and the *poem.txt* file as the
-second argument:
-
-```
-$ cargo run the poem.txt
-   Compiling minigrep v0.1.0 (file:///projects/minigrep)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     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!
-```
-
-Great! The code read and then printed the contents of the file. But the code
-has a few flaws. The `main` function has multiple 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.
-
-## Refactoring to Improve Modularity and Error Handling
-
-To improve our program, we’ll fix four problems that have to do with the
-program’s structure and how it’s handling potential errors.
-
-First, our `main` function now performs two tasks: it parses arguments and
-opens files. For such a small function, this isn’t a major problem. However, if
-we continue to grow our program inside `main`, the number of separate tasks the
-`main` function handles will increase. As a function gains responsibilities, it
-becomes more difficult to reason about, harder to test, and harder to change
-without breaking one of its parts. It’s best to separate functionality so each
-function is responsible for one task.
-
-This issue also ties into the second problem: although `query` and `filename`
-are configuration variables to our program, variables like `f` and `contents`
-are used to perform the program’s logic. The longer `main` becomes, the more
-variables we’ll need to bring into scope; the more variables we have in scope,
-the harder it will be to keep track of the purpose of each. It’s best to group
-the configuration variables into one structure to make their purpose clear.
-
-The third problem is that we’ve used `expect` to print an error message when
-opening the file fails, but the error message just prints `file not found`.
-Opening a file can fail in a number of ways besides the file being missing: for
-example, the file might exist, but we might not have permission to open it.
-Right now, if we’re in that situation, we’d print the `file not found` error
-message, which would give the user the wrong 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 in 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.
-
-### Separation of Concerns for Binary Projects
-
-The organizational problem of allocating responsibility for multiple tasks to
-the `main` function is common to many binary projects. As a result, the Rust
-community has developed a process to use as a guideline for splitting the
-separate concerns of a binary program when `main` starts getting large. The
-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*.
-* 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
-  from *main.rs* and move it to *lib.rs*.
-* The responsibilities that remain in the `main` function after this process
-  should be limited to the following:
-
-  * Calling the command line parsing logic with the argument values
-  * Setting up any other configuration
-  * Calling a `run` function in *lib.rs*
-  * 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
-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 only code
-that remains in *main.rs* will be small enough to verify its correctness by
-reading it. Let’s rework our program by following this process.
-
-#### Extracting the Argument Parser
-
-We’ll extract the functionality for parsing arguments into a function that
-`main` will call to prepare for moving the command line parsing logic to
-*src/lib.rs*. Listing 12-5 shows the new start of `main` that calls a new
-function `parse_config`, which we’ll define in *src/main.rs* for the moment.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let args: Vec = env::args().collect();
-
-    let (query, filename) = parse_config(&args);
-
-    // --snip--
-}
-
-fn parse_config(args: &[String]) -> (&str, &str) {
-    let query = &args[1];
-    let filename = &args[2];
-
-    (query, filename)
-}
-```
-
-Listing 12-5: Extracting a `parse_config` function from `main`
-
-We’re still collecting the command line arguments into a vector, but instead of
-assigning the argument value at index `1` to the variable `query` and the
-argument value at index `2` to the variable `filename` within the `main`
-function, we pass the whole vector to the `parse_config` function. The
-`parse_config` function then holds the logic that determines which argument
-goes in which variable and passes the values back to `main`. We still create
-the `query` and `filename` variables in `main`, but `main` no longer has the
-responsibility of determining how the command line arguments and variables
-correspond.
-
-This rework may seem like overkill for our small program, but we’re refactoring
-in small, incremental steps. After making this change, run the program again to
-verify that the argument parsing still works. It’s good to check your progress
-often, to help identify the cause of problems when they occur.
-
-#### Grouping Configuration Values
-
-We can take another small step to improve the `parse_config` function further.
-At the moment, we’re returning a tuple, but then we immediately break that
-tuple into individual parts again. This is a sign that perhaps we don’t have
-the right abstraction yet.
-
-Another indicator that shows there’s room for improvement is the `config` part
-of `parse_config`, which implies that the two values we return are related and
-are both part of one configuration value. We’re not currently conveying this
-meaning in the structure of the data other than by grouping the two values into
-a tuple; we could put the two values into one struct and give each of the
-struct fields a meaningful name. Doing so will make it easier for future
-maintainers of this code to understand how the different values relate to each
-other and what their purpose is.
-
-> Note: Some people call this anti-pattern of using primitive values when a
-> complex type would be more appropriate *primitive obsession*.
-
-Listing 12-6 shows the addition of a struct named `Config` defined to have
-fields named `query` and `filename`. We’ve also changed the `parse_config`
-function to return an instance of the `Config` struct and updated `main` to use
-the struct fields rather than having separate variables:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let args: Vec = env::args().collect();
-
-    let config = parse_config(&args);
-
-    println!("Searching for {}", config.query);
-    println!("In file {}", config.filename);
-
-    let mut f = File::open(config.filename).expect("file not found");
-
-    // --snip--
-}
-
-struct Config {
-    query: String,
-    filename: String,
-}
-
-fn parse_config(args: &[String]) -> Config {
-    let query = args[1].clone();
-    let filename = args[2].clone();
-
-    Config { query, filename }
-}
-```
-
-Listing 12-6: Refactoring `parse_config` to return an instance of a `Config`
-struct
-
-The signature of `parse_config` now indicates that it returns a `Config` value.
-In the body of `parse_config`, where we used to return string slices that
-reference `String` values in `args`, we now define `Config` to contain owned
-`String` values. The `args` variable in `main` is the owner of the argument
-values and is only letting the `parse_config` function borrow them, which means
-we’d violate Rust’s borrowing rules if `Config` tried to take ownership of the
-values in `args`.
-
-We could manage the `String` data in a number of different ways, but the
-easiest, though somewhat inefficient, route is to call the `clone` method on
-the values. This will make a full copy of the data for the `Config` instance to
-own, which takes more time and memory than storing a reference to the string
-data. However, cloning the data also makes our code very straightforward
-because we don’t have to manage the lifetimes of the references; in this
-circumstance, giving up a little performance to gain simplicity is a worthwhile
-trade-off.
-
-> ### The Trade-Offs of Using `clone`
->
-> There’s a tendency among many Rustaceans to avoid using `clone` to fix
-> ownership problems because of its runtime cost. In Chapter 13, you’ll learn
-> how to use more efficient methods in this type of situation. But for now,
-> it’s okay to copy a few strings to continue making progress because you’ll
-> make these copies only once and your filename and query string are very
-> small. It’s better to have a working program that’s a bit inefficient than to
-> try to hyperoptimize code on your first pass. As you become more experienced
-> with Rust, it’ll be easier to start with the most efficient solution, but for
-> now, it’s perfectly acceptable to call `clone`.
-
-We’ve updated `main` so it places the instance of `Config` returned by
-`parse_config` into a variable named `config`, and we updated the code that
-previously used the separate `query` and `filename` variables so it now uses
-the fields on the `Config` struct instead.
-
-Now our code more clearly conveys that `query` and `filename` are related and
-that their purpose is to configure how the program will work. Any code that
-uses these values knows to find them in the `config` instance in the fields
-named for their purpose.
-
-#### Creating a Constructor for `Config`
-
-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 `filename` 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 `filename` and to be able to return the
-values’ names as struct field names from the `parse_config` function.
-
-So now that the purpose of the `parse_config` function is to create a `Config`
-instance, we can change `parse_config` from a plain function to a function
-named `new` that is associated with the `Config` struct. Making this change
-will make the code more idiomatic. We can create instances of types in the
-standard library, such as `String`, by calling `String::new`. Similarly, by
-changing `parse_config` into a `new` function associated with `Config`, we’ll
-be able to create instances of `Config` by calling `Config::new`. Listing 12-7
-shows the changes we need to make:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let args: Vec = env::args().collect();
-
-    let config = Config::new(&args);
-
-    // --snip--
-}
-
-// --snip--
-
-impl Config {
-    fn new(args: &[String]) -> Config {
-        let query = args[1].clone();
-        let filename = args[2].clone();
-
-        Config { query, filename }
-    }
-}
-```
-
-Listing 12-7: Changing `parse_config` into `Config::new`
-
-We’ve updated `main` where we were calling `parse_config` to instead call
-`Config::new`. We’ve changed the name of `parse_config` to `new` and moved it
-within an `impl` block, which associates the `new` function with `Config`. Try
-compiling this code again to make sure it works.
-
-### Fixing the Error Handling
-
-Now we’ll work on fixing our error handling. Recall that attempting to access
-the values in the `args` vector at index `1` or index `2` will cause the
-program to panic if the vector contains fewer than three items. Try running the
-program 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.0 secs
-     Running `target/debug/minigrep`
-thread 'main' panicked at 'index out of bounds: the len is 1
-but the index is 1', src/main.rs:29:21
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-```
-
-The line `index out of bounds: the len is 1 but the index is 1` is an error
-message intended for programmers. It won’t help our end users understand what
-happened and what 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 than the
-`index out of bounds` message.
-
-Filename: src/main.rs
-
-```
-// --snip--
-fn new(args: &[String]) -> Config {
-    if args.len() < 3 {
-        panic!("not enough arguments");
-    }
-    // --snip--
-```
-
-Listing 12-8: Adding a check for the number of arguments
-
-This code is similar to the `Guess::new` function we wrote in Listing 9-9, 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 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.
-
-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:
-
-```
-$ cargo run
-   Compiling minigrep v0.1.0 (file:///projects/minigrep)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target/debug/minigrep`
-thread 'main' panicked at 'not enough arguments', src/main.rs:30:12
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-```
-
-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-9 isn’t the best to use here: a call to
-`panic!` is more appropriate for a programming problem rather than a usage
-problem, as discussed in Chapter 9. Instead, we can use the other technique you
-learned about in Chapter 9—returning a `Result` that indicates either success
-or an error.
-
-#### Returning a `Result` from `new` 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. When
-`Config::new` 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.
-
-Listing 12-9 shows the changes we need to make to the return value of
-`Config::new` 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
-
-```
-impl Config {
-    fn new(args: &[String]) -> Result {
-        if args.len() < 3 {
-            return Err("not enough arguments");
-        }
-
-        let query = args[1].clone();
-        let filename = args[2].clone();
-
-        Ok(Config { query, filename })
-    }
-}
-```
-
-Listing 12-9: Returning a `Result` from `Config::new`
-
-Our `new` function now returns a `Result` with a `Config` instance in the
-success case and a `&'static str` in the error case. Recall from “The Static
-Lifetime” section in Chapter 10 that `&'static str` is the type of string
-literals, which is our error message type for now.
-
-We’ve made two changes in the body of the `new` function: instead of calling
-`panic!` when the user doesn’t pass enough arguments, we now return an `Err`
-value, and we’ve wrapped the `Config` return value in an `Ok`. These changes
-make the function conform to its new type signature.
-
-Returning an `Err` value from `Config::new` allows the `main` function to
-handle the `Result` value returned from the `new` function and exit the process
-more cleanly in the error case.
-
-#### Calling `Config::new` 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::new`, as shown in
-Listing 12-10. We’ll also take the responsibility of exiting the command line
-tool with a nonzero error code from `panic!` and 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
-
-```
-use std::process;
-
-fn main() {
-    let args: Vec = env::args().collect();
-
-    let config = Config::new(&args).unwrap_or_else(|err| {
-        println!("Problem parsing arguments: {}", err);
-        process::exit(1);
-    });
-
-    // --snip--
-```
-
-Listing 12-10: Exiting with an error code if creating a new `Config` fails
-
-In this listing, we’ve used a method we haven’t covered before:
-`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. 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 import `process` from the standard library. 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 extra output. Let’s try
-it:
-
-```
-$ cargo run
-   Compiling minigrep v0.1.0 (file:///projects/minigrep)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.48 secs
-     Running `target/debug/minigrep`
-Problem parsing arguments: not enough arguments
-```
-
-Great! This output is much friendlier for our users.
-
-### 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”, 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--
-
-    println!("Searching for {}", config.query);
-    println!("In file {}", config.filename);
-
-    run(config);
-}
-
-fn run(config: Config) {
-    let mut f = File::open(config.filename).expect("file not found");
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)
-        .expect("something went wrong reading the file");
-
-    println!("With text:\n{}", contents);
-}
-
-// --snip--
-```
-
-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
-
-With the remaining program logic separated into the `run` function, we can
-improve the error handling, as we did with `Config::new` in Listing 12-9.
-Instead of allowing the program to panic by calling `expect`, the `run`
-function will return a `Result` when something goes wrong. This will let
-us further consolidate into `main` the logic around handling errors 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
-
-```
-use std::error::Error;
-
-// --snip--
-
-fn run(config: Config) -> Result<(), Box> {
-    let mut f = File::open(config.filename)?;
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)?;
-
-    println!("With text:\n{}", contents);
-
-    Ok(())
-}
-```
-
-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>`. 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). 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.
-
-Second, we’ve removed the calls to `expect` in favor of `?`, 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. 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 the
-idiomatic way to indicate that we’re calling `run` for its side effects only;
-it doesn’t return a value we need.
-
-When you run this code, it will compile but will display a warning:
-
-```
-warning: unused `std::result::Result` which must be used
-  --> src/main.rs:18:5
-   |
-18 |     run(config);
-   |     ^^^^^^^^^^^^
-= note: #[warn(unused_must_use)] on by default
-```
-
-Rust tells us that our code ignored the `Result` value and the `Result` value
-might indicate that an error occurred. But we’re not checking to see whether or
-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`
-
-We’ll check for errors and handle them using a technique similar to one we used
-with `Config::new` in Listing 12-10, but with a slight difference:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    // --snip--
-
-    println!("Searching for {}", config.query);
-    println!("In file {}", config.filename);
-
-    if let Err(e) = run(config) {
-        println!("Application error: {}", e);
-
-        process::exit(1);
-    }
-}
-```
-
-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::new`
-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 because it 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.
-
-### 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 so we can test
-it 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
-*src/lib.rs*:
-
-* The `run` function definition
-* The relevant `use` statements
-* The definition of `Config`
-* The `Config::new` function definition
-
-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 the listing after this one.
-
-Filename: src/lib.rs
-
-```
-use std::error::Error;
-use std::fs::File;
-use std::io::prelude::*;
-
-pub struct Config {
-    pub query: String,
-    pub filename: String,
-}
-
-impl Config {
-    pub fn new(args: &[String]) -> Result {
-        // --snip--
-    }
-}
-
-pub fn run(config: Config) -> Result<(), Box> {
-    // --snip--
-}
-```
-
-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
-`new` method, and on the `run` function. We now have a library crate that has a
-public API that 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
-
-```
-extern crate minigrep;
-
-use std::env;
-use std::process;
-
-use minigrep::Config;
-
-fn main() {
-    // --snip--
-    if let Err(e) = minigrep::run(config) {
-        // --snip--
-    }
-}
-```
-
-Listing 12-14: Bringing the `minigrep` crate into the scope of *src/main.rs*
-
-To bring the library crate into the binary crate, we use `extern crate
-minigrep`. Then we add a `use minigrep::Config` line to bring the `Config` type
-into 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.
-
-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
-modular. Almost all of our work will be done in *src/lib.rs* from here on out.
-
-Let’s take advantage of this newfound modularity by doing something that would
-have been difficult with the old code but is easy with the new code: we’ll
-write some tests!
-
-## Developing the Library’s Functionality with Test-Driven Development
-
-Now that we’ve extracted the logic into *src/lib.rs* and left the argument
-collecting and error handling in *src/main.rs*, it’s much easier to write tests
-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. Feel free to write some tests for the functionality in
-the `Config::new` and `run` functions on your own.
-
-In this section, we’ll add the searching logic to the `minigrep` program by
-using the Test-driven development (TDD) process. This software development
-technique follows these 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.
-4. Repeat from step 1!
-
-This process is just one of many ways to write software, but TDD can help drive
-code design as well. 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
-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`.
-
-### Writing a Failing Test
-
-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 `test` 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 for the
-query in, 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
-
-```
-#[cfg(test)]
-mod test {
-    use super::*;
-
-    #[test]
-    fn one_result() {
-        let query = "duct";
-        let contents = "\
-Rust:
-safe, fast, productive.
-Pick three.";
-
-        assert_eq!(
-            vec!["safe, fast, productive."],
-            search(query, contents)
-        );
-    }
-}
-```
-
-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"`. We assert that the value returned
-from the `search` function contains only the line we expect.
-
-We aren’t able to run this test and watch it fail because the test doesn’t even
-compile: the `search` function doesn’t exist yet! So now 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."`
-
-Filename: src/lib.rs
-
-```
-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
-
-Notice that we need an explicit lifetime `'a` defined in the signature of
-`search` and used 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`).
-
-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
-`contents` argument. This is important! The data referenced *by* a slice needs
-to be valid for the reference to be valid; if the compiler assumes we’re making
-string slices of `query` rather than `contents`, it will do its safety checking
-incorrectly.
-
-If we forget the lifetime annotations and try to compile this function, we’ll
-get this error:
-
-```
-error[E0106]: missing lifetime specifier
- --> src/lib.rs:5:51
-  |
-5 | pub fn search(query: &str, contents: &str) -> Vec<&str> {
-  |                                                   ^ expected 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`
-```
-
-Rust can’t possibly know which of the two arguments we need, so we need to tell
-it. Because `contents` is the argument that contains all of our text and we
-want to return the parts of that text that match, we know `contents` is the
-argument that should be connected to the return value using the lifetime syntax.
-
-Other programming languages don’t require you to connect arguments to return
-values in the signature. So although this might seem strange, it will get
-easier over time. You might want to compare this example with the “Validating
-References with Lifetimes” section in Chapter 10.
-
-Now let’s run the test:
-
-```
-$ cargo test
-   Compiling minigrep v0.1.0 (file:///projects/minigrep)
---warnings--
-    Finished dev [unoptimized + debuginfo] target(s) in 0.43 secs
-     Running target/debug/deps/minigrep-abcabcabc
-
-running 1 test
-test test::one_result ... FAILED
-
-failures:
-
----- test::one_result stdout ----
-        thread 'test::one_result' panicked at 'assertion failed: `(left ==
-right)`
-left: `["safe, fast, productive."]`,
-right: `[]`)', src/lib.rs:48:8
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-
-
-failures:
-    test::one_result
-
-test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out
-
-error: test failed, to rerun pass '--lib'
-```
-
-Great, the test fails, exactly as we expected. Let’s get the test to pass!
-
-### Writing Code to Pass the Test
-
-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.
-
-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:
-
-Filename: src/lib.rs
-
-```
-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`
-
-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.
-
-#### Searching Each Line for the Query
-
-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:
-
-Filename: src/lib.rs
-
-```
-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
-        }
-    }
-}
-```
-
-Listing 12-18: Adding functionality to see whether the line contains the string
-in `query`
-
-#### Storing Matching Lines
-
-We also need a way to store the lines that contain our query string. 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> {
-    let mut results = Vec::new();
-
-    for line in contents.lines() {
-        if line.contains(query) {
-            results.push(line);
-        }
-    }
-
-    results
-}
-```
-
-Listing 12-19: Storing the lines that match so we can return them
-
-Now the `search` function should return only the lines that contain `query`,
-and our test should pass. Let’s run the test:
-
-```
-$ cargo test
---snip--
-running 1 test
-test test::one_result ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Our test passed, so we know it works!
-
-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.
-
-#### 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
-`contents` that `run` reads from the file to the `search` function. Then `run`
-will print each line returned from `search`:
-
-Filename: src/lib.rs
-
-```
-pub fn run(config: Config) -> Result<(), Box> {
-    let mut f = File::open(config.filename)?;
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)?;
-
-    for line in search(&config.query, &contents) {
-        println!("{}", line);
-    }
-
-    Ok(())
-}
-```
-
-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”:
-
-```
-$ cargo run frog poem.txt
-   Compiling minigrep v0.1.0 (file:///projects/minigrep)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.38 secs
-     Running `target/debug/minigrep frog poem.txt`
-How public, like a frog
-```
-
-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.0 secs
-     Running `target/debug/minigrep body poem.txt`
-I’m nobody! Who are you?
-Are you nobody, too?
-How dreary to be somebody!
-```
-
-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”:
-
-```
-$ cargo run monomorphization poem.txt
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target/debug/minigrep monomorphization poem.txt`
-```
-
-Excellent! We’ve built our own mini version of a classic tool and learned a lot
-about how to structure applications. We’ve also learned a bit about file input
-and output, lifetimes, testing, and command line parsing.
-
-To round out this project, we’ll briefly demonstrate how to work with
-environment variables and how to print to standard error, both of which are
-useful when you’re writing command line programs.
-
-## Working with Environment Variables
-
-We’ll improve `minigrep` by adding an extra feature: an option for
-case-insensitive searching that the user can turn on via an environment
-variable. We could make this feature a command line option and require that
-users enter it each time they want it to apply, but instead we’ll use an
-environment variable. Doing so allows 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
-
-We want to add a new `search_case_insensitive` function that we’ll call when
-the environment variable is on. We’ll continue to follow the TDD process, so
-the first step is again to write a failing test. We’ll add a new test for 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
-
-```
-#[cfg(test)]
-mod test {
-    use super::*;
-
-    #[test]
-    fn case_sensitive() {
-        let query = "duct";
-        let contents = "\
-Rust:
-safe, fast, productive.
-Pick three.
-Duct tape.";
-
-        assert_eq!(
-            vec!["safe, fast, productive."],
-            search(query, contents)
-        );
-    }
-
-    #[test]
-    fn case_insensitive() {
-        let query = "rUsT";
-        let contents = "\
-Rust:
-safe, fast, productive.
-Pick three.
-Trust me.";
-
-        assert_eq!(
-            vec!["Rust:", "Trust me."],
-            search_case_insensitive(query, contents)
-        );
-    }
-}
-```
-
-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
-“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
-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 than 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.
-
-### 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 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
-
-```
-fn search_case_insensitive<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
-    let query = query.to_lowercase();
-    let mut results = Vec::new();
-
-    for line in contents.lines() {
-        if line.to_lowercase().contains(&query) {
-            results.push(line);
-        }
-    }
-
-    results
-}
-```
-
-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. Calling `to_lowercase` on the query is necessary so 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.
-
-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
-`"rust"`. When we pass `query` as an argument to the `contains` method now, we
-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` before we check whether it
-contains `query` to lowercase all 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:
-
-```
-running 2 tests
-test test::case_insensitive ... ok
-test test::case_sensitive ... ok
-
-test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-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 since we aren’t initializing this
-field anywhere yet:
-
-Filename: src/lib.rs
-
-```
-pub struct Config {
-    pub query: String,
-    pub filename: String,
-    pub case_sensitive: bool,
-}
-```
-
-Note that we added the `case_sensitive` field that holds a Boolean. Next, we
-need the `run` function to check the `case_sensitive` 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. Note this still
-won’t compile yet:
-
-Filename: src/lib.rs
-
-```
-pub fn run(config: Config) -> Result<(), Box> {
-    let mut f = File::open(config.filename)?;
-
-    let mut contents = String::new();
-    f.read_to_string(&mut contents)?;
-
-    let results = if config.case_sensitive {
-        search(&config.query, &contents)
-    } else {
-        search_case_insensitive(&config.query, &contents)
-    };
-
-    for line in results {
-        println!("{}", line);
-    }
-
-    Ok(())
-}
-```
-
-Listing 12-22: Calling either `search` or `search_case_insensitive` based on
-the value in `config.case_sensitive`
-
-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 want to bring that module into scope with a `use std::env;` line
-at the top of *src/lib.rs*. Then we’ll use the `var` method from the `env`
-module to check for an environment variable named `CASE_INSENSITIVE`, as shown
-in Listing 12-23:
-
-Filename: src/lib.rs
-
-```
-use std::env;
-
-// --snip--
-
-impl Config {
-    pub fn new(args: &[String]) -> Result {
-        if args.len() < 3 {
-            return Err("not enough arguments");
-        }
-
-        let query = args[1].clone();
-        let filename = args[2].clone();
-
-        let case_sensitive = env::var("CASE_INSENSITIVE").is_err();
-
-        Ok(Config { query, filename, case_sensitive })
-    }
-}
-```
-
-Listing 12-23: Checking for an environment variable named `CASE_INSENSITIVE`
-
-Here, we create a new variable `case_sensitive`. To set its value, we call the
-`env::var` function and pass it the name of the `CASE_INSENSITIVE` environment
-variable. The `env::var` method returns a `Result` that will be the successful
-`Ok` variant that contains the value of the environment variable if the
-environment variable is set. It will return the `Err` variant if the
-environment variable is not set.
-
-We’re using the `is_err` method on the `Result` to check whether it’s an error
-and therefore unset, which means it *should* do a case-sensitive search. If the
-`CASE_INSENSITIVE` environment variable is set to anything, `is_err` will
-return false and the program will perform a case-insensitive search. We don’t
-care about the *value* of the environment variable, just whether it’s set or
-unset, so we’re checking `is_err` rather than using `unwrap`, `expect`, or any
-of the other methods we’ve seen on `Result`.
-
-We pass the value in the `case_sensitive` variable to the `Config` instance so
-the `run` function can read that value and decide whether to call `search` or
-`search_case_insensitive`, as we implemented in Listing 12-22.
-
-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:
-
-```
-$ cargo run to poem.txt
-   Compiling minigrep v0.1.0 (file:///projects/minigrep)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     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 `CASE_INSENSITIVE`
-set to `1` but with the same query `to`.
-
-If you’re using PowerShell, you will need to set the environment variable and
-run the program in two commands rather than one:
-
-```
-$ $env:CASE_INSENSITIVE=1
-$ cargo run to poem.txt
-```
-
-We should get lines that contain “to” that might have uppercase letters:
-
-```
-$ CASE_INSENSITIVE=1 cargo run to poem.txt
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target/debug/minigrep to poem.txt`
-Are you nobody, too?
-How dreary to be somebody!
-To tell your name the livelong day
-To an admiring bog!
-```
-
-Excellent, we also got lines containing “To”! Our `minigrep` program can now do
-case-insensitive searching controlled by an environment variable. Now you know
-how to manage options set using either command line arguments or environment
-variables.
-
-Some programs allow arguments *and* environment variables for the same
-configuration. In those cases, the programs decide that one or the other takes
-precedence. For another exercise on your own, try controlling case
-insensitivity through either a command line argument or an environment
-variable. Decide whether the command line argument or the environment variable
-should take precedence if the program is run with one set to case sensitive and
-one set to case insensitive.
-
-The `std::env` module contains many more useful features for dealing with
-environment variables: check out its documentation to see what is available.
-
-## Writing Error Messages to Standard Error Instead of Standard Output
-
-At the moment, we’re writing all of our output to the terminal using the
-`println!` function. Most terminals provide two kinds of output: *standard
-output* (`stdout`) for general information and *standard error* (`stderr`)
-for error messages. This distinction enables users to choose to direct the
-successful output of a program to a file but still print error messages to the
-screen.
-
-The `println!` function is only capable of printing to standard output, so we
-have to use something else to print to standard error.
-
-### Checking Where Errors Are Written
-
-First, let’s observe how the content printed by `minigrep` is currently being
-written to standard output, including any error messages we want to write to
-standard error instead. We’ll do that by redirecting the standard output stream
-to a file while also intentionally causing an error. We won’t redirect the
-standard error stream, so any content sent to standard error will continue to
-display on the screen.
-
-Command line programs are expected to send error messages to the standard error
-stream so we can still see error messages on the screen even if we redirect the
-standard output stream to a file. Our program is not currently well-behaved:
-we’re about to see that it saves the error message output to a file instead!
-
-The way to demonstrate this behavior is by running the program with `>` and the
-filename, *output.txt*, that we want to redirect the standard output stream to.
-We won’t pass any arguments, which should cause an error:
-
-```
-$ cargo run > output.txt
-```
-
-The `>` syntax tells the shell to write the contents of standard output to
-*output.txt* instead of the screen. We didn’t see the error message we were
-expecting printed to the screen, so that means it must have ended up in the
-file. This is what *output.txt* contains:
-
-```
-Problem parsing arguments: not enough arguments
-```
-
-Yup, our error message is being printed to standard output. It’s much more
-useful for error messages like this to be printed to standard error so only
-data from a successful run ends up in the file. We’ll change that.
-
-### Printing Errors to Standard Error
-
-We’ll use the code in Listing 12-24 to change how error messages are printed.
-Because of the refactoring we did earlier in this chapter, all the code that
-prints error messages is in one function, `main`. The standard library provides
-the `eprintln!` macro that prints to the standard error stream, so let’s change
-the two places we were calling `println!` to print errors to use `eprintln!`
-instead.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let args: Vec = env::args().collect();
-
-    let config = Config::new(&args).unwrap_or_else(|err| {
-        eprintln!("Problem parsing arguments: {}", err);
-        process::exit(1);
-    });
-
-    if let Err(e) = minigrep::run(config) {
-        eprintln!("Application error: {}", e);
-
-        process::exit(1);
-    }
-}
-```
-
-Listing 12-24: Writing error messages to standard error instead of standard
-output using `eprintln!`
-
-After changing `println!` to `eprintln!`, let’s run the program again in the
-same way, without any arguments and redirecting standard output with `>`:
-
-```
-$ cargo run > output.txt
-Problem parsing arguments: not enough arguments
-```
-
-Now we see the error onscreen and *output.txt* contains nothing, which is the
-behavior we expect of command line programs.
-
-Let’s run the program again with arguments that don’t cause an error but still
-redirect standard output to a file, like so:
-
-```
-$ cargo run to poem.txt > output.txt
-```
-
-We won’t see any output to the terminal, and *output.txt* will contain our
-results:
-
-Filename: output.txt
-
-```
-Are you nobody, too?
-How dreary to be somebody!
-```
-
-This demonstrates that we’re now using standard output for successful output
-and standard error for error output as appropriate.
-
-## Summary
-
-This chapter recapped some of the major concepts you’ve learned so far and
-covered how to perform common I/O operations in Rust. By using command line
-arguments, files, environment variables, and the `eprintln!` macro for printing
-errors, you’re now prepared to write command line applications. By using the
-concepts in previous chapters, your code will be well organized, store data
-effectively in the appropriate data structures, handle errors nicely, and be
-well tested.
-
-Next, we’ll explore some Rust features that were influenced by functional
-languages: closures and iterators.
diff --git a/src/doc/book/second-edition/nostarch/chapter13.md b/src/doc/book/second-edition/nostarch/chapter13.md
deleted file mode 100644
index f592c137bb..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter13.md
+++ /dev/null
@@ -1,1528 +0,0 @@
-
-[TOC]
-
-# Functional Language Features: Iterators and Closures
-
-Rust’s design has taken inspiration from many existing languages and
-techniques, and one significant influence is *functional programming*.
-Programming in a functional style often includes using functions as values by
-passing them in arguments, returning them from other functions, assigning them
-to variables for later execution, and so forth.
-
-In this chapter, we won’t debate the issue of what functional programming is or
-isn’t but will instead discuss some features of Rust that are similar to
-features in many languages often referred to as functional.
-
-More specifically, we’ll cover:
-
-* *Closures*, a function-like construct you can store in a variable
-* *Iterators*, a way of processing a series of elements
-* How to use these two features to improve the I/O project in Chapter 12
-* The performance of these two features (Spoiler alert: they’re faster than you
-  might think!)
-
-Other Rust features, such as pattern matching and enums, which we’ve covered in
-other chapters, are influenced by the functional style as well. Mastering
-closures and iterators is an important part of writing idiomatic, fast Rust
-code, so we’ll devote this entire chapter to them.
-
-## Closures: Anonymous Functions that Can Capture Their Environment
-
-Rust’s closures are anonymous functions you can save in a variable or pass as
-arguments to other functions. You can create the closure in one place and then
-call the closure to evaluate it in a different context. Unlike functions,
-closures can capture values from the scope in which they’re called. We’ll
-demonstrate how these closure features allow for code reuse and behavior
-customization.
-
-### Creating an Abstraction of Behavior with Closures
-
-Let’s work on an example of a situation in which it’s useful to store a closure
-to be executed later. Along the way, we’ll talk about the syntax of closures,
-type inference, and traits.
-
-Consider this hypothetical situation: we work at a startup that’s making an app
-to generate custom exercise workout plans. The backend is written in Rust, and
-the algorithm that generates the workout plan takes into account many factors,
-such as the app user’s age, body mass index, exercise preferences, recent
-workouts, and an intensity number they specify. The actual algorithm used isn’t
-important in this example; what’s important is that this calculation takes a
-few seconds. We want to call this algorithm only when we need to and only call
-it once so we don’t make the user wait more than necessary.
-
-We’ll simulate calling this hypothetical algorithm with the function
-`simulated_expensive_calculation` shown in Listing 13-1, which will print
-`calculating slowly...`, wait for two seconds, and then return whatever number
-we passed in:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::time::Duration;
-
-fn simulated_expensive_calculation(intensity: u32) -> u32 {
-    println!("calculating slowly...");
-    thread::sleep(Duration::from_secs(2));
-    intensity
-}
-```
-
-Listing 13-1: A function to stand in for a hypothetical calculation that takes
-about 2 seconds to run
-
-Next is the `main` function, which contains the parts of the workout app
-important for this example. This function represents the code that the app will
-call when a user asks for a workout plan. Because the interaction with the
-app’s frontend isn’t relevant to the use of closures, we’ll hardcode values
-representing inputs to our program and print the outputs.
-
-The required inputs are these:
-
-* An intensity number from the user, which is specified when they request
-  a workout to indicate whether they want a low-intensity workout or a
-  high-intensity workout
-* A random number that will generate some variety in the workout plans
-
-The output will be the recommended workout plan. Listing 13-2 shows the `main`
-function we’ll use:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let simulated_user_specified_value = 10;
-    let simulated_random_number = 7;
-
-    generate_workout(
-        simulated_user_specified_value,
-        simulated_random_number
-    );
-}
-```
-
-Listing 13-2: A `main` function with hardcoded values to simulate user input
-and random number generation
-
-We’ve hardcoded the variable `simulated_user_specified_value` as 10 and the
-variable `simulated_random_number` as 7 for simplicity’s sake; in an actual
-program, we’d get the intensity number from the app frontend, and we’d use the
-`rand` crate to generate a random number, as we did in the Guessing Game
-example in Chapter 2. The `main` function calls a `generate_workout` function
-with the simulated input values.
-
-Now that we have the context, let’s get to the algorithm. The function
-`generate_workout` in Listing 13-3 contains the business logic of the
-app that we’re most concerned with in this example. The rest of the code
-changes in this example will be made to this function.
-
-Filename: src/main.rs
-
-```
-fn generate_workout(intensity: u32, random_number: u32) {
-    if intensity < 25 {
-        println!(
-            "Today, do {} pushups!",
-            simulated_expensive_calculation(intensity)
-        );
-        println!(
-            "Next, do {} situps!",
-            simulated_expensive_calculation(intensity)
-        );
-    } else {
-        if random_number == 3 {
-            println!("Take a break today! Remember to stay hydrated!");
-        } else {
-            println!(
-                "Today, run for {} minutes!",
-                simulated_expensive_calculation(intensity)
-            );
-        }
-    }
-}
-```
-
-Listing 13-3: The business logic that prints the workout plans based on the
-inputs and calls to the `simulated_expensive_calculation` function
-
-The code in Listing 13-3 has multiple calls to the slow calculation function.
-The first `if` block calls `simulated_expensive_calculation` twice, the `if`
-inside the outer `else` doesn’t call it at all, and the code inside the
-second `else` case calls it once.
-
-The desired behavior of the `generate_workout` function is to first check
-whether the user wants a low-intensity workout (indicated by a number less
-than 25) or a high-intensity workout (a number of 25 or greater).
-
-Low-intensity workout plans will recommend a number of push-ups and sit-ups
-based on the complex algorithm we’re simulating.
-
-If the user wants a high-intensity workout, there’s some additional logic: if
-the value of the random number generated by the app happens to be 3, the app
-will recommend a break and hydration. If not, the user will get a number of
-minutes of running based on the complex algorithm.
-
-This code works the way the business wants it to now, but let’s say the data
-science team decides that we need to make some changes to the way we call the
-`simulated_expensive_calculation` function in the future. To simplify the
-update when those changes happen, we want to refactor this code so it calls the
-`simulated_expensive_calculation` function only once. We also want to cut the
-place where we’re currently unnecessarily calling the function twice without
-adding any other calls to that function in the process. That is, we don’t want
-to call it if the result isn’t needed, and we still want to call it only once.
-
-#### Refactoring Using Functions
-
-We could restructure the workout program in many ways. First, we’ll try
-extracting the duplicated call to the `simulated_expensive_calculation`
-function into a variable, as shown in Listing 13-4:
-
-Filename: src/main.rs
-
-```
-fn generate_workout(intensity: u32, random_number: u32) {
-    let expensive_result =
-        simulated_expensive_calculation(intensity);
-
-    if intensity < 25 {
-        println!(
-            "Today, do {} pushups!",
-            expensive_result
-        );
-        println!(
-            "Next, do {} situps!",
-            expensive_result
-        );
-    } else {
-        if random_number == 3 {
-            println!("Take a break today! Remember to stay hydrated!");
-        } else {
-            println!(
-                "Today, run for {} minutes!",
-                expensive_result
-            );
-        }
-    }
-}
-```
-
-Listing 13-4: Extracting the calls to `simulated_expensive_calculation` to one
-place and storing the result in the `expensive_result` variable
-
-This change unifies all the calls to `simulated_expensive_calculation` and
-solves the problem of the first `if` block unnecessarily calling the function
-twice. Unfortunately, we’re now calling this function and waiting for the
-result in all cases, which includes the inner `if` block that doesn’t use the
-result value at all.
-
-We want to define code in one place in our program, but only *execute* that
-code where we actually need the result. This is a use case for closures!
-
-#### Refactoring with Closures to Store Code
-
-Instead of always calling the `simulated_expensive_calculation` function before
-the `if` blocks, we can define a closure and store the *closure* in a variable
-rather than storing the result of the function call, as shown in Listing 13-5.
-We can actually move the whole body of `simulated_expensive_calculation` within
-the closure we’re introducing here:
-
-Filename: src/main.rs
-
-```
-let expensive_closure = |num| {
-    println!("calculating slowly...");
-    thread::sleep(Duration::from_secs(2));
-    num
-};
-```
-
-Listing 13-5: Defining a closure and storing it in the `expensive_closure`
-variable
-
-The closure definition comes after the `=` to assign it to the variable
-`expensive_closure`. To define a closure, we start with a pair of vertical
-pipes (`|`), inside which we specify the parameters to the closure; this syntax
-was chosen because of its similarity to closure definitions in Smalltalk and
-Ruby. This closure has one parameter named `num`: if we had more than one
-parameter, we would separate them with commas, like `|param1, param2|`.
-
-After the parameters, we place curly brackets that hold the body of the
-closure—these are optional if the closure body is a single expression. The end
-of the closure, after the curly brackets, needs a semicolon to complete the
-`let` statement. The value returned from the last line in the closure body
-(`num`) will be the value returned from the closure when it’s called, because
-that line doesn’t end in a semicolon; just like in function bodies.
-
-Note that this `let` statement means `expensive_closure` contains the
-*definition* of an anonymous function, not the *resulting value* of calling the
-anonymous function. Recall that we’re using a closure because we want to define
-the code to call at one point, store that code, and call it at a later point;
-the code we want to call is now stored in `expensive_closure`.
-
-With the closure defined, we can change the code in the `if` blocks to call the
-closure to execute the code and get the resulting value. We call a closure like
-we do a function: we specify the variable name that holds the closure
-definition and follow it with parentheses containing the argument values we
-want to use, as shown in Listing 13-6:
-
-Filename: src/main.rs
-
-```
-fn generate_workout(intensity: u32, random_number: u32) {
-    let expensive_closure = |num| {
-        println!("calculating slowly...");
-        thread::sleep(Duration::from_secs(2));
-        num
-    };
-
-    if intensity < 25 {
-        println!(
-            "Today, do {} pushups!",
-            expensive_closure(intensity)
-        );
-        println!(
-            "Next, do {} situps!",
-            expensive_closure(intensity)
-        );
-    } else {
-        if random_number == 3 {
-            println!("Take a break today! Remember to stay hydrated!");
-        } else {
-            println!(
-                "Today, run for {} minutes!",
-                expensive_closure(intensity)
-            );
-        }
-    }
-}
-```
-
-Listing 13-6: Calling the `expensive_closure` we’ve defined
-
-Now the expensive calculation is called in only one place, and we’re only
-executing that code where we need the results.
-
-However, we’ve reintroduced one of the problems from Listing 13-3: we’re still
-calling the closure twice in the first `if` block, which will call the
-expensive code twice and make the user wait twice as long as they need to. We
-could fix this problem by creating a variable local to that `if` block to hold
-the result of calling the closure, but closures provide us with another
-solution. We’ll talk about that solution in a bit. But first let’s talk about
-why there aren’t type annotations in the closure definition and the traits
-involved with closures.
-
-### Closure Type Inference and Annotation
-
-Closures don’t require you to annotate the types of the parameters or the
-return value like `fn` functions do. Type annotations are required on functions
-because they’re part of an explicit interface exposed to your users. Defining
-this interface rigidly is important for ensuring that everyone agrees on what
-types of values a function uses and returns. But closures aren’t used in an
-exposed interface like this: they’re stored in variables and used without
-naming them and exposing them to users of our library.
-
-Closures are usually short and relevant only within a narrow context rather
-than in any arbitrary scenario. Within these limited contexts, the compiler is
-reliably able to infer the types of the parameters and the return type, similar
-to how it’s able to infer the types of most variables.
-
-Making programmers annotate the types in these small, anonymous functions would
-be annoying and largely redundant with the information the compiler already has
-available.
-
-As with variables, we can add type annotations if we want to increase
-explicitness and clarity at the cost of being more verbose than is strictly
-necessary. Annotating the types for the closure we defined in Listing 13-5
-would look like the definition shown in Listing 13-7:
-
-Filename: src/main.rs
-
-```
-let expensive_closure = |num: u32| -> u32 {
-    println!("calculating slowly...");
-    thread::sleep(Duration::from_secs(2));
-    num
-};
-```
-
-Listing 13-7: Adding optional type annotations of the parameter and return
-value types in the closure
-
-With type annotations added, the syntax of closures looks more similar to the
-syntax of functions. The following is a vertical comparison of the syntax for
-the definition of a function that adds 1 to its parameter and a closure that
-has the same behavior. We’ve added some spaces to line up the relevant parts.
-This illustrates how closure syntax is similar to function syntax except for
-the use of pipes and the amount of syntax that is optional:
-
-```
-fn  add_one_v1   (x: u32) -> u32 { x + 1 }
-let add_one_v2 = |x: u32| -> u32 { x + 1 };
-let add_one_v3 = |x|             { x + 1 };
-let add_one_v4 = |x|               x + 1  ;
-```
-
-The first line shows a function definition, and the second line shows a fully
-annotated closure definition. The third line removes the type annotations from
-the closure definition, and the fourth line removes the brackets, which are
-optional because the closure body has only one expression. These are all valid
-definitions that will produce the same behavior when they’re called.
-
-Closure definitions will have one concrete type inferred for each of their
-parameters and for their return value. For instance, Listing 13-8 shows the
-definition of a short closure that just returns the value it receives as a
-parameter. This closure isn’t very useful except for the purposes of this
-example. Note that we haven’t added any type annotations to the definition: if
-we then try to call the closure twice, using a `String` as an argument the
-first time and a `u32` the second time, we’ll get an error.
-
-Filename: src/main.rs
-
-```
-let example_closure = |x| x;
-
-let s = example_closure(String::from("hello"));
-let n = example_closure(5);
-```
-
-Listing 13-8: Attempting to call a closure whose types are inferred with two
-different types
-
-The compiler gives us this error:
-
-```
-error[E0308]: mismatched types
- --> src/main.rs
-  |
-  | let n = example_closure(5);
-  |                         ^ expected struct `std::string::String`, found
-  integral variable
-  |
-  = note: expected type `std::string::String`
-             found type `{integer}`
-```
-
-The first time we call `example_closure` with the `String` value, the compiler
-infers the type of `x` and the return type of the closure to be `String`. Those
-types are then locked in to the closure in `example_closure`, and we get a type
-error if we try to use a different type with the same closure.
-
-### Storing Closures Using Generic Parameters and the `Fn` Traits
-
-Let’s return to our workout generation app. In Listing 13-6, our code was still
-calling the expensive calculation closure more times than it needed to. One
-option to solve this issue is to save the result of the expensive closure in a
-variable for reuse and use the variable in each place we need the result,
-instead of calling the closure again. However, this method could result in a
-lot of repeated code.
-
-Fortunately, another solution is available to us. We can create a struct that
-will hold the closure and the resulting value of calling the closure. The
-struct will execute the closure only if we need the resulting value, and it
-will cache the resulting value so the rest of our code doesn’t have to be
-responsible for saving and reusing the result. You may know this pattern as
-*memoization* or *lazy evaluation*.
-
-To make a struct that holds a closure, we need to specify the type of the
-closure, because a struct definition needs to know the types of each of its
-fields. Each closure instance has its own unique anonymous type: that is, even
-if two closures have the same signature, their types are still considered
-different. To define structs, enums, or function parameters that use closures,
-we use generics and trait bounds, as we discussed in Chapter 10.
-
-The `Fn` traits are provided by the standard library. All closures implement at
-least one of the traits: `Fn`, `FnMut`, or `FnOnce`. We’ll discuss the
-difference between these traits in the “Capturing the Environment with
-Closures” section; in this example, we can use the `Fn` trait.
-
-We add types to the `Fn` trait bound to represent the types of the parameters
-and return values the closures must have to match this trait bound. In this
-case, our closure has a parameter of type `u32` and returns a `u32`, so the
-trait bound we specify is `Fn(u32) -> u32`.
-
-Listing 13-9 shows the definition of the `Cacher` struct that holds a closure
-and an optional result value:
-
-Filename: src/main.rs
-
-```
-struct Cacher
-    where T: Fn(u32) -> u32
-{
-    calculation: T,
-    value: Option,
-}
-```
-
-Listing 13-9: Defining a `Cacher` struct that holds a closure in `calculation`
-and an optional result in `value`
-
-The `Cacher` struct has a `calculation` field of the generic type `T`. The
-trait bounds on `T` specify that it’s a closure by using the `Fn` trait. Any
-closure we want to store in the `calculation` field must have one `u32`
-parameter (specified within the parentheses after `Fn`) and must return a
-`u32` (specified after the `->`).
-
-> Note: Functions implement all three of the `Fn` traits too. If what we want
-> to do doesn’t require capturing a value from the environment, we can use a
-> function rather than a closure where we need something that implements an `Fn`
-> trait.
-
-The `value` field is of type `Option`. Before we execute the closure,
-`value` will be `None`. When code using a `Cacher` asks for the *result* of the
-closure, the `Cacher` will execute the closure at that time and store the
-result within a `Some` variant in the `value` field. Then if the code asks for
-the result of the closure again, instead of executing the closure again, the
-`Cacher` will return the result held in the `Some` variant.
-
-The logic around the `value` field we’ve just described is defined in Listing
-13-10:
-
-Filename: src/main.rs
-
-```
-impl Cacher
-    where T: Fn(u32) -> u32
-{
-    fn new(calculation: T) -> Cacher {
-        Cacher {
-            calculation,
-            value: None,
-        }
-    }
-
-    fn value(&mut self, arg: u32) -> u32 {
-        match self.value {
-            Some(v) => v,
-            None => {
-                let v = (self.calculation)(arg);
-                self.value = Some(v);
-                v
-            },
-        }
-    }
-}
-```
-
-Listing 13-10: The caching logic of `Cacher`
-
-We want `Cacher` to manage the struct fields’ values rather than letting the
-calling code potentially change the values in these fields directly, so these
-fields are private.
-
-The `Cacher::new` function takes a generic parameter `T`, which we’ve defined
-as having the same trait bound as the `Cacher` struct. Then `Cacher::new`
-returns a `Cacher` instance that holds the closure specified in the
-`calculation` field and a `None` value in the `value` field, because we haven’t
-executed the closure yet.
-
-When the calling code needs the result of evaluating the closure, instead of
-calling the closure directly, it will call the `value` method. This method
-checks whether we already have a resulting value in `self.value` in a `Some`;
-if we do, it returns the value within the `Some` without executing the closure
-again.
-
-If `self.value` is `None`, the code calls the closure stored in
-`self.calculation`, saves the result in `self.value` for future use, and
-returns the value as well.
-
-Listing 13-11 shows how we can use this `Cacher` struct in the function
-`generate_workout` from Listing 13-6:
-
-Filename: src/main.rs
-
-```
-fn generate_workout(intensity: u32, random_number: u32) {
-    let mut expensive_result = Cacher::new(|num| {
-        println!("calculating slowly...");
-        thread::sleep(Duration::from_secs(2));
-        num
-    });
-
-    if intensity < 25 {
-        println!(
-            "Today, do {} pushups!",
-            expensive_result.value(intensity)
-        );
-        println!(
-            "Next, do {} situps!",
-            expensive_result.value(intensity)
-        );
-    } else {
-        if random_number == 3 {
-            println!("Take a break today! Remember to stay hydrated!");
-        } else {
-            println!(
-                "Today, run for {} minutes!",
-                expensive_result.value(intensity)
-            );
-        }
-    }
-}
-```
-
-Listing 13-11: Using `Cacher` in the `generate_workout` function to abstract
-away the caching logic
-
-Instead of saving the closure in a variable directly, we save a new instance of
-`Cacher` that holds the closure. Then, in each place we want the result, we
-call the `value` method on the `Cacher` instance. We can call the `value`
-method as many times as we want, or not call it at all, and the expensive
-calculation will be run a maximum of once.
-
-Try running this program with the `main` function from Listing 13-2. Change the
-values in the `simulated_user_specified_value` and `simulated_random_number`
-variables to verify that in all the cases in the various `if` and `else`
-blocks, `calculating slowly...` appears only once and only when needed. The
-`Cacher` takes care of the logic necessary to ensure we aren’t calling the
-expensive calculation more than we need to so `generate_workout` can focus on
-the business logic.
-
-### Limitations of the `Cacher` Implementation
-
-Caching values is a generally useful behavior that we might want to use in
-other parts of our code with different closures. However, there are two
-problems with the current implementation of `Cacher` that would make reusing it
-in different contexts difficult.
-
-The first problem is that a `Cacher` instance assumes it will always get the
-same value for the parameter `arg` to the `value` method. That is, this test of
-`Cacher` will fail:
-
-```
-#[test]
-fn call_with_different_values() {
-    let mut c = Cacher::new(|a| a);
-
-    let v1 = c.value(1);
-    let v2 = c.value(2);
-
-    assert_eq!(v2, 2);
-}
-```
-
-This test creates a new `Cacher` instance with a closure that returns the value
-passed into it. We call the `value` method on this `Cacher` instance with an
-`arg` value of 1 and then an `arg` value of 2, and we expect the call to
-`value` with the `arg` value of 2 should return 2.
-
-Run this test with the `Cacher` implementation in Listing 13-9 and Listing
-13-10, and the test will fail on the `assert_eq!` with this message:
-
-```
-thread 'call_with_different_values' panicked at 'assertion failed: `(left == right)`
-  left: `1`,
- right: `2`', src/main.rs
-```
-
-The problem is that the first time we called `c.value` with 1, the `Cacher`
-instance saved `Some(1)` in `self.value`. Thereafter, no matter what we pass in
-to the `value` method, it will always return 1.
-
-Try modifying `Cacher` to hold a hash map rather than a single value. The keys
-of the hash map will be the `arg` values that are passed in, and the values of
-the hash map will be the result of calling the closure on that key. Instead of
-looking at whether `self.value` directly has a `Some` or a `None` value, the
-`value` function will look up the `arg` in the hash map and return the value if
-it’s present. If it’s not present, the `Cacher` will call the closure and save
-the resulting value in the hash map associated with its `arg` value.
-
-The second problem with the current `Cacher` implementation is that it only
-accepts closures that take one parameter of type `u32` and return a `u32`. We
-might want to cache the results of closures that take a string slice and return
-`usize` values, for example. To fix this issue, try introducing more generic
-parameters to increase the flexibility of the `Cacher` functionality.
-
-### Capturing the Environment with Closures
-
-In the workout generator example, we only used closures as inline anonymous
-functions. However, closures have an additional capability that functions don’t
-have: they can capture their environment and access variables from the scope in
-which they’re defined.
-
-Listing 13-12 has an example of a closure stored in the `equal_to_x` variable
-that uses the `x` variable from the closure’s surrounding environment:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 4;
-
-    let equal_to_x = |z| z == x;
-
-    let y = 4;
-
-    assert!(equal_to_x(y));
-}
-```
-
-Listing 13-12: Example of a closure that refers to a variable in its enclosing
-scope
-
-Here, even though `x` is not one of the parameters of `equal_to_x`, the
-`equal_to_x` closure is allowed to use the `x` variable that’s defined in the
-same scope that `equal_to_x` is defined in.
-
-We can’t do the same with functions; if we try with the following example, our
-code won’t compile:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 4;
-
-    fn equal_to_x(z: i32) -> bool { z == x }
-
-    let y = 4;
-
-    assert!(equal_to_x(y));
-}
-```
-
-We get an error:
-
-```
-error[E0434]: can't capture dynamic environment in a fn item; use the || { ...
-} closure form instead
- --> src/main.rs
-  |
-4 |     fn equal_to_x(z: i32) -> bool { z == x }
-  |                                          ^
-```
-
-The compiler even reminds us that this only works with closures!
-
-When a closure captures a value from its environment, it uses memory to store
-the values for use in the closure body. This use of memory is overhead that we
-don’t want to pay in more common cases where we want to execute code that
-doesn’t capture its environment. Because functions are never allowed to capture
-their environment, defining and using functions will never incur this overhead.
-
-Closures can capture values from their environment in three ways, which
-directly map to the three ways a function can take a parameter: taking
-ownership, borrowing mutably, and borrowing immutably. These are encoded in the
-three `Fn` traits as follows:
-
-* `FnOnce` consumes the variables it captures from its enclosing scope, known
-  as the closure’s *environment*. To consume the captured variables, the
-  closure must take ownership of these variables and move them into the closure
-  when it is defined. The `Once` part of the name represents the fact that the
-  closure can’t take ownership of the same variables more than once, so it can
-  be called only once.
-* `FnMut` can change the environment because it mutably borrows values.
-* `Fn` borrows values from the environment immutably.
-
-When you create a closure, Rust infers which trait to use based on how the
-closure uses the values from the environment. All closures implement `FnOnce`
-because they can all be called at least once. Closures that don’t move the
-captured variables also implement `FnMut`, and closures that don’t need mutable
-access to the captured variables also implement `Fn`. In Listing 13-12, the
-`equal_to_x` closure borrows `x` immutably (so `equal_to_x` has the `Fn` trait)
-because the body of the closure only needs to read the value in `x`.
-
-If you want to force the closure to take ownership of the values it uses in the
-environment, you can use the `move` keyword before the parameter list. This
-technique is mostly useful when passing a closure to a new thread to move the
-data so it’s owned by the new thread.
-
-We’ll have more examples of `move` closures in Chapter 16 when we talk about
-concurrency. For now, here’s the code from Listing 13-12 with the `move`
-keyword added to the closure definition and using vectors instead of integers,
-because integers can be copied rather than moved; note that this code will not
-yet compile.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = vec![1, 2, 3];
-
-    let equal_to_x = move |z| z == x;
-
-    println!("can't use x here: {:?}", x);
-
-    let y = vec![1, 2, 3];
-
-    assert!(equal_to_x(y));
-}
-```
-
-We receive the following error:
-
-```
-error[E0382]: use of moved value: `x`
- --> src/main.rs:6:40
-  |
-4 |     let equal_to_x = move |z| z == x;
-  |                      -------- value moved (into closure) here
-5 |
-6 |     println!("can't use x here: {:?}", x);
-  |                                        ^ value used here after move
-  |
-  = note: move occurs because `x` has type `std::vec::Vec`, which does not
-  implement the `Copy` trait
-```
-
-The `x` value is moved into the closure when the closure is defined, because we
-added the `move` keyword. The closure then has ownership of `x`, and `main`
-isn’t allowed to use `x` anymore in the `println!` statement. Removing
-`println!` will fix this example.
-
-Most of the time when specifying one of the `Fn` trait bounds, you can start
-with `Fn` and the compiler will tell you if you need `FnMut` or `FnOnce` based
-on what happens in the closure body.
-
-To illustrate situations where closures that can capture their environment are
-useful as function parameters, let’s move on to our next topic: iterators.
-
-## Processing a Series of Items with Iterators
-
-The iterator pattern allows you to perform some task on a sequence of items in
-turn. An iterator is responsible for the logic of iterating over each item and
-determining when the sequence has finished. When you use iterators, you don’t
-have to reimplement that logic yourself.
-
-In Rust, iterators are *lazy*, meaning they have no effect until you call
-methods that consume the iterator to use it up. For example, the code in
-Listing 13-13 creates an iterator over the items in the vector `v1` by calling
-the `iter` method defined on `Vec`. This code by itself doesn’t do anything
-useful.
-
-```
-let v1 = vec![1, 2, 3];
-
-let v1_iter = v1.iter();
-```
-
-Listing 13-13: Creating an iterator
-
-Once we’ve created an iterator, we can use it in a variety of ways. In Listing
-3-5 in Chapter 3, we used iterators with `for` loops to execute some code on
-each item, although we glossed over what the call to `iter` did until now.
-
-The example in Listing 13-14 separates the creation of the iterator from the
-use of the iterator in the `for` loop. The iterator is stored in the `v1_iter`
-variable, and no iteration takes place at that time. When the `for` loop is
-called using the iterator in `v1_iter`, each element in the iterator is used in
-one iteration of the loop, which prints out each value.
-
-```
-let v1 = vec![1, 2, 3];
-
-let v1_iter = v1.iter();
-
-for val in v1_iter {
-    println!("Got: {}", val);
-}
-```
-
-Listing 13-14: Using an iterator in a `for` loop
-
-In languages that don’t have iterators provided by their standard libraries,
-you would likely write this same functionality by starting a variable at index
-0, using that variable to index into the vector to get a value, and
-incrementing the variable value in a loop until it reached the total number of
-items in the vector.
-
-Iterators handle all that logic for you, cutting down on repetitive code you
-could potentially mess up. Iterators give you more flexibility to use the same
-logic with many different kinds of sequences, not just data structures you can
-index into, like vectors. Let’s examine how iterators do that.
-
-### The `Iterator` Trait and the `next` Method
-
-All iterators implement a trait named `Iterator` that is defined in the
-standard library. The definition of the trait looks like this:
-
-```
-trait Iterator {
-    type Item;
-
-    fn next(&mut self) -> Option;
-
-    // methods with default implementations elided
-}
-```
-
-Notice this definition uses some new syntax: `type Item` and `Self::Item`,
-which are defining an *associated type* with this trait. We’ll talk about
-associated types in depth in Chapter 19. For now, all you need to know is that
-this code says implementing the `Iterator` trait requires that you also define
-an `Item` type, and this `Item` type is used in the return type of the `next`
-method. In other words, the `Item` type will be the type returned from the
-iterator.
-
-The `Iterator` trait only requires implementors to define one method: the
-`next` method, which returns one item of the iterator at a time wrapped in
-`Some` and, when iteration is over, returns `None`.
-
-We can call the `next` method on iterators directly; Listing 13-15 demonstrates
-what values are returned from repeated calls to `next` on the iterator created
-from the vector:
-
-Filename: src/lib.rs
-
-```
-#[test]
-fn iterator_demonstration() {
-    let v1 = vec![1, 2, 3];
-
-    let mut v1_iter = v1.iter();
-
-    assert_eq!(v1_iter.next(), Some(&1));
-    assert_eq!(v1_iter.next(), Some(&2));
-    assert_eq!(v1_iter.next(), Some(&3));
-    assert_eq!(v1_iter.next(), None);
-}
-```
-
-Listing 13-15: Calling the `next` method on an iterator
-
-Note that we needed to make `v1_iter` mutable: calling the `next` method on an
-iterator changes internal state that the iterator uses to keep track of where
-it is in the sequence. In other words, this code *consumes*, or uses up, the
-iterator. Each call to `next` eats up an item from the iterator. We didn’t need
-to make `v1_iter` mutable when we used a `for` loop because the loop took
-ownership of `v1_iter` and made it mutable behind the scenes.
-
-Also note that the values we get from the calls to `next` are immutable
-references to the values in the vector. The `iter` method produces an iterator
-over immutable references. If we want to create an iterator that takes
-ownership of `v1` and returns owned values, we can call `into_iter` instead of
-`iter`. Similarly, if we want to iterate over mutable references, we can call
-`iter_mut` instead of `iter`.
-
-### Methods that Consume the Iterator
-
-The `Iterator` trait has a number of different methods with default
-implementations provided by the standard library; you can find out about these
-methods by looking in the standard library API documentation for the `Iterator`
-trait. Some of these methods call the `next` method in their definition, which
-is why you’re required to implement the `next` method when implementing the
-`Iterator` trait.
-
-Methods that call `next` are called *consuming adaptors*, because calling them
-uses up the iterator. One example is the `sum` method, which takes ownership of
-the iterator and iterates through the items by repeatedly calling `next`, thus
-consuming the iterator. As it iterates through, it adds each item to a running
-total and returns the total when iteration is complete. Listing 13-16 has a
-test illustrating a use of the `sum` method:
-
-Filename: src/lib.rs
-
-```
-#[test]
-fn iterator_sum() {
-    let v1 = vec![1, 2, 3];
-
-    let v1_iter = v1.iter();
-
-    let total: i32 = v1_iter.sum();
-
-    assert_eq!(total, 6);
-}
-```
-
-Listing 13-16: Calling the `sum` method to get the total of all items in the
-iterator
-
-We aren’t allowed to use `v1_iter` after the call to `sum` because `sum` takes
-ownership of the iterator we call it on.
-
-### Methods that Produce Other Iterators
-
-Other methods defined on the `Iterator` trait, known as *iterator adaptors*,
-allow you to change iterators into different kinds of iterators. You can chain
-multiple calls to iterator adaptors to perform complex actions in a readable
-way. But because all iterators are lazy, you have to call one of the consuming
-adaptor methods to get results from calls to iterator adaptors.
-
-Listing 13-17 shows an example of calling the iterator adaptor method `map`,
-which takes a closure to call on each item to produce a new iterator. The
-closure here creates a new iterator in which each item from the vector has been
-incremented by 1. However, this code produces a warning:
-
-Filename: src/main.rs
-
-```
-let v1: Vec = vec![1, 2, 3];
-
-v1.iter().map(|x| x + 1);
-```
-
-Listing 13-17: Calling the iterator adaptor `map` to create a new iterator
-
-The warning we get is this:
-
-```
-warning: unused `std::iter::Map` which must be used: iterator adaptors are lazy
-and do nothing unless consumed
- --> src/main.rs:4:5
-  |
-4 |     v1.iter().map(|x| x + 1);
-  |     ^^^^^^^^^^^^^^^^^^^^^^^^^
-  |
-  = note: #[warn(unused_must_use)] on by default
-```
-
-The code in Listing 13-17 doesn’t do anything; the closure we’ve specified
-never gets called. The warning reminds us why: iterator adaptors are lazy, and
-we need to consume the iterator here.
-
-To fix this and consume the iterator, we’ll use the `collect` method, which we
-used in Chapter 12 with `env::args` in Listing 12-1. This method consumes the
-iterator and collects the resulting values into a collection data type.
-
-In Listing 13-18, we collect the results of iterating over the iterator that’s
-returned from the call to `map` into a vector. This vector will end up
-containing each item from the original vector incremented by 1.
-
-Filename: src/main.rs
-
-```
-let v1: Vec = vec![1, 2, 3];
-
-let v2: Vec<_> = v1.iter().map(|x| x + 1).collect();
-
-assert_eq!(v2, vec![2, 3, 4]);
-```
-
-Listing 13-18: Calling the `map` method to create a new iterator and then
-calling the `collect` method to consume the new iterator and create a vector
-
-Because `map` takes a closure, we can specify any operation we want to perform
-on each item. This is a great example of how closures let you customize some
-behavior while reusing the iteration behavior that the `Iterator` trait
-provides.
-
-### Using Closures that Capture Their Environment
-
-Now that we’ve introduced iterators, we can demonstrate a common use of
-closures that capture their environment by using the `filter` iterator adaptor.
-The `filter` method on an iterator takes a closure that takes each item from
-the iterator and returns a Boolean. If the closure returns `true`, the value
-will be included in the iterator produced by `filter`. If the closure returns
-`false`, the value won’t be included in the resulting iterator.
-
-In Listing 13-19, we use `filter` with a closure that captures the `shoe_size`
-variable from its environment to iterate over a collection of `Shoe` struct
-instances. It will return only shoes that are the specified size.
-
-Filename: src/lib.rs
-
-```
-#[derive(PartialEq, Debug)]
-struct Shoe {
-    size: u32,
-    style: String,
-}
-
-fn shoes_in_my_size(shoes: Vec, shoe_size: u32) -> Vec {
-    shoes.into_iter()
-        .filter(|s| s.size == shoe_size)
-        .collect()
-}
-
-#[test]
-fn filters_by_size() {
-    let shoes = vec![
-        Shoe { size: 10, style: String::from("sneaker") },
-        Shoe { size: 13, style: String::from("sandal") },
-        Shoe { size: 10, style: String::from("boot") },
-    ];
-
-    let in_my_size = shoes_in_my_size(shoes, 10);
-
-    assert_eq!(
-        in_my_size,
-        vec![
-            Shoe { size: 10, style: String::from("sneaker") },
-            Shoe { size: 10, style: String::from("boot") },
-        ]
-    );
-}
-```
-
-Listing 13-19: Using the `filter` method with a closure that captures
-`shoe_size`
-
-The `shoes_in_my_size` function takes ownership of a vector of shoes and a shoe
-size as parameters. It returns a vector containing only shoes of the specified
-size.
-
-In the body of `shoes_in_my_size`, we call `into_iter` to create an iterator
-that takes ownership of the vector. Then we call `filter` to adapt that
-iterator into a new iterator that only contains elements for which the closure
-returns `true`.
-
-The closure captures the `shoe_size` parameter from the environment and
-compares the value with each shoe’s size, keeping only shoes of the size
-specified. Finally, calling `collect` gathers the values returned by the
-adapted iterator into a vector that’s returned by the function.
-
-The test shows that when we call `shoes_in_my_size`, we get back only shoes
-that have the same size as the value we specified.
-
-### Creating Our Own Iterators with the `Iterator` Trait
-
-We’ve shown that you can create an iterator by calling `iter`, `into_iter`, or
-`iter_mut` on a vector. You can create iterators from the other collection
-types in the standard library, such as hash map. You can also create iterators
-that do anything you want by implementing the `Iterator` trait on your own
-types. As previously mentioned, the only method you’re required to provide a
-definition for is the `next` method. Once you’ve done that, you can use all
-other methods that have default implementations provided by the `Iterator`
-trait!
-
-To demonstrate, let’s create an iterator that will only ever count from 1 to 5.
-First, we’ll create a struct to hold some values. Then we’ll make this struct
-into an iterator by implementing the `Iterator` trait and using the values in
-that implementation.
-
-Listing 13-20 has the definition of the `Counter` struct and an associated
-`new` function to create instances of `Counter`:
-
-Filename: src/lib.rs
-
-```
-struct Counter {
-    count: u32,
-}
-
-impl Counter {
-    fn new() -> Counter {
-        Counter { count: 0 }
-    }
-}
-```
-
-Listing 13-20: Defining the `Counter` struct and a `new` function that creates
-instances of `Counter` with an initial value of 0 for `count`
-
-The `Counter` struct has one field named `count`. This field holds a `u32`
-value that will keep track of where we are in the process of iterating from 1
-to 5. The `count` field is private because we want the implementation of
-`Counter` to manage its value. The `new` function enforces the behavior of
-always starting new instances with a value of 0 in the `count` field.
-
-Next, we’ll implement the `Iterator` trait for our `Counter` type by defining
-the body of the `next` method to specify what we want to happen when this
-iterator is used, as shown in Listing 13-21:
-
-Filename: src/lib.rs
-
-```
-impl Iterator for Counter {
-    type Item = u32;
-
-    fn next(&mut self) -> Option {
-        self.count += 1;
-
-        if self.count < 6 {
-            Some(self.count)
-        } else {
-            None
-        }
-    }
-}
-```
-
-Listing 13-21: Implementing the `Iterator` trait on our `Counter` struct
-
-We set the associated `Item` type for our iterator to `u32`, meaning the
-iterator will return `u32` values. Again, don’t worry about associated types
-yet, we’ll cover them in Chapter 19.
-
-We want our iterator to add 1 to the current state, so we initialized `count`
-to 0 so it would return 1 first. If the value of `count` is less than 6, `next`
-will return the current value wrapped in `Some`, but if `count` is 6 or higher,
-our iterator will return `None`.
-
-#### Using Our `Counter` Iterator’s `next` Method
-
-Once we’ve implemented the `Iterator` trait, we have an iterator! Listing 13-22
-shows a test demonstrating that we can use the iterator functionality of our
-`Counter` struct by calling the `next` method on it directly, just as we did
-with the iterator created from a vector in Listing 13-15.
-
-Filename: src/lib.rs
-
-```
-#[test]
-fn calling_next_directly() {
-    let mut counter = Counter::new();
-
-    assert_eq!(counter.next(), Some(1));
-    assert_eq!(counter.next(), Some(2));
-    assert_eq!(counter.next(), Some(3));
-    assert_eq!(counter.next(), Some(4));
-    assert_eq!(counter.next(), Some(5));
-    assert_eq!(counter.next(), None);
-}
-```
-
-Listing 13-22: Testing the functionality of the `next` method implementation
-
-This test creates a new `Counter` instance in the `counter` variable and then
-calls `next` repeatedly, verifying that we have implemented the behavior we
-want this iterator to have: returning the values from 1 to 5.
-
-#### Using Other `Iterator` Trait Methods
-
-We implemented the `Iterator` trait by defining the `next` method, so we
-can now use any `Iterator` trait method’s default implementations as defined in
-the standard library, because they all use the `next` method’s functionality.
-
-For example, if for some reason we wanted to take the values produced by an
-instance of `Counter`, pair them with values produced by another `Counter`
-instance after skipping the first value, multiply each pair together, keep only
-those results that are divisible by 3, and add all the resulting values
-together, we could do so, as shown in the test in Listing 13-23:
-
-Filename: src/lib.rs
-
-```
-#[test]
-fn using_other_iterator_trait_methods() {
-    let sum: u32 = Counter::new().zip(Counter::new().skip(1))
-                                 .map(|(a, b)| a * b)
-                                 .filter(|x| x % 3 == 0)
-                                 .sum();
-    assert_eq!(18, sum);
-}
-```
-
-Listing 13-23: Using a variety of `Iterator` trait methods on our `Counter`
-iterator
-
-Note that `zip` produces only four pairs; the theoretical fifth pair `(5,
-None)` is never produced because `zip` returns `None` when either of its input
-iterators return `None`.
-
-All of these method calls are possible because we specified how the `next`
-method works, and the standard library provides default implementations for
-other methods that call `next`.
-
-## Improving Our I/O Project
-
-With this new knowledge about iterators, we can improve the I/O project in
-Chapter 12 by using iterators to make places in the code clearer and more
-concise. Let’s look at how iterators can improve our implementation of the
-`Config::new` function and the `search` function.
-
-
-### Removing a `clone` Using an Iterator
-
-In Listing 12-6, we added code that took a slice of `String` values and created
-an instance of the `Config` struct by indexing into the slice and cloning the
-values, allowing the `Config` struct to own those values. In Listing 13-24,
-we’ve reproduced the implementation of the `Config::new` function as it was in
-Listing 12-23:
-
-Filename: src/lib.rs
-
-```
-impl Config {
-    pub fn new(args: &[String]) -> Result {
-        if args.len() < 3 {
-            return Err("not enough arguments");
-        }
-
-        let query = args[1].clone();
-        let filename = args[2].clone();
-
-        let case_sensitive = env::var("CASE_INSENSITIVE").is_err();
-
-        Ok(Config { query, filename, case_sensitive })
-    }
-}
-```
-
-Listing 13-24: Reproduction of the `Config::new` function from Listing 12-23
-
-At the time, we said not to worry about the inefficient `clone` calls because
-we would remove them in the future. Well, that time is now!
-
-We needed `clone` here because we have a slice with `String` elements in the
-parameter `args`, but the `new` function doesn’t own `args`. To return
-ownership of a `Config` instance, we had to clone the values from the `query`
-and `filename` fields of `Config` so the `Config` instance can own its values.
-
-With our new knowledge about iterators, we can change the `new` function to
-take ownership of an iterator as its argument instead of borrowing a slice.
-We’ll use the iterator functionality instead of the code that checks the length
-of the slice and indexes into specific locations. This will clarify what the
-`Config::new` function is doing because the iterator will access the values.
-
-Once `Config::new` takes ownership of the iterator and stops using indexing
-operations that borrow, we can move the `String` values from the iterator into
-`Config` rather than calling `clone` and making a new allocation.
-
-#### Using the Returned Iterator Directly
-
-Open your I/O project’s *src/main.rs* file, which should look like this:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let args: Vec = env::args().collect();
-
-    let config = Config::new(&args).unwrap_or_else(|err| {
-        eprintln!("Problem parsing arguments: {}", err);
-        process::exit(1);
-    });
-
-    // --snip--
-}
-```
-
-We’ll change the start of the `main` function that we had in Listing 12-24 at
-to the code in Listing 13-25. This won’t compile until we update `Config::new`
-as well.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let config = Config::new(env::args()).unwrap_or_else(|err| {
-        eprintln!("Problem parsing arguments: {}", err);
-        process::exit(1);
-    });
-
-    // --snip--
-}
-```
-
-Listing 13-25: Passing the return value of `env::args` to `Config::new`
-
-The `env::args` function returns an iterator! Rather than collecting the
-iterator values into a vector and then passing a slice to `Config::new`, now
-we’re passing ownership of the iterator returned from `env::args` to
-`Config::new` directly.
-
-Next, we need to update the definition of `Config::new`. In your I/O project’s
-*src/lib.rs* file, let’s change the signature of `Config::new` to look like
-Listing 13-26. This still won’t compile because we need to update the function
-body.
-
-Filename: src/lib.rs
-
-```
-impl Config {
-    pub fn new(mut args: std::env::Args) -> Result {
-        // --snip--
-```
-
-Listing 13-26: Updating the signature of `Config::new` to expect an iterator
-
-The standard library documentation for the `env::args` function shows that the
-type of the iterator it returns is `std::env::Args`. We’ve updated the
-signature of the `Config::new` function so the parameter `args` has the type
-`std::env::Args` instead of `&[String]`. Because we’re taking ownership of
-`args` and we’ll be mutating `args` by iterating over it, we can add the `mut`
-keyword into the specification of the `args` parameter to make it mutable.
-
-#### Using `Iterator` Trait Methods Instead of Indexing
-
-Next, we’ll fix the body of `Config::new`. The standard library documentation
-also mentions that `std::env::Args` implements the `Iterator` trait, so we know
-we can call the `next` method on it! Listing 13-27 updates the code from
-Listing 12-23 to use the `next` method:
-
-Filename: src/lib.rs
-
-```
-impl Config {
-    pub fn new(mut args: std::env::Args) -> Result {
-        args.next();
-
-        let query = match args.next() {
-            Some(arg) => arg,
-            None => return Err("Didn't get a query string"),
-        };
-
-        let filename = match args.next() {
-            Some(arg) => arg,
-            None => return Err("Didn't get a file name"),
-        };
-
-        let case_sensitive = env::var("CASE_INSENSITIVE").is_err();
-
-        Ok(Config { query, filename, case_sensitive })
-    }
-}
-```
-
-Listing 13-27: Changing the body of `Config::new` to use iterator methods
-
-Remember that the first value in the return value of `env::args` is the name of
-the program. We want to ignore that and get to the next value, so first we call
-`next` and do nothing with the return value. Second, we call `next` to get the
-value we want to put in the `query` field of `Config`. If `next` returns a
-`Some`, we use a `match` to extract the value. If it returns `None`, it means
-not enough arguments were given and we return early with an `Err` value. We do
-the same thing for the `filename` value.
-
-### Making Code Clearer with Iterator Adaptors
-
-We can also take advantage of iterators in the `search` function in our I/O
-project, which is reproduced here in Listing 13-28 as it was in Listing 12-19:
-
-Filename: src/lib.rs
-
-```
-pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
-    let mut results = Vec::new();
-
-    for line in contents.lines() {
-        if line.contains(query) {
-            results.push(line);
-        }
-    }
-
-    results
-}
-```
-
-Listing 13-28: The implementation of the `search` function from Listing 12-19
-
-We can write this code in a more concise way using iterator adaptor methods.
-Doing so also lets us avoid having a mutable intermediate `results` vector. The
-functional programming style prefers to minimize the amount of mutable state to
-make code clearer. Removing the mutable state might enable a future enhancement
-to make searching happen in parallel, because we wouldn’t have to manage
-concurrent access to the `results` vector. Listing 13-29 shows this change:
-
-Filename: src/lib.rs
-
-```
-pub fn search<'a>(query: &str, contents: &'a str) -> Vec<&'a str> {
-    contents.lines()
-        .filter(|line| line.contains(query))
-        .collect()
-}
-```
-
-Listing 13-29: Using iterator adaptor methods in the implementation of the
-`search` function
-
-Recall that the purpose of the `search` function is to return all lines in
-`contents` that contain the `query`. Similar to the `filter` example in Listing
-13-19, this code uses the `filter` adaptor to keep only the lines that
-`line.contains(query)` returns `true` for. We then collect the matching lines
-into another vector with `collect`. Much simpler! Feel free to make the same
-change to use iterator methods in the `search_case_insensitive` function as
-well.
-
-The next logical question is which style you should choose in your own code and
-why: the original implementation in Listing 13-28 or the version using
-iterators in Listing 13-29. Most Rust programmers prefer to use the iterator
-style. It’s a bit tougher to get the hang of at first, but once you get a feel
-for the various iterator adaptors and what they do, iterators can be easier to
-understand. Instead of fiddling with the various bits of looping and building
-new vectors, the code focuses on the high-level objective of the loop. This
-abstracts away some of the commonplace code so it’s easier to see the concepts
-that are unique to this code, such as the filtering condition each element in
-the iterator must pass.
-
-But are the two implementations truly equivalent? The intuitive assumption
-might be that the more low-level loop will be faster. Let’s talk about
-performance.
-
-## Comparing Performance: Loops vs. Iterators
-
-To determine whether to use loops or iterators, you need to know which version
-of our `search` functions is faster: the version with an explicit `for` loop or
-the version with iterators.
-
-We ran a benchmark by loading the entire contents of *The Adventures of
-Sherlock Holmes* by Sir Arthur Conan Doyle into a `String` and looking for the
-word *the* in the contents. Here are the results of the benchmark on the
-version of `search` using the `for` loop and the version using iterators:
-
-```
-test bench_search_for  ... bench:  19,620,300 ns/iter (+/- 915,700)
-test bench_search_iter ... bench:  19,234,900 ns/iter (+/- 657,200)
-```
-
-The iterator version was slightly faster! We won’t explain the benchmark code
-here, because the point is not to prove that the two versions are equivalent
-but to get a general sense of how these two implementations compare
-performance-wise.
-
-For a more comprehensive benchmark, you should check using various texts of
-various sizes as the `contents`, different words and words of different lengths
-as the `query`, and all kinds of other variations. The point is this:
-iterators, although a high-level abstraction, get compiled down to roughly the
-same code as if you’d written the lower-level code yourself. Iterators are one
-of Rust’s *zero-cost abstractions*, by which we mean using the abstraction
-imposes no additional runtime overhead. This is analogous to how Bjarne
-Stroustrup, the original designer and implementor of C++, defines
-*zero-overhead* in “Foundations of C++” (2012):
-
-> In general, C++ implementations obey the zero-overhead principle: What you
-> don’t use, you don’t pay for. And further: What you do use, you couldn’t hand
-> code any better.
-
-As another example, the following code is taken from an audio decoder. The
-decoding algorithm uses the linear prediction mathematical operation to
-estimate future values based on a linear function of the previous samples. This
-code uses an iterator chain to do some math on three variables in scope: a
-`buffer` slice of data, an array of 12 `coefficients`, and an amount by which
-to shift data in `qlp_shift`. We’ve declared the variables within this example
-but not given them any values; although this code doesn’t have much meaning
-outside of its context, it’s still a concise, real-world example of how Rust
-translates high-level ideas to low-level code.
-
-```
-let buffer: &mut [i32];
-let coefficients: [i64; 12];
-let qlp_shift: i16;
-
-for i in 12..buffer.len() {
-    let prediction = coefficients.iter()
-                                 .zip(&buffer[i - 12..i])
-                                 .map(|(&c, &s)| c * s as i64)
-                                 .sum::() >> qlp_shift;
-    let delta = buffer[i];
-    buffer[i] = prediction as i32 + delta;
-}
-```
-
-To calculate the value of `prediction`, this code iterates through each of the
-12 values in `coefficients` and uses the `zip` method to pair the coefficient
-values with the previous 12 values in `buffer`. Then, for each pair, we
-multiply the values together, sum all the results, and shift the bits in the
-sum `qlp_shift` bits to the right.
-
-Calculations in applications like audio decoders often prioritize performance
-most highly. Here, we’re creating an iterator, using two adaptors, and then
-consuming the value. What assembly code would this Rust code compile to? Well,
-as of this writing, it compiles down to the same assembly you’d write by hand.
-There’s no loop at all corresponding to the iteration over the values in
-`coefficients`: Rust knows that there are 12 iterations, so it “unrolls” the
-loop. *Unrolling* is an optimization that removes the overhead of the loop
-controlling code and instead generates repetitive code for each iteration of
-the loop.
-
-All of the coefficients get stored in registers, which means accessing the
-values is very fast. There are no bounds checks on the array access at runtime.
-All these optimizations that Rust is able to apply make the resulting code
-extremely efficient. Now that you know this, you can use iterators and closures
-without fear! They make code seem like it’s higher level but don’t impose a
-runtime performance penalty for doing so.
-
-## Summary
-
-Closures and iterators are Rust features inspired by functional programming
-language ideas. They contribute to Rust’s capability to clearly express
-high-level ideas at low-level performance. The implementations of closures and
-iterators are such that runtime performance is not affected. This is part of
-Rust’s goal to strive to provide zero-cost abstractions.
-
-Now that we’ve improved the expressiveness of our I/O project, let’s look at
-some more features of `cargo` that will help us share the project with the
-world.
diff --git a/src/doc/book/second-edition/nostarch/chapter14.md b/src/doc/book/second-edition/nostarch/chapter14.md
deleted file mode 100644
index 2cbdde02f3..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter14.md
+++ /dev/null
@@ -1,984 +0,0 @@
-
-[TOC]
-
-# More About Cargo and Crates.io
-
-So far we’ve used only the most basic features of Cargo to build, run, and test
-our code, but it can do a lot more. In this chapter, we’ll discuss some of its
-other, more advanced features to show you how to:
-
-* Customize your build through release profiles
-* Publish libraries on *https://crates.io/*
-* Organize large projects with workspaces
-* Install binaries from *https://crates.io/*
-* Extend Cargo using custom commands
-
-Cargo can do even more than what we cover in this chapter, so for a full
-explanation of all its features, see its documentation at
-*https://doc.rust-lang.org/cargo/*.
-
-## Customizing Builds with Release Profiles
-
-In Rust, *release profiles* are predefined and customizable profiles with
-different configurations that allow a programmer to have more control over
-various options for compiling code. Each profile is configured independently of
-the others.
-
-Cargo has two main profiles: the `dev` profile Cargo uses when you run `cargo
-build` and the `release` profile Cargo uses when you run `cargo build
---release`. The `dev` profile is defined with good defaults for developing, and
-the `release` profile has good defaults for release builds.
-
-These profile names might be familiar from the output of your builds, which
-shows the profile used in the build:
-
-```
-$ cargo build
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-$ cargo build --release
-    Finished release [optimized] target(s) in 0.0 secs
-```
-
-The `dev` and `release` shown in this build output indicate that the compiler
-is using different profiles.
-
-Cargo has default settings for each of the profiles that apply when there
-aren’t any `[profile.*]` sections in the project’s *Cargo.toml* file. By adding
-`[profile.*]` sections for any profile we want to customize, we can override
-any subset of the default settings. For example, here are the default values
-for the `opt-level` setting for the `dev` and `release` profiles:
-
-Filename: Cargo.toml
-
-```
-[profile.dev]
-opt-level = 0
-
-[profile.release]
-opt-level = 3
-```
-
-The `opt-level` setting controls the number of optimizations Rust will apply to
-your code with a range of zero to three. Applying more optimizations extends
-compiling time, so if you’re in development and compiling your code often, you
-want faster compiling even at the expense of the resulting code running slower.
-That is the reason the default `opt-level` for `dev` is `0`. When you’re ready
-to release your code, it’s best to spend more time compiling. You’ll only
-compile in release mode once and run the compiled program many times, so
-release mode trades longer compile time for code that runs faster. That is the
-reason the default `opt-level` for the `release` profile is `3`.
-
-We can override any default setting by adding a different value for it in
-*Cargo.toml*. For example, if we want to use optimization level 1 in the
-development profile, we can add these two lines to our project’s *Cargo.toml*
-file:
-
-Filename: Cargo.toml
-
-```
-[profile.dev]
-opt-level = 1
-```
-
-This code overrides the default setting of `0`. Now when we run `cargo build`,
-Cargo will use the defaults for the `dev` profile plus our customization to
-`opt-level`. Because we set `opt-level` to `1`, Cargo will apply more
-optimizations than the default, but not as many as a release build.
-
-For the full list of configuration options and defaults for each profile, see
-Cargo’s documentation at *https://doc.rust-lang.org/cargo/*.
-
-## Publishing a Crate to Crates.io
-
-We’ve used packages from *https://crates.io/* as dependencies of our project,
-but you can also share your code for other people to use by publishing your own
-packages. The crate registry at *https://crates.io/* distributes the source
-code of your packages, so it primarily hosts code that is open source.
-
-Rust and Cargo have features that help make your published package easier for
-people to use and to find in the first place. We’ll talk about some of these
-features next, and then explain how to publish a package.
-
-### Making Useful Documentation Comments
-
-Accurately documenting your packages will help other users know how and when to
-use them, so it’s worth spending time writing documentation. In Chapter 3, we
-discussed how to comment Rust code using `//`. Rust also has a particular kind
-of comment for documentation, which is known conveniently as *documentation
-comments*, that will generate HTML documentation. The HTML displays the
-contents of documentation comments for public API items intended for
-programmers interested in knowing how to *use* your crate as opposed to how
-your crate is *implemented*.
-
-Documentation comments use `///` instead of `//` and support Markdown notation
-for formatting the text if you want to use it. You place documentation comments
-just before the item they’re documenting. Listing 14-1 shows documentation
-comments for an `add_one` function in a crate named `my_crate`:
-
-Filename: src/lib.rs
-
-```
-/// Adds one to the number given.
-///
-/// # Examples
-///
-/// ```
-/// let five = 5;
-///
-/// assert_eq!(6, my_crate::add_one(5));
-/// ```
-pub fn add_one(x: i32) -> i32 {
-    x + 1
-}
-```
-
-Listing 14-1: A documentation comment for a function
-
-Here, we give a description of what the `add_one` function does, start a
-section with the heading `Examples`, and then provide code that demonstrates
-how to use the `add_one` function. We can generate the HTML documentation from
-this documentation comment by running `cargo doc`. This command runs the
-`rustdoc` tool distributed with Rust and puts the generated HTML documentation
-in the *target/doc* directory.
-
-For convenience, running `cargo doc --open` will build the HTML for your
-current crate’s documentation (as well as the documentation for all of your
-crate’s dependencies) and open the result in a web browser. Navigate to the
-`add_one` function and you’ll see how the text in the documentation comments is
-rendered, as shown in Figure 14-1:
-
-Rendered HTML documentation for the `add_one` function of `my_crate`
-
-Figure 14-1: HTML documentation for the `add_one` function
-
-#### Commonly Used Sections
-
-We used the `# Examples` Markdown heading in Listing 14-1 to create a section
-in the HTML with the title “Examples.” Some other sections that crate authors
-commonly use in their documentation include:
-
-* **Panics**: The scenarios in which the function being documented could
-  `panic!`. Callers of the function who don’t want their programs to panic
-  should make sure they don’t call the function in these situations.
-* **Errors**: If the function returns a `Result`, describing the kinds of
-  errors that might occur and what conditions might cause those errors to be
-  returned can be helpful to callers so they can write code to handle the
-  different kinds of errors in different ways.
-* **Safety**: If the function is `unsafe` to call (we discuss unsafety in
-  Chapter 19), there should be a section explaining why the function is unsafe
-  and covering the invariants that the function expects callers to uphold.
-
-Most documentation comment sections don’t need all of these sections, but it’s
-a good list to check to remind you of the aspects of your code that people
-calling your code will be interested in knowing about.
-
-#### Documentation Comments as Tests
-
-Adding examples in code blocks in your documentation comments can clearly
-demonstrate how to use your library, and doing so has an additional bonus:
-running `cargo test` will run the code examples in your documentation as
-tests! Nothing is better than documentation with examples. But nothing is worse
-than examples that don’t work because the code has changed since the
-documentation was written. Run `cargo test` with the documentation for the
-`add_one` function from Listing 14-1; you should see a section in the test
-results like this:
-
-```
-   Doc-tests my_crate
-
-running 1 test
-test src/lib.rs - add_one (line 5) ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Now change either the function or the example so the `assert_eq!` in the
-example panics. Run `cargo test` again; you’ll see that the doc tests catch
-that the example and the code are out of sync from one another!
-
-#### Commenting Contained Items
-
-Another style of doc comment, `//!`, adds documentation to the item that
-contains the comments rather than adding documentation to the items following
-the comments. We typically use these doc comments inside the crate root file
-(*src/lib.rs* by convention) or inside a module to document the crate or the
-module as a whole.
-
-For example, if we want to add documentation that describes the purpose of the
-`my_crate` crate that contains the `add_one` function, we can add documentation
-comments that start with `//!` to the beginning of the *src/lib.rs* file, as
-shown in Listing 14-2:
-
-Filename: src/lib.rs
-
-```
-//! # My Crate
-//!
-//! `my_crate` is a collection of utilities to make performing certain
-//! calculations more convenient.
-
-/// Adds one to the number given.
-// --snip--
-```
-
-Listing 14-2: Documentation for the `my_crate` crate as a whole
-
-Notice there isn’t any code after the last line that begins with `//!`. Because
-we started the comments with `//!` instead of `///`, we’re documenting the item
-that contains this comment rather than an item that follows this comment. In
-this case, the item that contains this comment is the *src/lib.rs* file, which
-is the crate root. These comments describe the entire crate.
-
-When we run `cargo doc --open`, these comments will display on the front
-page of the documentation for `my_crate` above the list of public items in the
-crate, as shown in Figure 14-2:
-
-Rendered HTML documentation with a comment for the crate as a whole
-
-Figure 14-2: Rendered documentation for `my_crate` including the comment
-describing the crate as a whole
-
-Documentation comments within items are useful for describing crates and
-modules especially. Use them to explain the purpose of the container overall to
-help your crate users understand your organization.
-
-### Exporting a Convenient Public API with `pub use`
-
-In Chapter 7, we covered how to organize our code into modules using the `mod`
-keyword, how to make items public using the `pub` keyword, and how to bring
-items into a scope with the `use` keyword. However, the structure that makes
-sense to you while you’re developing a crate might not be very convenient for
-your users. You might want to organize your structs in a hierarchy containing
-multiple levels, but people who want to use a type you’ve defined deep in the
-hierarchy might have trouble finding out that those types exist. They might
-also be annoyed at having to enter `use`
-`my_crate::some_module::another_module::UsefulType;` rather than `use`
-`my_crate::UsefulType;`.
-
-The structure of your public API is a major consideration when publishing a
-crate. People who use your crate are less familiar with the structure than you
-are and might have difficulty finding the pieces they want to use if your crate
-has a large module hierarchy.
-
-The good news is that if the structure *isn’t* convenient for others to use
-from another library, you don’t have to rearrange your internal organization:
-instead, you can re-export items to make a public structure that’s different
-than your private structure by using `pub use`. Re-exporting takes a public
-item in one location and makes it public in another location, as if it was
-defined in the other location instead.
-
-For example, say we made a library named `art` for modeling artistic concepts.
-Within this library are two modules: a `kinds` module containing two enums
-named `PrimaryColor` and `SecondaryColor`, and a `utils` module containing a
-function named `mix`, as shown in Listing 14-3:
-
-Filename: src/lib.rs
-
-```
-//! # Art
-//!
-//! A library for modeling artistic concepts.
-
-pub mod kinds {
-    /// The primary colors according to the RYB color model.
-    pub enum PrimaryColor {
-        Red,
-        Yellow,
-        Blue,
-    }
-
-    /// The secondary colors according to the RYB color model.
-    pub enum SecondaryColor {
-        Orange,
-        Green,
-        Purple,
-    }
-}
-
-pub mod utils {
-    use kinds::*;
-
-    /// Combines two primary colors in equal amounts to create
-    /// a secondary color.
-    pub fn mix(c1: PrimaryColor, c2: PrimaryColor) -> SecondaryColor {
-        // --snip--
-    }
-}
-```
-
-Listing 14-3: An `art` library with items organized into `kinds` and `utils`
-modules
-
-Figure 14-3 shows what the front page of the documentation for this crate
-generated by `cargo doc` would look like:
-
-Rendered documentation for the `art` crate that lists the `kinds` and `utils` modules
-
-Figure 14-3: Front page of the documentation for `art` that lists the `kinds`
-and `utils` modules
-
-Note that the `PrimaryColor` and `SecondaryColor` types aren’t listed on the
-front page, nor is the `mix` function. We have to click `kinds` and `utils` to
-see them.
-
-Another crate that depends on this library would need `use` statements that
-import the items from `art`, including specifying the module structure that’s
-currently defined. Listing 14-4 shows an example of a crate that uses the
-`PrimaryColor` and `mix` items from the `art` crate:
-
-Filename: src/main.rs
-
-```
-extern crate art;
-
-use art::kinds::PrimaryColor;
-use art::utils::mix;
-
-fn main() {
-    let red = PrimaryColor::Red;
-    let yellow = PrimaryColor::Yellow;
-    mix(red, yellow);
-}
-```
-
-Listing 14-4: A crate using the `art` crate’s items with its internal structure
-exported
-
-The author of the code in Listing 14-4, which uses the `art` crate, had to
-figure out that `PrimaryColor` is in the `kinds` module and `mix` is in the
-`utils` module. The module structure of the `art` crate is more relevant to
-developers working on the `art` crate than developers using the `art` crate.
-The internal structure that organizes parts of the crate into the `kinds`
-module and the `utils` module doesn’t contain any useful information for
-someone trying to understand how to use the `art` crate. Instead, the `art`
-crate’s module structure causes confusion because developers have to figure out
-where to look, and the structure is inconvenient because developers must
-specify the module names in the `use` statements.
-
-To remove the internal organization from the public API, we can modify the
-`art` crate code in Listing 14-3 to add `pub use` statements to re-export the
-items at the top level, as shown in Listing 14-5:
-
-Filename: src/lib.rs
-
-```
-//! # Art
-//!
-//! A library for modeling artistic concepts.
-
-pub use kinds::PrimaryColor;
-pub use kinds::SecondaryColor;
-pub use utils::mix;
-
-pub mod kinds {
-    // --snip--
-}
-
-pub mod utils {
-    // --snip--
-}
-```
-
-Listing 14-5: Adding `pub use` statements to re-export items
-
-The API documentation that `cargo doc` generates for this crate will now list
-and link re-exports on the front page, as shown in Figure 14-4, which makes the
-`PrimaryColor` and `SecondaryColor` types and the `mix` function easier to find:
-
-Rendered documentation for the `art` crate with the re-exports on the front page
-
-Figure 14-4: The front page of the documentation for `art` that lists the
-re-exports
-
-The `art` crate users can still see and use the internal structure from Listing
-14-3 as demonstrated in Listing 14-4, or they can use the more convenient
-structure in Listing 14-5, as shown in Listing 14-6:
-
-Filename: src/main.rs
-
-```
-extern crate art;
-
-use art::PrimaryColor;
-use art::mix;
-
-fn main() {
-    // --snip--
-}
-```
-
-Listing 14-6: A program using the re-exported items from the `art` crate
-
-In cases where there are many nested modules, re-exporting the types at the top
-level with `pub use` can make a significant difference in the experience of
-people who use the crate.
-
-Creating a useful public API structure is more of an art than a science, and
-you can iterate to find the API that works best for your users. Choosing `pub
-use` gives you flexibility in how you structure your crate internally and
-decouples that internal structure with what you present to your users. Look at
-some of the code of crates you’ve installed to see if their internal structure
-differs from their public API.
-
-### Setting Up a Crates.io Account
-
-Before you can publish any crates, you need to create an account on
-*https://crates.io/* and get an API token. To do so, visit the home page at
-*https://crates.io/* and log in via a GitHub account: the GitHub account is
-currently a requirement, but the site might support other ways of creating an
-account in the future. Once you’re logged in, visit your account settings at
-*https://crates.io/me/* and retrieve your API key. Then run the `cargo`
-`login` command with your API key, like this:
-
-```
-$ cargo login abcdefghijklmnopqrstuvwxyz012345
-```
-
-This command will inform Cargo of your API token and store it locally in
-*~/.cargo/credentials*. Note that this token is a *secret*: do not share it
-with anyone else. If you do share it with anyone for any reason, you should
-revoke it and generate a new token on *https://crates.io/*.
-
-### Before Publishing a New Crate
-
-Now that you have an account, let’s say you have a crate you want to publish.
-Before publishing, you’ll need to add some metadata to your crate by adding it
-to the `[package]` section of the crate’s *Cargo.toml* file.
-
-Your crate will need a unique name. While you’re working on a crate locally,
-you can name a crate whatever you’d like. However, crate names on
-*https://crates.io/* are allocated on a first-come, first-served basis. Once
-a crate name is taken, no one else can publish a crate with that name. Search
-for the name you want to use on the site to find out if it has been used. If it
-hasn’t, edit the name in the *Cargo.toml* file under `[package]` to use the
-name for publishing, like so:
-
-Filename: Cargo.toml
-
-```
-[package]
-name = "guessing_game"
-```
-
-Even if you’ve chosen a unique name, when you run `cargo publish` to publish
-the crate at this point, you’ll get a warning and then an error:
-
-```
-$ cargo publish
-    Updating registry `https://github.com/rust-lang/crates.io-index`
-warning: manifest has no description, license, license-file, documentation,
-homepage or repository.
---snip--
-error: api errors: missing or empty metadata fields: description, license.
-```
-
-The reason is that you’re missing some crucial information: a description and
-license are required so people will know what your crate does and under what
-terms they can use it. To rectify this error, you need to include this
-information in the *Cargo.toml* file.
-
-Add a description that is just a sentence or two, because it will appear with
-your crate in search results. For the `license` field, you need to give a
-*license identifier value*. The Linux Foundation’s Software Package Data
-Exchange (SPDX) at *http://spdx.org/licenses/* lists the identifiers you can
-use for this value. For example, to specify that you’ve licensed your crate
-using the MIT License, add the `MIT` identifier:
-
-Filename: Cargo.toml
-
-```
-[package]
-name = "guessing_game"
-license = "MIT"
-```
-
-If you want to use a license that doesn’t appear in the SPDX, you need to place
-the text of that license in a file, include the file in your project, and then
-use `license-file` to specify the name of that file instead of using the
-`license` key.
-
-Guidance on which license is appropriate for your project is beyond the scope
-of this book. Many people in the Rust community license their projects in the
-same way as Rust by using a dual license of `MIT OR Apache-2.0`, which
-demonstrates that you can also specify multiple license identifiers separated
-by `OR` to have multiple licenses for your project.
-
-With a unique name, the version, the author details that `cargo new` added
-when you created the crate, your description, and a license added, the
-*Cargo.toml* file for a project that is ready to publish might look like this:
-
-Filename: Cargo.toml
-
-```
-[package]
-name = "guessing_game"
-version = "0.1.0"
-authors = ["Your Name "]
-description = "A fun game where you guess what number the computer has chosen."
-license = "MIT OR Apache-2.0"
-
-[dependencies]
-```
-
-Cargo’s documentation at *https://doc.rust-lang.org/cargo/* describes other
-metadata you can specify to ensure others can discover and use your crate more
-easily!
-
-### Publishing to Crates.io
-
-Now that you’ve created an account, saved your API token, chosen a name for
-your crate, and specified the required metadata, you’re ready to publish!
-Publishing a crate uploads a specific version to *https://crates.io/* for
-others to use.
-
-Be careful when publishing a crate because a publish is *permanent*. The
-version can never be overwritten, and the code cannot be deleted. One major
-goal of *https://crates.io/* is to act as a permanent archive of code so that
-builds of all projects that depend on crates from *https://crates.io/* will
-continue to work. Allowing version deletions would make fulfilling that goal
-impossible. However, there is no limit to the number of crate versions you can
-publish.
-
-Run the `cargo publish` command again. It should succeed now:
-
-```
-$ cargo publish
- Updating registry `https://github.com/rust-lang/crates.io-index`
-Packaging guessing_game v0.1.0 (file:///projects/guessing_game)
-Verifying guessing_game v0.1.0 (file:///projects/guessing_game)
-Compiling guessing_game v0.1.0
-(file:///projects/guessing_game/target/package/guessing_game-0.1.0)
- Finished dev [unoptimized + debuginfo] target(s) in 0.19 secs
-Uploading guessing_game v0.1.0 (file:///projects/guessing_game)
-```
-
-Congratulations! You’ve now shared your code with the Rust community, and
-anyone can easily add your crate as a dependency of their project.
-
-### Publishing a New Version of an Existing Crate
-
-When you’ve made changes to your crate and are ready to release a new version,
-you change the `version` value specified in your *Cargo.toml* file and
-republish. Use the Semantic Versioning rules at *http://semver.org/* to
-decide what an appropriate next version number is based on the kinds of changes
-you’ve made. Then run `cargo publish` to upload the new version.
-
-### Removing Versions from Crates.io with `cargo yank`
-
-Although you can’t remove previous versions of a crate, you can prevent any
-future projects from adding them as a new dependency. This is useful when a
-crate version is broken for one reason or another. In such situations, Cargo
-supports *yanking* a crate version.
-
-Yanking a version prevents new projects from starting to depend on that version
-while allowing all existing projects that depend on it to continue to download
-and depend on that version. Essentially, a yank means that all projects with a
-*Cargo.lock* will not break, and any future *Cargo.lock* files generated will
-not use the yanked version.
-
-To yank a version of a crate, run `cargo yank` and specify which version you
-want to yank:
-
-```
-$ cargo yank --vers 1.0.1
-```
-
-By adding `--undo` to the command, you can also undo a yank and allow projects
-to start depending on a version again:
-
-```
-$ cargo yank --vers 1.0.1 --undo
-```
-
-A yank *does not* delete any code. For example, the yank feature is not
-intended for deleting accidentally uploaded secrets. If that happens, you must
-reset those secrets immediately.
-
-## Cargo Workspaces
-
-In Chapter 12, we built a package that included a binary crate and a library
-crate. As your project develops, you might find that the library crate
-continues to get bigger and you want to split up your package further into
-multiple library crates. In this situation, Cargo offers a feature called
-*workspaces* that can help manage multiple related packages that are developed
-in tandem.
-
-A *workspace* is a set of packages that share the same *Cargo.lock* and output
-directory. Let’s make a project using a workspace—we’ll use trivial code so we
-can concentrate on the structure of the workspace. There are multiple ways to
-structure a workspace; we’re going to show one common way. We’ll have a
-workspace containing a binary and two libraries. The binary will provide the
-main functionality, and will depend on the two libraries. One library will
-provide an `add_one` function, and a second library an `add_two` function.
-These three crates will be part of the same workspace. We’ll start by creating
-a new directory for the workspace:
-
-```
-$ mkdir add
-$ cd add
-```
-
-Next, in the *add* directory, we create the *Cargo.toml* file that will
-configure the entire workspace. This file won’t have a `[package]` section or
-the metadata we’ve seen in other *Cargo.toml* files, but will instead start
-with a `[workspace]` section that will allow us to add members to the workspace
-by specifying the path to our binary crate; in this case, that path is *adder*:
-
-Filename: Cargo.toml
-
-```
-[workspace]
-
-members = [
-    "adder",
-]
-```
-
-Next, we’ll create the `adder` binary crate by running `cargo new` within the
-*add* directory:
-
-```
-$ cargo new --bin adder
-     Created binary (application) `adder` project
-```
-
-At this point, we can build the workspace by running `cargo build`. The files
-in your *add* directory should look like this:
-
-```
-├── Cargo.lock
-├── Cargo.toml
-├── adder
-│   ├── Cargo.toml
-│   └── src
-│       └── main.rs
-└── target
-```
-
-The workspace has one *target* directory at the top level for the compiled
-artifacts to be placed into; the `adder` crate doesn’t have its own *target*
-directory. Even if we were to run `cargo build` from inside the *adder*
-directory, the compiled artifacts would still end up in *add/target* rather
-than *add/adder/target*. Cargo structures the *target* directory in a workspace
-like this because the crates in a workspace are meant to depend on each other.
-If each crate had its own *target* directory, each crate would have to
-recompile each of the other crates in the workspace to have the artifacts in
-its own *target* directory. By sharing one *target* directory, the crates can
-avoid unnecessary rebuilding.
-
-### Creating the Second Crate in the Workspace
-
-Next, let’s create another member crate in the workspace and call it `add-one`.
-Change the top-level *Cargo.toml* to specify the *add-one* path in the
-`members` list:
-
-Filename: Cargo.toml
-
-```
-[workspace]
-
-members = [
-    "adder",
-    "add-one",
-]
-```
-
-Then generate a new library crate named `add-one`:
-
-```
-$ cargo new add-one
-     Created library `add-one` project
-```
-
-Your *add* directory should now have these directories and files:
-
-```
-├── Cargo.lock
-├── Cargo.toml
-├── add-one
-│   ├── Cargo.toml
-│   └── src
-│       └── lib.rs
-├── adder
-│   ├── Cargo.toml
-│   └── src
-│       └── main.rs
-└── target
-```
-
-In the *add-one/src/lib.rs* file, let’s add an `add_one` function:
-
-Filename: add-one/src/lib.rs
-
-```
-pub fn add_one(x: i32) -> i32 {
-    x + 1
-}
-```
-
-Now that we have a library crate in the workspace, we can have the binary crate
-`adder` depend on the library crate `add-one`. First, we’ll need to add a path
-dependency on `add-one` to *adder/Cargo.toml*.
-
-Filename: adder/Cargo.toml
-
-```
-[dependencies]
-
-add-one = { path = "../add-one" }
-```
-
-Cargo doesn’t assume that crates in a workspace will depend on each other, so
-we need to be explicit about the dependency relationships between the crates.
-
-Next, let’s use the `add_one` function from the `add-one` crate in the `adder`
-crate. Open the *adder/src/main.rs* file and add an `extern crate` line at
-the top to bring the new `add-one` library crate into scope. Then change the
-`main` function to call the `add_one` function, as in Listing 14-7:
-
-Filename: adder/src/main.rs
-
-```
-extern crate add_one;
-
-fn main() {
-    let num = 10;
-    println!("Hello, world! {} plus one is {}!", num, add_one::add_one(num));
-}
-```
-
-Listing 14-7: Using the `add-one` library crate from the `adder` crate
-
-Let’s build the workspace by running `cargo build` in the top-level *add*
-directory!
-
-```
-$ cargo build
-   Compiling add-one v0.1.0 (file:///projects/add/add-one)
-   Compiling adder v0.1.0 (file:///projects/add/adder)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.68 secs
-```
-
-To run the binary crate from the *add* directory, we need to specify which
-package in the workspace we want to use by using the `-p` argument and the
-package name with `cargo run`:
-
-```
-$ cargo run -p adder
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running `target/debug/adder`
-Hello, world! 10 plus one is 11!
-```
-
-This runs the code in *adder/src/main.rs*, which depends on the `add-one` crate.
-
-#### Depending on an External Crate in a Workspace
-
-Notice that the workspace has only one *Cargo.lock* file at the top level of
-the workspace rather than having a *Cargo.lock* in each crate’s directory. This
-ensures that all crates are using the same version of all dependencies. If we
-add the `rand` crate to the *adder/Cargo.toml* and *add-one/Cargo.toml*
-files, Cargo will resolve both of those to one version of `rand` and record
-that in the one *Cargo.lock*. Making all crates in the workspace use the same
-dependencies means the crates in the workspace will always be compatible with
-each other. Let’s add the `rand` crate to the `[dependencies]` section in the
-*add-one/Cargo.toml* file to be able to use the `rand` crate in the `add-one`
-crate:
-
-Filename: add-one/Cargo.toml
-
-```
-[dependencies]
-
-rand = "0.3.14"
-```
-
-We can now add `extern crate rand;` to the *add-one/src/lib.rs* file, and
-building the whole workspace by running `cargo build` in the *add* directory
-will bring in and compile the `rand` crate:
-
-```
-$ cargo build
-    Updating registry `https://github.com/rust-lang/crates.io-index`
- Downloading rand v0.3.14
-   --snip--
-   Compiling rand v0.3.14
-   Compiling add-one v0.1.0 (file:///projects/add/add-one)
-   Compiling adder v0.1.0 (file:///projects/add/adder)
-    Finished dev [unoptimized + debuginfo] target(s) in 10.18 secs
-```
-
-The top-level *Cargo.lock* now contains information about the dependency of
-`add-one` on `rand`. However, even though `rand` is used somewhere in the
-workspace, we can’t use it in other crates in the workspace unless we add
-`rand` to their *Cargo.toml* files as well. For example, if we add `extern
-crate rand;` to the *adder/src/main.rs* file for the `adder` crate, we’ll get
-an error:
-
-```
-$ cargo build
-   Compiling adder v0.1.0 (file:///projects/add/adder)
-error: use of unstable library feature 'rand': use `rand` from crates.io (see
-issue #27703)
- --> adder/src/main.rs:1:1
-  |
-1 | extern crate rand;
-```
-
-To fix this, edit the *Cargo.toml* file for the `adder` crate and indicate that
-`rand` is a dependency for that crate as well. Building the `adder` crate will
-add `rand` to the list of dependencies for `adder` in *Cargo.lock*, but no
-additional copies of `rand` will be downloaded. Cargo has ensured that any
-crate in the workspace using the `rand` crate will be using the same version.
-Using the same version of `rand` across the workspace saves space because we
-won’t have multiple copies and ensures that the crates in the workspace will be
-compatible with each other.
-
-#### Adding a Test to a Workspace
-
-For another enhancement, let’s add a test of the `add_one::add_one` function
-within the `add_one` crate:
-
-Filename: add-one/src/lib.rs
-
-```
-pub fn add_one(x: i32) -> i32 {
-    x + 1
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn it_works() {
-        assert_eq!(3, add_one(2));
-    }
-}
-```
-
-Now run `cargo test` in the top-level *add* directory:
-
-```
-$ cargo test
-   Compiling add-one v0.1.0 (file:///projects/add/add-one)
-   Compiling adder v0.1.0 (file:///projects/add/adder)
-    Finished dev [unoptimized + debuginfo] target(s) in 0.27 secs
-     Running target/debug/deps/add_one-f0253159197f7841
-
-running 1 test
-test tests::it_works ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-     Running target/debug/deps/adder-f88af9d2cc175a5e
-
-running 0 tests
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-   Doc-tests add-one
-
-running 0 tests
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-The first section of the output shows that the `it_works` test in the `add-one`
-crate passed. The next section shows that 0 tests were found in the `adder`
-crate, and then the last section shows 0 documentation tests were found in the
-`add-one` crate. Running `cargo test` in a workspace structured like this one
-will run the tests for all the crates in the workspace.
-
-We can also run tests for one particular crate in a workspace from the
-top-level directory by using the `-p` flag and specifying the name of the crate
-we want to test:
-
-```
-$ cargo test -p add-one
-    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
-     Running target/debug/deps/add_one-b3235fea9a156f74
-
-running 1 test
-test tests::it_works ... ok
-
-test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-
-   Doc-tests add-one
-
-running 0 tests
-
-test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-This output shows `cargo test` only ran the tests for the `add-one` crate and
-didn’t run the `adder` crate tests.
-
-If you publish the crates in the workspace to *https://crates.io/*, each crate
-in the workspace will need to be published separately. The `cargo publish`
-command does not have an `--all` flag or a `-p` flag, so you must change to
-each crate’s directory and run `cargo publish` on each crate in the workspace
-to publish them.
-
-For additional practice, add an `add-two` crate to this workspace in a similar
-way as the `add-one` crate!
-
-As your project grows, consider using a workspace: it’s easier to understand
-smaller, individual components than one big blob of code. Keeping the crates in
-a workspace can make coordination between them easier if they are often changed
-at the same time.
-
-## Installing Binaries from Crates.io with `cargo install`
-
-The `cargo install` command allows you to install and use binary crates
-locally. This isn’t intended to replace system packages; it’s meant to be a
-convenient way for Rust developers to install tools that others have shared on
-*https://crates.io/*. You can only install packages that have binary targets.
-A binary target is the runnable program that is created if the crate has a
-*src/main.rs* file or another file specified as a binary, as opposed to a
-library target that isn’t runnable on its own but is suitable for including
-within other programs. Usually, crates have information in the *README* file
-about whether a crate is a library, has a binary target, or both.
-
-All binaries installed with `cargo install` are stored in the installation
-root’s *bin* folder. If you installed Rust using *rustup.rs* and don’t have any
-custom configurations, this directory will be *$HOME/.cargo/bin*. Ensure that
-directory is in your `$PATH` to be able to run programs you’ve installed with
-`cargo install`.
-
-For example, in Chapter 12 we mentioned that there’s a Rust implementation of
-the `grep` tool called `ripgrep` for searching files. If we want to install
-`ripgrep`, we can run the following:
-
-```
-$ cargo install ripgrep
-Updating registry `https://github.com/rust-lang/crates.io-index`
- Downloading ripgrep v0.3.2
- --snip--
-   Compiling ripgrep v0.3.2
-    Finished release [optimized + debuginfo] target(s) in 97.91 secs
-  Installing ~/.cargo/bin/rg
-```
-
-The last line of the output shows the location and the name of the installed
-binary, which in the case of `ripgrep` is `rg`. As long as the installation
-directory is in your `$PATH`, as mentioned previously, you can then run `rg
---help` and start using a faster, rustier tool for searching files!
-
-## Extending Cargo with Custom Commands
-
-Cargo is designed so you can extend it with new subcommands without having to
-modify Cargo. If a binary in your `$PATH` is named `cargo-something`, you can
-run it as if it was a Cargo subcommand by running `cargo something`. Custom
-commands like this are also listed when you run `cargo --list`. Being able to
-use `cargo install` to install extensions and then run them just like the
-built-in Cargo tools is a super convenient benefit of Cargo’s design!
-
-## Summary
-
-Sharing code with Cargo and *https://crates.io/* is part of what makes the
-Rust ecosystem useful for many different tasks. Rust’s standard library is
-small and stable, but crates are easy to share, use, and improve on a timeline
-different from the language. Don’t be shy about sharing code that’s useful to
-you on *https://crates.io/*; it’s likely that it will be useful to someone
-else as well!
diff --git a/src/doc/book/second-edition/nostarch/chapter15.md b/src/doc/book/second-edition/nostarch/chapter15.md
deleted file mode 100644
index 05b0db9906..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter15.md
+++ /dev/null
@@ -1,1976 +0,0 @@
-
-[TOC]
-
-# Smart Pointers
-
-A *pointer* is a general concept for a variable that contains an address in
-memory. This address refers to, or “points at,” some other data. The most
-common kind of pointer in Rust is a reference, which you learned about in
-Chapter 4. References are indicated by the `&` symbol and borrow the value they
-point to. They don’t have any special capabilities other than referring to
-data. Also, they don’t have any overhead and are the kind of pointer we use
-most often.
-
-*Smart pointers*, on the other hand, are data structures that not only act like
-a pointer but also have additional metadata and capabilities. The concept of
-smart pointers isn’t unique to Rust: smart pointers originated in C++ and exist
-in other languages as well. In Rust, the different smart pointers defined in
-the standard library provide functionality beyond that provided by references.
-One example that we’ll explore in this chapter is the *reference counting*
-smart pointer type. This pointer enables you to have multiple owners of data by
-keeping track of the number of owners and, when no owners remain, cleaning up
-the data.
-
-In Rust, which uses the concept of ownership and borrowing, an additional
-difference between references and smart pointers is that references are
-pointers that only borrow data; in contrast, in many cases, smart pointers
-*own* the data they point to.
-
-We’ve already encountered a few smart pointers in this book, such as `String`
-and `Vec` in Chapter 8, although we didn’t call them smart pointers at the
-time. Both these types count as smart pointers because they own some memory and
-allow you to manipulate it. They also have metadata (such as their capacity)
-and extra capabilities or guarantees (such as with `String` ensuring its data
-will always be valid UTF-8).
-
-Smart pointers are usually implemented using structs. The characteristic that
-distinguishes a smart pointer from an ordinary struct is that smart pointers
-implement the `Deref` and `Drop` traits. The `Deref` trait allows an instance
-of the smart pointer struct to behave like a reference so you can write code
-that works with either references or smart pointers. The `Drop` trait allows
-you to customize the code that is run when an instance of the smart pointer
-goes out of scope. In this chapter, we’ll discuss both traits and demonstrate
-why they’re important to smart pointers.
-
-Given that the smart pointer pattern is a general design pattern used
-frequently in Rust, this chapter won’t cover every existing smart pointer. Many
-libraries have their own smart pointers, and you can even write your own. We’ll
-cover the most common smart pointers in the standard library:
-
-* `Box` for allocating values on the heap
-* `Rc`, a reference counting type that enables multiple ownership
-* `Ref` and `RefMut`, accessed through `RefCell`, a type that enforces
-  the borrowing rules at runtime instead of compile time
-
-In addition, we’ll cover the *interior mutability* pattern where an immutable
-type exposes an API for mutating an interior value. We’ll also discuss
-*reference cycles*: how they can leak memory and how to prevent them.
-
-Let’s dive in!
-
-## Using `Box` to Point to Data on the Heap with a Known Size
-
-The most straightforward smart pointer is a *box*, whose type is written
-`Box`. Boxes allow you to store data on the heap rather than the stack. What
-remains on the stack is the pointer to the heap data. Refer to Chapter 4 to
-review the difference between the stack and the heap.
-
-Boxes don’t have performance overhead, other than storing their data on the
-heap instead of on the stack. But they don’t have many extra capabilities
-either. You’ll use them most often in these situations:
-
-* When you have a type whose size can’t be known at compile time and you want
-  to use a value of that type in a context that requires an exact size
-* When you have a large amount of data and you want to transfer ownership but
-  ensure the data won’t be copied when you do so
-* When you want to own a value and you care only that it’s a type that
-  implements a particular trait rather than being of a specific type
-
-We’ll demonstrate the first situation in the “Enabling Recursive Types with
-Boxes” section. In the second case, transferring ownership of a large amount of
-data can take a long time because the data is copied around on the stack. To
-improve performance in this situation, we can store the large amount of data on
-the heap in a box. Then, only the small amount of pointer data is copied around
-on the stack, while the data it references stays in one place on the heap. The
-third case is known as a *trait object*, and Chapter 17 devotes an entire
-section, “Using Trait Objects That Allow for Values of Different Types,” just
-to that topic. So what you learn here you’ll apply again in Chapter 17!
-
-### Using a `Box` to Store Data on the Heap
-
-Before we discuss this use case for `Box`, we’ll cover the syntax and how to
-interact with values stored within a `Box`.
-
-Listing 15-1 shows how to use a box to store an `i32` value on the heap:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let b = Box::new(5);
-    println!("b = {}", b);
-}
-```
-
-Listing 15-1: Storing an `i32` value on the heap using a box
-
-We define the variable `b` to have the value of a `Box` that points to the
-value `5`, which is allocated on the heap. This program will print `b = 5`; in
-this case, we can access the data in the box similar to how we would if this
-data were on the stack. Just like any owned value, when a box goes out of
-scope, as `b` does at the end of `main`, it will be deallocated. The
-deallocation happens for the box (stored on the stack) and the data it points
-to (stored on the heap).
-
-Putting a single value on the heap isn’t very useful, so you won’t use boxes by
-themselves in this way very often. Having values like a single `i32` on the
-stack, where they’re stored by default, is more appropriate in the majority of
-situations. Let’s look at a case where boxes allow us to define types that we
-wouldn’t be allowed to if we didn’t have boxes.
-
-### Enabling Recursive Types with Boxes
-
-At compile time, Rust needs to know how much space a type takes up. One type
-whose size can’t be known at compile time is a *recursive type*, where a value
-can have as part of itself another value of the same type. Because this nesting
-of values could theoretically continue infinitely, Rust doesn’t know how much
-space a value of a recursive type needs. However, boxes have a known size, so
-by inserting a box in a recursive type definition, you can have recursive types.
-
-Let’s explore the *cons list*, which is a data type common in functional
-programming languages, as an example of a recursive type. The cons list type
-we’ll define is straightforward except for the recursion; therefore, the
-concepts in the example we’ll work with will be useful any time you get into
-more complex situations involving recursive types.
-
-#### More Information About the Cons List
-
-A *cons list* is a data structure that comes from the Lisp programming language
-and its dialects. In Lisp, the `cons` function (short for “construct function”)
-constructs a new pair from its two arguments, which usually are a single value
-and another pair. These pairs containing pairs form a list.
-
-The cons function concept has made its way into more general functional
-programming jargon: “to cons *x* onto *y*” informally means to construct a new
-container instance by putting the element *x* at the start of this new
-container, followed by the container *y*.
-
-Each item in a cons list contains two elements: the value of the current item
-and the next item. The last item in the list contains only a value called `Nil`
-without a next item. A cons list is produced by recursively calling the `cons`
-function. The canonical name to denote the base case of the recursion is `Nil`.
-Note that this is not the same as the “null” or “nil” concept in Chapter 6,
-which is an invalid or absent value.
-
-Although functional programming languages use cons lists frequently, the cons
-list isn’t a commonly used data structure in Rust. Most of the time when you
-have a list of items in Rust, `Vec` is a better choice to use. Other, more
-complex recursive data types *are* useful in various situations, but by
-starting with the cons list, we can explore how boxes let us define a recursive
-data type without much distraction.
-
-Listing 15-2 contains an enum definition for a cons list. Note that this code
-won’t compile yet because the `List` type doesn’t have a known size, which
-we’ll demonstrate.
-
-Filename: src/main.rs
-
-```
-enum List {
-    Cons(i32, List),
-    Nil,
-}
-```
-
-Listing 15-2: The first attempt at defining an enum to represent a cons list
-data structure of `i32` values
-
-> Note: We’re implementing a cons list that holds only `i32` values for the
-> purposes of this example. We could have implemented it using generics, as we
-> discussed in Chapter 10, to define a cons list type that could store values of
-> any type.
-
-Using the `List` type to store the list `1, 2, 3` would look like the code in
-Listing 15-3:
-
-Filename: src/main.rs
-
-```
-use List::{Cons, Nil};
-
-fn main() {
-    let list = Cons(1, Cons(2, Cons(3, Nil)));
-}
-```
-
-Listing 15-3: Using the `List` enum to store the list `1, 2, 3`
-
-The first `Cons` value holds `1` and another `List` value. This `List` value is
-another `Cons` value that holds `2` and another `List` value. This `List` value
-is one more `Cons` value that holds `3` and a `List` value, which is finally
-`Nil`, the non-recursive variant that signals the end of the list.
-
-If we try to compile the code in Listing 15-3, we get the error shown in
-Listing 15-4:
-
-```
-error[E0072]: recursive type `List` has infinite size
- --> src/main.rs:1:1
-  |
-1 | enum List {
-  | ^^^^^^^^^ recursive type has infinite size
-2 |     Cons(i32, List),
-  |               ----- recursive without indirection
-  |
-  = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to
-  make `List` representable
-```
-
-Listing 15-4: The error we get when attempting to define a recursive enum
-
-The error shows this type “has infinite size.” The reason is that we’ve defined
-`List` with a variant that is recursive: it holds another value of itself
-directly. As a result, Rust can’t figure out how much space it needs to store a
-`List` value. Let’s break down why we get this error a bit. First, let’s look
-at how Rust decides how much space it needs to store a value of a non-recursive
-type.
-
-#### Computing the Size of a Non-Recursive Type
-
-Recall the `Message` enum we defined in Listing 6-2 when we discussed enum
-definitions in Chapter 6:
-
-```
-enum Message {
-    Quit,
-    Move { x: i32, y: i32 },
-    Write(String),
-    ChangeColor(i32, i32, i32),
-}
-```
-
-To determine how much space to allocate for a `Message` value, Rust goes
-through each of the variants to see which variant needs the most space. Rust
-sees that `Message::Quit` doesn’t need any space, `Message::Move` needs enough
-space to store two `i32` values, and so forth. Because only one variant will be
-used, the most space a `Message` value will need is the space it would take to
-store the largest of its variants.
-
-Contrast this with what happens when Rust tries to determine how much space a
-recursive type like the `List` enum in Listing 15-2 needs. The compiler starts
-by looking at the `Cons` variant, which holds a value of type `i32` and a value
-of type `List`. Therefore, `Cons` needs an amount of space equal to the size of
-an `i32` plus the size of a `List`. To figure out how much memory the `List`
-type needs, the compiler looks at the variants, starting with the `Cons`
-variant. The `Cons` variant holds a value of type `i32` and a value of type
-`List`, and this process continues infinitely, as shown in Figure 15-1.
-
-An infinite Cons list
-
-Figure 15-1: An infinite `List` consisting of infinite `Cons` variants
-
-#### Using `Box` to Get a Recursive Type with a Known Size
-
-Rust can’t figure out how much space to allocate for recursively defined types,
-so the compiler gives the error in Listing 15-4. But the error does include
-this helpful suggestion:
-
-```
-  = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to
-  make `List` representable
-```
-
-In this suggestion, “indirection” means that instead of storing a value
-directly, we’ll change the data structure to store the value indirectly by
-storing a pointer to the value instead.
-
-Because a `Box` is a pointer, Rust always knows how much space a `Box`
-needs: a pointer’s size doesn’t change based on the amount of data it’s
-pointing to. This means we can put a `Box` inside the `Cons` variant instead
-of another `List` value directly. The `Box` will point to the next `List`
-value that will be on the heap rather than inside the `Cons` variant.
-Conceptually, we still have a list, created with lists “holding” other lists,
-but this implementation is now more like placing the items next to one another
-rather than inside one another.
-
-We can change the definition of the `List` enum in Listing 15-2 and the usage
-of the `List` in Listing 15-3 to the code in Listing 15-5, which will compile:
-
-Filename: src/main.rs
-
-```
-enum List {
-    Cons(i32, Box),
-    Nil,
-}
-
-use List::{Cons, Nil};
-
-fn main() {
-    let list = Cons(1,
-        Box::new(Cons(2,
-            Box::new(Cons(3,
-                Box::new(Nil))))));
-}
-```
-
-Listing 15-5: Definition of `List` that uses `Box` in order to have a known
-size
-
-The `Cons` variant will need the size of an `i32` plus the space to store the
-box’s pointer data. The `Nil` variant stores no values, so it needs less space
-than the `Cons` variant. We now know that any `List` value will take up the
-size of an `i32` plus the size of a box’s pointer data. By using a box, we’ve
-broken the infinite, recursive chain, so the compiler can figure out the size
-it needs to store a `List` value. Figure 15-2 shows what the `Cons` variant
-looks like now.
-
-A finite Cons list
-
-Figure 15-2: A `List` that is not infinitely sized because `Cons` holds a `Box`
-
-Boxes provide only the indirection and heap allocation; they don’t have any
-other special capabilities, like those we’ll see with the other smart pointer
-types. They also don’t have any performance overhead that these special
-capabilities incur, so they can be useful in cases like the cons list where the
-indirection is the only feature we need. We’ll look at more use cases for boxes
-in Chapter 17, too.
-
-The `Box` type is a smart pointer because it implements the `Deref` trait,
-which allows `Box` values to be treated like references. When a `Box`
-value goes out of scope, the heap data that the box is pointing to is cleaned
-up as well because of the `Drop` trait implementation. Let’s explore these two
-traits in more detail. These two traits will be even more important to the
-functionality provided by the other smart pointer types we’ll discuss in the
-rest of this chapter.
-
-## Treating Smart Pointers Like Regular References with the `Deref` Trait
-
-Implementing the `Deref` trait allows you to customize the behavior of the
-*dereference operator*, `*` (as opposed to the multiplication or glob
-operator). By implementing `Deref` in such a way that a smart pointer can be
-treated like a regular reference, you can write code that operates on
-references and use that code with smart pointers too.
-
-Let’s first look at how the dereference operator works with regular references.
-Then we’ll try to define a custom type that behaves like `Box`, and see why
-the dereference operator doesn’t work like a reference on our newly defined
-type. We’ll explore how implementing the `Deref` trait makes it possible for
-smart pointers to work in a similar way as references. Then we’ll look at
-Rust’s *deref coercion* feature and how it lets us work with either references
-or smart pointers.
-
-### Following the Pointer to the Value with the Dereference Operator
-
-A regular reference is a type of pointer, and one way to think of a pointer is
-as an arrow to a value stored somewhere else. In Listing 15-6, we create a
-reference to an `i32` value and then use the dereference operator to follow the
-reference to the data:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 5;
-    let y = &x;
-
-    assert_eq!(5, x);
-    assert_eq!(5, *y);
-}
-```
-
-Listing 15-6: Using the dereference operator to follow a reference to an `i32`
-value
-
-The variable `x` holds an `i32` value, `5`. We set `y` equal to a reference to
-`x`. We can assert that `x` is equal to `5`. However, if we want to make an
-assertion about the value in `y`, we have to use `*y` to follow the reference
-to the value it’s pointing to (hence *dereference*). Once we dereference `y`,
-we have access to the integer value `y` is pointing to that we can compare with
-`5`.
-
-If we tried to write `assert_eq!(5, y);` instead, we would get this compilation
-error:
-
-```
-error[E0277]: the trait bound `{integer}: std::cmp::PartialEq<&{integer}>` is
-not satisfied
- --> src/main.rs:6:5
-  |
-6 |     assert_eq!(5, y);
-  |     ^^^^^^^^^^^^^^^^^ can't compare `{integer}` with `&{integer}`
-  |
-  = help: the trait `std::cmp::PartialEq<&{integer}>` is not implemented for
-  `{integer}`
-```
-
-Comparing a number and a reference to a number isn’t allowed because they’re
-different types. We must use the dereference operator to follow the reference
-to the value it’s pointing to.
-
-### Using `Box` Like a Reference
-
-We can rewrite the code in Listing 15-6 to use a `Box` instead of a
-reference; the dereference operator will work as shown in Listing 15-7:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 5;
-    let y = Box::new(x);
-
-    assert_eq!(5, x);
-    assert_eq!(5, *y);
-}
-```
-
-Listing 15-7: Using the dereference operator on a `Box`
-
-The only difference between Listing 15-7 and Listing 15-6 is that here we set
-`y` to be an instance of a box pointing to the value in `x` rather than a
-reference pointing to the value of `x`. In the last assertion, we can use the
-dereference operator to follow the box’s pointer in the same way that we did
-when `y` was a reference. Next, we’ll explore what is special about `Box`
-that enables us to use the dereference operator by defining our own box type.
-
-### Defining Our Own Smart Pointer
-
-Let’s build a smart pointer similar to the `Box` type provided by the
-standard library to experience how smart pointers behave differently than
-references by default. Then we’ll look at how to add the ability to use the
-dereference operator.
-
-The `Box` type is ultimately defined as a tuple struct with one element, so
-Listing 15-8 defines a `MyBox` type in the same way. We’ll also define a
-`new` function to match the `new` function defined on `Box`.
-
-Filename: src/main.rs
-
-```
-struct MyBox(T);
-
-impl MyBox {
-    fn new(x: T) -> MyBox {
-        MyBox(x)
-    }
-}
-```
-
-Listing 15-8: Defining a `MyBox` type
-
-We define a struct named `MyBox` and declare a generic parameter `T`, because
-we want our type to hold values of any type. The `MyBox` type is a tuple struct
-with one element of type `T`. The `MyBox::new` function takes one parameter of
-type `T` and returns a `MyBox` instance that holds the value passed in.
-
-Let’s try adding the `main` function in Listing 15-7 to Listing 15-8 and
-changing it to use the `MyBox` type we’ve defined instead of `Box`. The
-code in Listing 15-9 won’t compile because Rust doesn’t know how to dereference
-`MyBox`.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let x = 5;
-    let y = MyBox::new(x);
-
-    assert_eq!(5, x);
-    assert_eq!(5, *y);
-}
-```
-
-Listing 15-9: Attempting to use `MyBox` in the same way we used references
-and `Box`
-
-Here’s the resulting compilation error:
-
-```
-error[E0614]: type `MyBox<{integer}>` cannot be dereferenced
-  --> src/main.rs:14:19
-   |
-14 |     assert_eq!(5, *y);
-   |                   ^^
-```
-
-Our `MyBox` type can’t be dereferenced because we haven’t implemented that
-ability on our type. To enable dereferencing with the `*` operator, we
-implement the `Deref` trait.
-
-### Treating a Type Like a Reference by Implementing the `Deref` Trait
-
-As discussed in Chapter 10, to implement a trait, we need to provide
-implementations for the trait’s required methods. The `Deref` trait, provided
-by the standard library, requires us to implement one method named `deref` that
-borrows `self` and returns a reference to the inner data. Listing 15-10
-contains an implementation of `Deref` to add to the definition of `MyBox`:
-
-Filename: src/main.rs
-
-```
-use std::ops::Deref;
-
-impl Deref for MyBox {
-    type Target = T;
-
-    fn deref(&self) -> &T {
-        &self.0
-    }
-}
-```
-
-Listing 15-10: Implementing `Deref` on `MyBox`
-
-The `type Target = T;` syntax defines an associated type for the `Deref` trait
-to use. Associated types are a slightly different way of declaring a generic
-parameter, but you don’t need to worry about them for now; we’ll cover them in
-more detail in Chapter 19.
-
-We fill in the body of the `deref` method with `&self.0` so `deref` returns a
-reference to the value we want to access with the `*` operator. The `main`
-function in Listing 15-9 that calls `*` on the `MyBox` value now compiles,
-and the assertions pass!
-
-Without the `Deref` trait, the compiler can only dereference `&` references.
-The `deref` method gives the compiler the ability to take a value of any type
-that implements `Deref` and call the `deref` method to get a `&` reference that
-it knows how to dereference.
-
-When we entered `*y` in Listing 15-9, behind the scenes Rust actually ran this
-code:
-
-```
-*(y.deref())
-```
-
-Rust substitutes the `*` operator with a call to the `deref` method and then a
-plain dereference so we don’t have to think about whether or not we need to
-call the `deref` method. This Rust feature lets us write code that functions
-identically whether we have a regular reference or a type that implements
-`Deref`.
-
-The reason the `deref` method returns a reference to a value and that the plain
-dereference outside the parentheses in `*(y.deref())` is still necessary is the
-ownership system. If the `deref` method returned the value directly instead of
-a reference to the value, the value would be moved out of `self`. We don’t want
-to take ownership of the inner value inside `MyBox` in this case or in most
-cases where we use the dereference operator.
-
-Note that the `*` operator is replaced with a call to the `deref` method and
-then a call to the `*` operator just once, each time we use a `*` in our code.
-Because the substitution of the `*` operator does not recurse infinitely, we
-end up with data of type `i32`, which matches the `5` in `assert_eq!` in
-Listing 15-9.
-
-### Implicit Deref Coercions with Functions and Methods
-
-*Deref coercion* is a convenience that Rust performs on arguments to functions
-and methods. Deref coercion converts a reference to a type that implements
-`Deref` into a reference to a type that `Deref` can convert the original type
-into. Deref coercion happens automatically when we pass a reference to a
-particular type’s value as an argument to a function or method that doesn’t
-match the parameter type in the function or method definition. A sequence of
-calls to the `deref` method converts the type we provided into the type the
-parameter needs.
-
-Deref coercion was added to Rust so that programmers writing function and
-method calls don’t need to add as many explicit references and dereferences
-with `&` and `*`. The deref coercion feature also lets us write more code that
-can work for either references or smart pointers.
-
-To see deref coercion in action, let’s use the `MyBox` type we defined in
-Listing 15-8 as well as the implementation of `Deref` that we added in Listing
-15-10. Listing 15-11 shows the definition of a function that has a string slice
-parameter:
-
-Filename: src/main.rs
-
-```
-fn hello(name: &str) {
-    println!("Hello, {}!", name);
-}
-```
-
-Listing 15-11: A `hello` function that has the parameter `name` of type `&str`
-
-We can call the `hello` function with a string slice as an argument, such as
-`hello("Rust");` for example. Deref coercion makes it possible to call `hello`
-with a reference to a value of type `MyBox`, as shown in Listing 15-12:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let m = MyBox::new(String::from("Rust"));
-    hello(&m);
-}
-```
-
-Listing 15-12: Calling `hello` with a reference to a `MyBox` value,
-which works because of deref coercion
-
-Here we’re calling the `hello` function with the argument `&m`, which is a
-reference to a `MyBox` value. Because we implemented the `Deref` trait
-on `MyBox` in Listing 15-10, Rust can turn `&MyBox` into `&String`
-by calling `deref`. The standard library provides an implementation of `Deref`
-on `String` that returns a string slice, and this is in the API documentation
-for `Deref`. Rust calls `deref` again to turn the `&String` into `&str`, which
-matches the `hello` function’s definition.
-
-If Rust didn’t implement deref coercion, we would have to write the code in
-Listing 15-13 instead of the code in Listing 15-12 to call `hello` with a value
-of type `&MyBox`.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let m = MyBox::new(String::from("Rust"));
-    hello(&(*m)[..]);
-}
-```
-
-Listing 15-13: The code we would have to write if Rust didn’t have deref
-coercion
-
-The `(*m)` dereferences the `MyBox` into a `String`. Then the `&` and
-`[..]` take a string slice of the `String` that is equal to the whole string to
-match the signature of `hello`. The code without deref coercions is harder to
-read, write, and understand with all of these symbols involved. Deref coercion
-allows Rust to handle these conversions for us automatically.
-
-When the `Deref` trait is defined for the types involved, Rust will analyze the
-types and use `Deref::deref` as many times as necessary to get a reference to
-match the parameter’s type. The number of times that `Deref::deref` needs to be
-inserted is resolved at compile time, so there is no runtime penalty for taking
-advantage of deref coercion!
-
-### How Deref Coercion Interacts with Mutability
-
-Similar to how you use the `Deref` trait to override the `*` operator on
-immutable references, you can use the `DerefMut` trait to override the `*`
-operator on mutable references.
-
-Rust does deref coercion when it finds types and trait implementations in three
-cases:
-
-* From `&T` to `&U` when `T: Deref`
-* From `&mut T` to `&mut U` when `T: DerefMut`
-* From `&mut T` to `&U` when `T: Deref`
-
-The first two cases are the same except for mutability. The first case states
-that if you have a `&T`, and `T` implements `Deref` to some type `U`, you can
-get a `&U` transparently. The second case states that the same deref coercion
-happens for mutable references.
-
-The third case is trickier: Rust will also coerce a mutable reference to an
-immutable one. But the reverse is *not* possible: immutable references will
-never coerce to mutable references. Because of the borrowing rules, if you have
-a mutable reference, that mutable reference must be the only reference to that
-data (otherwise, the program wouldn’t compile). Converting one mutable
-reference to one immutable reference will never break the borrowing rules.
-Converting an immutable reference to a mutable reference would require that
-there is only one immutable reference to that data, and the borrowing rules
-don’t guarantee that. Therefore, Rust can’t make the assumption that converting
-an immutable reference to a mutable reference is possible.
-
-## Running Code on Cleanup with the `Drop` Trait
-
-The second trait important to the smart pointer pattern is `Drop`, which lets
-you customize what happens when a value is about to go out of scope. You can
-provide an implementation for the `Drop` trait on any type, and the code you
-specify can be used to release resources like files or network connections.
-We’re introducing `Drop` in the context of smart pointers because the
-functionality of the `Drop` trait is almost always used when implementing a
-smart pointer. For example, `Box` customizes `Drop` to deallocate the space
-on the heap that the box points to.
-
-In some languages, the programmer must call code to free memory or resources
-every time they finish using an instance of a smart pointer. If they forget,
-the system might become overloaded and crash. In Rust, you can specify that a
-particular bit of code be run whenever a value goes out of scope, and the
-compiler will insert this code automatically. As a result, you don’t need to be
-careful about placing cleanup code everywhere in a program that an instance of
-a particular type is finished with—you still won’t leak resources!
-
-Specify the code to run when a value goes out of scope by implementing the
-`Drop` trait. The `Drop` trait requires you to implement one method named
-`drop` that takes a mutable reference to `self`. To see when Rust calls `drop`,
-let’s implement `drop` with `println!` statements for now.
-
-Listing 15-14 shows a `CustomSmartPointer` struct whose only custom
-functionality is that it will print `Dropping CustomSmartPointer!` when the
-instance goes out of scope. This example demonstrates when Rust runs the `drop`
-function.
-
-Filename: src/main.rs
-
-```
-struct CustomSmartPointer {
-    data: String,
-}
-
-impl Drop for CustomSmartPointer {
-    fn drop(&mut self) {
-        println!("Dropping CustomSmartPointer with data `{}`!", self.data);
-    }
-}
-
-fn main() {
-    let c = CustomSmartPointer { data: String::from("my stuff") };
-    let d = CustomSmartPointer { data: String::from("other stuff") };
-    println!("CustomSmartPointers created.");
-}
-```
-
-Listing 15-14: A `CustomSmartPointer` struct that implements the `Drop` trait
-where we would put our cleanup code
-
-The `Drop` trait is included in the prelude, so we don’t need to import it. We
-implement the `Drop` trait on `CustomSmartPointer` and provide an
-implementation for the `drop` method that calls `println!`. The body of the
-`drop` function is where you would place any logic that you wanted to run when
-an instance of your type goes out of scope. We’re printing some text here to
-demonstrate when Rust will call `drop`.
-
-In `main`, we create two instances of `CustomSmartPointer` and then print
-`CustomSmartPointers created.`. At the end of `main`, our instances of
-`CustomSmartPointer` will go out of scope, and Rust will call the code we put
-in the `drop` method, printing our final message. Note that we didn’t need to
-call the `drop` method explicitly.
-
-When we run this program, we’ll see the following output:
-
-```
-CustomSmartPointers created.
-Dropping CustomSmartPointer with data `other stuff`!
-Dropping CustomSmartPointer with data `my stuff`!
-```
-
-Rust automatically called `drop` for us when our instances went out of scope,
-calling the code we specified. Variables are dropped in the reverse order of
-their creation, so `d` was dropped before `c`. This example gives you a visual
-guide to how the `drop` method works; usually you would specify the cleanup
-code that your type needs to run rather than a print message.
-
-### Dropping a Value Early with `std::mem::drop`
-
-Unfortunately, it’s not straightforward to disable the automatic `drop`
-functionality. Disabling `drop` isn’t usually necessary; the whole point of the
-`Drop` trait is that it’s taken care of automatically. Occasionally, however,
-you might want to clean up a value early. One example is when using smart
-pointers that manage locks: you might want to force the `drop` method that
-releases the lock to run so other code in the same scope can acquire the lock.
-Rust doesn’t let you call the `Drop` trait’s `drop` method manually; instead
-you have to call the `std::mem::drop` function provided by the standard library
-if you want to force a value to be dropped before the end of its scope.
-
-If we try to call the `Drop` trait’s `drop` method manually by modifying the
-`main` function from Listing 15-14, as shown in Listing 15-15, we’ll get a
-compiler error:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let c = CustomSmartPointer { data: String::from("some data") };
-    println!("CustomSmartPointer created.");
-    c.drop();
-    println!("CustomSmartPointer dropped before the end of main.");
-}
-```
-
-Listing 15-15: Attempting to call the `drop` method from the `Drop` trait
-manually to clean up early
-
-When we try to compile this code, we’ll get this error:
-
-```
-error[E0040]: explicit use of destructor method
-  --> src/main.rs:14:7
-   |
-14 |     c.drop();
-   |       ^^^^ explicit destructor calls not allowed
-```
-
-This error message states that we’re not allowed to explicitly call `drop`. The
-error message uses the term *destructor*, which is the general programming term
-for a function that cleans up an instance. A *destructor* is analogous to a
-*constructor*, which creates an instance. The `drop` function in Rust is one
-particular destructor.
-
-Rust doesn’t let us call `drop` explicitly because Rust would still
-automatically call `drop` on the value at the end of `main`. This would be a
-*double free* error because Rust would be trying to clean up the same value
-twice.
-
-We can’t disable the automatic insertion of `drop` when a value goes out of
-scope, and we can’t call the `drop` method explicitly. So, if we need to force
-a value to be cleaned up early, we can use the `std::mem::drop` function.
-
-The `std::mem::drop` function is different than the `drop` method in the `Drop`
-trait. We call it by passing the value we want to force to be dropped early as
-an argument. The function is in the prelude, so we can modify `main` in Listing
-15-15 to call the `drop` function, as shown in Listing 15-16:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let c = CustomSmartPointer { data: String::from("some data") };
-    println!("CustomSmartPointer created.");
-    drop(c);
-    println!("CustomSmartPointer dropped before the end of main.");
-}
-```
-
-Listing 15-16: Calling `std::mem::drop` to explicitly drop a value before it
-goes out of scope
-
-Running this code will print the following:
-
-```
-CustomSmartPointer created.
-Dropping CustomSmartPointer with data `some data`!
-CustomSmartPointer dropped before the end of main.
-```
-
-The text ```Dropping CustomSmartPointer with data `some data`!``` is printed
-between the `CustomSmartPointer created.` and `CustomSmartPointer dropped
-before the end of main.` text, showing that the `drop` method code is called to
-drop `c` at that point.
-
-You can use code specified in a `Drop` trait implementation in many ways to
-make cleanup convenient and safe: for instance, you could use it to create your
-own memory allocator! With the `Drop` trait and Rust’s ownership system, you
-don’t have to remember to clean up because Rust does it automatically.
-
-You also don’t have to worry about problems resulting from accidentally
-cleaning up values still in use: the ownership system that makes sure
-references are always valid also ensures that `drop` gets called only once when
-the value is no longer being used.
-
-Now that we’ve examined `Box` and some of the characteristics of smart
-pointers, let’s look at a few other smart pointers defined in the standard
-library.
-
-## `Rc`, the Reference Counted Smart Pointer
-
-In the majority of cases, ownership is clear: you know exactly which variable
-owns a given value. However, there are cases when a single value might have
-multiple owners. For example, in graph data structures, multiple edges might
-point to the same node, and that node is conceptually owned by all of the edges
-that point to it. A node shouldn’t be cleaned up unless it doesn’t have any
-edges pointing to it.
-
-To enable multiple ownership, Rust has a type called `Rc`, which is an
-abbreviation for *reference counting*. The `Rc` type keeps track of the
-number of references to a value which determines whether or not a value is
-still in use. If there are zero references to a value, the value can be cleaned
-up without any references becoming invalid.
-
-Imagine `Rc` as a TV in a family room. When one person enters to watch TV,
-they turn it on. Others can come into the room and watch the TV. When the last
-person leaves the room, they turn off the TV because it’s no longer being used.
-If someone turns off the TV while others are still watching it, there would be
-uproar from the remaining TV watchers!
-
-We use the `Rc` type when we want to allocate some data on the heap for
-multiple parts of our program to read and we can’t determine at compile time
-which part will finish using the data last. If we knew which part would finish
-last, we could just make that part the data’s owner, and the normal ownership
-rules enforced at compile time would take effect.
-
-Note that `Rc` is only for use in single-threaded scenarios. When we discuss
-concurrency in Chapter 16, we’ll cover how to do reference counting in
-multithreaded programs.
-
-### Using `Rc` to Share Data
-
-Let’s return to our cons list example in Listing 15-5. Recall that we defined
-it using `Box`. This time, we’ll create two lists that both share ownership
-of a third list. Conceptually, this looks similar to Figure 15-3:
-
-Two lists that share ownership of a third list
-
-Figure 15-3: Two lists, `b` and `c`, sharing ownership of a third list, `a`
-
-We’ll create list `a` that contains 5 and then 10. Then we’ll make two more
-lists: `b` that starts with 3 and `c` that starts with 4. Both `b` and `c`
-lists will then continue on to the first `a` list containing 5 and 10. In other
-words, both lists will share the first list containing 5 and 10.
-
-Trying to implement this scenario using our definition of `List` with `Box`
-won’t work, as shown in Listing 15-17:
-
-Filename: src/main.rs
-
-```
-enum List {
-    Cons(i32, Box),
-    Nil,
-}
-
-use List::{Cons, Nil};
-
-fn main() {
-    let a = Cons(5,
-        Box::new(Cons(10,
-            Box::new(Nil))));
-    let b = Cons(3, Box::new(a));
-    let c = Cons(4, Box::new(a));
-}
-```
-
-Listing 15-17: Demonstrating we’re not allowed to have two lists using `Box`
-that try to share ownership of a third list
-
-When we compile this code, we get this error:
-
-```
-error[E0382]: use of moved value: `a`
-  --> src/main.rs:13:30
-   |
-12 |     let b = Cons(3, Box::new(a));
-   |                              - value moved here
-13 |     let c = Cons(4, Box::new(a));
-   |                              ^ value used here after move
-   |
-   = note: move occurs because `a` has type `List`, which does not implement
-   the `Copy` trait
-```
-
-The `Cons` variants own the data they hold, so when we create the `b` list, `a`
-is moved into `b` and `b` owns `a`. Then, when we try to use `a` again when
-creating `c`, we’re not allowed to because `a` has been moved.
-
-We could change the definition of `Cons` to hold references instead, but then
-we would have to specify lifetime parameters. By specifying lifetime
-parameters, we would be specifying that every element in the list will live at
-least as long as the entire list. The borrow checker wouldn’t let us compile
-`let a = Cons(10, &Nil);` for example, because the temporary `Nil` value would
-be dropped before `a` could take a reference to it.
-
-Instead, we’ll change our definition of `List` to use `Rc` in place of
-`Box`, as shown in Listing 15-18. Each `Cons` variant will now hold a value
-and an `Rc` pointing to a `List`. When we create `b`, instead of taking
-ownership of `a`, we’ll clone the `Rc` that `a` is holding, thereby
-increasing the number of references from one to two and letting `a` and `b`
-share ownership of the data in that `Rc`. We’ll also clone `a` when
-creating `c`, increasing the number of references from two to three. Every time
-we call `Rc::clone`, the reference count to the data within the `Rc` will
-increase, and the data won’t be cleaned up unless there are zero references to
-it.
-
-Filename: src/main.rs
-
-```
-enum List {
-    Cons(i32, Rc),
-    Nil,
-}
-
-use List::{Cons, Nil};
-use std::rc::Rc;
-
-fn main() {
-    let a = Rc::new(Cons(5, Rc::new(Cons(10, Rc::new(Nil)))));
-    let b = Cons(3, Rc::clone(&a));
-    let c = Cons(4, Rc::clone(&a));
-}
-```
-
-Listing 15-18: A definition of `List` that uses `Rc`
-
-We need to add a `use` statement to bring `Rc` into scope because it’s not
-in the prelude. In `main`, we create the list holding 5 and 10 and store it in
-a new `Rc` in `a`. Then when we create `b` and `c`, we call the
-`Rc::clone` function and pass a reference to the `Rc` in `a` as an
-argument.
-
-We could have called `a.clone()` rather than `Rc::clone(&a)`, but Rust’s
-convention is to use `Rc::clone` in this case. The implementation of
-`Rc::clone` doesn’t make a deep copy of all the data like most types’
-implementations of `clone` do. The call to `Rc::clone` only increments the
-reference count, which doesn’t take much time. Deep copies of data can take a
-lot of time. By using `Rc::clone` for reference counting, we can visually
-distinguish between the deep-copy kinds of clones and the kinds of clones that
-increase the reference count. When looking for performance problems in the
-code, we only need to consider the deep-copy clones and can disregard calls to
-`Rc::clone`.
-
-### Cloning an `Rc` Increases the Reference Count
-
-Let’s change our working example in Listing 15-18 so we can see the reference
-counts changing as we create and drop references to the `Rc` in `a`.
-
-In Listing 15-19, we’ll change `main` so it has an inner scope around list `c`;
-then we can see how the reference count changes when `c` goes out of scope.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let a = Rc::new(Cons(5, Rc::new(Cons(10, Rc::new(Nil)))));
-    println!("count after creating a = {}", Rc::strong_count(&a));
-    let b = Cons(3, Rc::clone(&a));
-    println!("count after creating b = {}", Rc::strong_count(&a));
-    {
-        let c = Cons(4, Rc::clone(&a));
-        println!("count after creating c = {}", Rc::strong_count(&a));
-    }
-    println!("count after c goes out of scope = {}", Rc::strong_count(&a));
-}
-```
-
-Listing 15-19: Printing the reference count
-
-At each point in the program where the reference count changes, we print the
-reference count, which we can get by calling the `Rc::strong_count` function.
-This function is named `strong_count` rather than `count` because the `Rc`
-type also has a `weak_count`; we’ll see what `weak_count` is used for in the
-“Preventing Reference Cycles” section.
-
-This code prints the following:
-
-```
-count after creating a = 1
-count after creating b = 2
-count after creating c = 3
-count after c goes out of scope = 2
-```
-
-We can see that the `Rc` in `a` has an initial reference count of 1; then
-each time we call `clone`, the count goes up by 1. When `c` goes out of scope,
-the count goes down by 1. We don’t have to call a function to decrease the
-reference count like we have to call `Rc::clone` to increase the reference
-count: the implementation of the `Drop` trait decreases the reference count
-automatically when an `Rc` value goes out of scope.
-
-What we can’t see in this example is that when `b` and then `a` go out of scope
-at the end of `main`, the count is then 0, and the `Rc` is cleaned up
-completely at that point. Using `Rc` allows a single value to have
-multiple owners, and the count ensures that the value remains valid as long as
-any of the owners still exist.
-
-Via immutable references, `Rc` allows you to share data between multiple
-parts of your program for reading only. If `Rc` allowed you to have multiple
-mutable references too, you might violate one of the borrowing rules discussed
-in Chapter 4: multiple mutable borrows to the same place can cause data races
-and inconsistencies. But being able to mutate data is very useful! In the next
-section, we’ll discuss the interior mutability pattern and the `RefCell`
-type that you can use in conjunction with an `Rc` to work with this
-immutability restriction.
-
-## `RefCell` and the Interior Mutability Pattern
-
-*Interior mutability* is a design pattern in Rust that allows you to mutate
-data even when there are immutable references to that data; normally, this
-action is disallowed by the borrowing rules. To mutate data, the pattern uses
-`unsafe` code inside a data structure to bend Rust’s usual rules that govern
-mutation and borrowing. We haven’t yet covered unsafe code; we will in Chapter
-19. We can use types that use the interior mutability pattern when we can
-ensure that the borrowing rules will be followed at runtime, even though the
-compiler can’t guarantee that. The `unsafe` code involved is then wrapped in a
-safe API, and the outer type is still immutable.
-
-Let’s explore this concept by looking at the `RefCell` type that follows the
-interior mutability pattern.
-
-### Enforcing Borrowing Rules at Runtime with `RefCell`
-
-Unlike `Rc`, the `RefCell` type represents single ownership over the data
-it holds. So, what makes `RefCell` different from a type like `Box`?
-Recall the borrowing rules you learned in Chapter 4:
-
-* At any given time, you can have *either* (but not both of) one mutable
-  reference or any number of immutable references.
-* References must always be valid.
-
-With references and `Box`, the borrowing rules’ invariants are enforced at
-compile time. With `RefCell`, these invariants are enforced *at runtime*.
-With references, if you break these rules, you’ll get a compiler error. With
-`RefCell`, if you break these rules, your program will panic and exit.
-
-The advantages of checking the borrowing rules at compile time are that errors
-will be caught sooner in the development process, and there is no impact on
-runtime performance because all the analysis is completed beforehand. For those
-reasons, checking the borrowing rules at compile time is the best choice in the
-majority of cases, which is why this is Rust’s default.
-
-The advantage of checking the borrowing rules at runtime instead is that
-certain memory-safe scenarios are then allowed, whereas they are disallowed by
-the compile-time checks. Static analysis, like the Rust compiler, is inherently
-conservative. Some properties of code are impossible to detect by analyzing the
-code: the most famous example is the Halting Problem, which is beyond the scope
-of this book but is an interesting topic to research.
-
-Because some analysis is impossible, if the Rust compiler can’t be sure the
-code complies with the ownership rules, it might reject a correct program; in
-this way, it’s conservative. If Rust accepted an incorrect program, users
-wouldn’t be able to trust in the guarantees Rust makes. However, if Rust
-rejects a correct program, the programmer will be inconvenienced, but nothing
-catastrophic can occur. The `RefCell` type is useful when you’re sure your
-code follows the borrowing rules but the compiler is unable to understand and
-guarantee that.
-
-Similar to `Rc`, `RefCell` is only for use in single-threaded scenarios
-and will give you a compile-time error if you try using it in a multithreaded
-context. We’ll talk about how to get the functionality of `RefCell` in a
-multithreaded program in Chapter 16.
-
-Here is a recap of the reasons to choose `Box`, `Rc`, or `RefCell`:
-
-* `Rc` enables multiple owners of the same data; `Box` and `RefCell`
-  have single owners.
-* `Box` allows immutable or mutable borrows checked at compile time; `Rc`
-  allows only immutable borrows checked at compile time; `RefCell` allows
-  immutable or mutable borrows checked at runtime.
-* Because `RefCell` allows mutable borrows checked at runtime, you can
-  mutate the value inside the `RefCell` even when the `RefCell` is
-  immutable.
-
-Mutating the value inside an immutable value is the *interior mutability*
-pattern. Let’s look at a situation in which interior mutability is useful and
-examine how it’s possible.
-
-### Interior Mutability: A Mutable Borrow to an Immutable Value
-
-A consequence of the borrowing rules is that when you have an immutable value,
-you can’t borrow it mutably. For example, this code won’t compile:
-
-```
-fn main() {
-    let x = 5;
-    let y = &mut x;
-}
-```
-
-If you tried to compile this code, you’d get the following error:
-
-```
-error[E0596]: cannot borrow immutable local variable `x` as mutable
- --> src/main.rs:3:18
-  |
-2 |     let x = 5;
-  |         - consider changing this to `mut x`
-3 |     let y = &mut x;
-  |                  ^ cannot borrow mutably
-```
-
-However, there are situations in which it would be useful for a value to mutate
-itself in its methods but appear immutable to other code. Code outside the
-value’s methods would not be able to mutate the value. Using `RefCell` is
-one way to get the ability to have interior mutability. But `RefCell`
-doesn’t get around the borrowing rules completely: the borrow checker in the
-compiler allows this interior mutability, and the borrowing rules are checked
-at runtime instead. If you violate the rules, you’ll get a `panic!` instead of
-a compiler error.
-
-Let’s work through a practical example where we can use `RefCell` to mutate
-an immutable value and see why that is useful.
-
-#### A Use Case for Interior Mutability: Mock Objects
-
-A *test double* is the general programming concept for a type used in place of
-another type during testing. *Mock objects* are specific types of test doubles
-that record what happens during a test so you can assert that the correct
-actions took place.
-
-Rust doesn’t have objects in the same sense as other languages have objects,
-and Rust doesn’t have mock object functionality built into the standard library
-as some other languages do. However, you can definitely create a struct that
-will serve the same purposes as a mock object.
-
-Here’s the scenario we’ll test: we’ll create a library that tracks a value
-against a maximum value and sends messages based on how close to the maximum
-value the current value is. This library could be used to keep track of a
-user’s quota for the number of API calls they’re allowed to make, for example.
-
-Our library will only provide the functionality of tracking how close to the
-maximum a value is and what the messages should be at what times. Applications
-that use our library will be expected to provide the mechanism for sending the
-messages: the application could put a message in the application, send an
-email, send a text message, or something else. The library doesn’t need to know
-that detail. All it needs is something that implements a trait we’ll provide
-called `Messenger`. Listing 15-20 shows the library code:
-
-Filename: src/lib.rs
-
-```
-pub trait Messenger {
-    fn send(&self, msg: &str);
-}
-
-pub struct LimitTracker<'a, T: 'a + Messenger> {
-    messenger: &'a T,
-    value: usize,
-    max: usize,
-}
-
-impl<'a, T> LimitTracker<'a, T>
-    where T: Messenger {
-    pub fn new(messenger: &T, max: usize) -> LimitTracker {
-        LimitTracker {
-            messenger,
-            value: 0,
-            max,
-        }
-    }
-
-    pub fn set_value(&mut self, value: usize) {
-        self.value = value;
-
-        let percentage_of_max = self.value as f64 / self.max as f64;
-
-        if percentage_of_max >= 0.75 && percentage_of_max < 0.9 {
-            self.messenger.send("Warning: You've used up over 75% of your quota!");
-        } else if percentage_of_max >= 0.9 && percentage_of_max < 1.0 {
-            self.messenger.send("Urgent warning: You've used up over 90% of your quota!");
-        } else if percentage_of_max >= 1.0 {
-            self.messenger.send("Error: You are over your quota!");
-        }
-    }
-}
-```
-
-Listing 15-20: A library to keep track of how close a value is to a maximum
-value and warn when the value is at certain levels
-
-One important part of this code is that the `Messenger` trait has one method
-called `send` that takes an immutable reference to `self` and the text of the
-message. This is the interface our mock object needs to have. The other
-important part is that we want to test the behavior of the `set_value` method
-on the `LimitTracker`. We can change what we pass in for the `value` parameter,
-but `set_value` doesn’t return anything for us to make assertions on. We want
-to be able to say that if we create a `LimitTracker` with something that
-implements the `Messenger` trait and a particular value for `max`, when we pass
-different numbers for `value`, the messenger is told to send the appropriate
-messages.
-
-We need a mock object that, instead of sending an email or text message when we
-call `send`, will only keep track of the messages it’s told to send. We can
-create a new instance of the mock object, create a `LimitTracker` that uses the
-mock object, call the `set_value` method on `LimitTracker`, and then check that
-the mock object has the messages we expect. Listing 15-21 shows an attempt to
-implement a mock object to do just that, but the borrow checker won’t allow it:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    struct MockMessenger {
-        sent_messages: Vec,
-    }
-
-    impl MockMessenger {
-        fn new() -> MockMessenger {
-            MockMessenger { sent_messages: vec![] }
-        }
-    }
-
-    impl Messenger for MockMessenger {
-        fn send(&self, message: &str) {
-            self.sent_messages.push(String::from(message));
-        }
-    }
-
-    #[test]
-    fn it_sends_an_over_75_percent_warning_message() {
-        let mock_messenger = MockMessenger::new();
-        let mut limit_tracker = LimitTracker::new(&mock_messenger, 100);
-
-        limit_tracker.set_value(80);
-
-        assert_eq!(mock_messenger.sent_messages.len(), 1);
-    }
-}
-```
-
-Listing 15-21: An attempt to implement a `MockMessenger` that isn’t allowed by
-the borrow checker
-
-This test code defines a `MockMessenger` struct that has a `sent_messages`
-field with a `Vec` of `String` values to keep track of the messages it’s told
-to send. We also define an associated function `new` to make it convenient to
-create new `MockMessenger` values that start with an empty list of messages. We
-then implement the `Messenger` trait for `MockMessenger` so we can give a
-`MockMessenger` to a `LimitTracker`. In the definition of the `send` method, we
-take the message passed in as a parameter and store it in the `MockMessenger`
-list of `sent_messages`.
-
-In the test, we’re testing what happens when the `LimitTracker` is told to set
-`value` to something that is more than 75 percent of the `max` value. First, we
-create a new `MockMessenger`, which will start with an empty list of messages.
-Then we create a new `LimitTracker` and give it a reference to the new
-`MockMessenger` and a `max` value of 100. We call the `set_value` method on the
-`LimitTracker` with a value of 80, which is more than 75 percent of 100. Then
-we assert that the list of messages that the `MockMessenger` is keeping track
-of should now have one message in it.
-
-However, there’s one problem with this test, as shown here:
-
-```
-error[E0596]: cannot borrow immutable field `self.sent_messages` as mutable
-  --> src/lib.rs:52:13
-   |
-51 |         fn send(&self, message: &str) {
-   |                 ----- use `&mut self` here to make mutable
-52 |             self.sent_messages.push(String::from(message));
-   |             ^^^^^^^^^^^^^^^^^^ cannot mutably borrow immutable field
-```
-
-We can’t modify the `MockMessenger` to keep track of the messages, because the
-`send` method takes an immutable reference to `self`. We also can’t take the
-suggestion from the error text to use `&mut self` instead, because then the
-signature of `send` wouldn’t match the signature in the `Messenger` trait
-definition (feel free to try and see what error message you get).
-
-This is a situation in which interior mutability can help! We’ll store the
-`sent_messages` within a `RefCell`, and then the `send` message will be
-able to modify `sent_messages` to store the messages we’ve seen. Listing 15-22
-shows what that looks like:
-
-Filename: src/lib.rs
-
-```
-#[cfg(test)]
-mod tests {
-    use super::*;
-    use std::cell::RefCell;
-
-    struct MockMessenger {
-        sent_messages: RefCell>,
-    }
-
-    impl MockMessenger {
-        fn new() -> MockMessenger {
-            MockMessenger { sent_messages: RefCell::new(vec![]) }
-        }
-    }
-
-    impl Messenger for MockMessenger {
-        fn send(&self, message: &str) {
-            self.sent_messages.borrow_mut().push(String::from(message));
-        }
-    }
-
-    #[test]
-    fn it_sends_an_over_75_percent_warning_message() {
-        // --snip--
-
-        assert_eq!(mock_messenger.sent_messages.borrow().len(), 1);
-    }
-}
-```
-
-Listing 15-22: Using `RefCell` to mutate an inner value while the outer
-value is considered immutable
-
-The `sent_messages` field is now of type `RefCell>` instead of
-`Vec`. In the `new` function, we create a new `RefCell>`
-instance around the empty vector.
-
-For the implementation of the `send` method, the first parameter is still an
-immutable borrow of `self`, which matches the trait definition. We call
-`borrow_mut` on the `RefCell>` in `self.sent_messages` to get a
-mutable reference to the value inside the `RefCell>`, which is
-the vector. Then we can call `push` on the mutable reference to the vector to
-keep track of the messages sent during the test.
-
-The last change we have to make is in the assertion: to see how many items are
-in the inner vector, we call `borrow` on the `RefCell>` to get an
-immutable reference to the vector.
-
-Now that you’ve seen how to use `RefCell`, let’s dig into how it works!
-
-#### Keeping Track of Borrows at Runtime with `RefCell`
-
-When creating immutable and mutable references, we use the `&` and `&mut`
-syntax, respectively. With `RefCell`, we use the `borrow` and `borrow_mut`
-methods, which are part of the safe API that belongs to `RefCell`. The
-`borrow` method returns the smart pointer type `Ref`, and `borrow_mut`
-returns the smart pointer type `RefMut`. Both types implement `Deref`, so we
-can treat them like regular references.
-
-The `RefCell` keeps track of how many `Ref` and `RefMut` smart
-pointers are currently active. Every time we call `borrow`, the `RefCell`
-increases its count of how many immutable borrows are active. When a `Ref`
-value goes out of scope, the count of immutable borrows goes down by one. Just
-like the compile-time borrowing rules, `RefCell` lets us have many immutable
-borrows or one mutable borrow at any point in time.
-
-If we try to violate these rules, rather than getting a compiler error as we
-would with references, the implementation of `RefCell` will panic at
-runtime. Listing 15-23 shows a modification of the implementation of `send` in
-Listing 15-22. We’re deliberately trying to create two mutable borrows active
-for the same scope to illustrate that `RefCell` prevents us from doing this
-at runtime.
-
-Filename: src/lib.rs
-
-```
-impl Messenger for MockMessenger {
-    fn send(&self, message: &str) {
-        let mut one_borrow = self.sent_messages.borrow_mut();
-        let mut two_borrow = self.sent_messages.borrow_mut();
-
-        one_borrow.push(String::from(message));
-        two_borrow.push(String::from(message));
-    }
-}
-```
-
-Listing 15-23: Creating two mutable references in the same scope to see that
-`RefCell` will panic
-
-We create a variable `one_borrow` for the `RefMut` smart pointer returned
-from `borrow_mut`. Then we create another mutable borrow in the same way in the
-variable `two_borrow`. This makes two mutable references in the same scope,
-which isn’t allowed. When we run the tests for our library, the code in Listing
-15-23 will compile without any errors, but the test will fail:
-
-```
----- tests::it_sends_an_over_75_percent_warning_message stdout ----
-	thread 'tests::it_sends_an_over_75_percent_warning_message' panicked at
-'already borrowed: BorrowMutError', src/libcore/result.rs:906:4
-note: Run with `RUST_BACKTRACE=1` for a backtrace.
-```
-
-Notice that the code panicked with the message `already borrowed:
-BorrowMutError`. This is how `RefCell` handles violations of the borrowing
-rules at runtime.
-
-Catching borrowing errors at runtime rather than compile time means that you
-would find a mistake in your code later in the development process and possibly
-not until your code was deployed to production. Also, your code would incur a
-small runtime performance penalty as a result of keeping track of the borrows
-at runtime rather than compile time. However, using `RefCell` makes it
-possible to write a mock object that can modify itself to keep track of the
-messages it has seen while you’re using it in a context where only immutable
-values are allowed. You can use `RefCell` despite its trade-offs to get more
-functionality than regular references provide.
-
-### Having Multiple Owners of Mutable Data by Combining `Rc` and `RefCell`
-
-A common way to use `RefCell` is in combination with `Rc`. Recall that
-`Rc` lets you have multiple owners of some data, but it only gives immutable
-access to that data. If you have an `Rc` that holds a `RefCell`, you can
-get a value that can have multiple owners *and* that you can mutate!
-
-For example, recall the cons list example in Listing 15-18 where we used
-`Rc` to allow multiple lists to share ownership of another list. Because
-`Rc` holds only immutable values, we can’t change any of the values in the
-list once we’ve created them. Let’s add in `RefCell` to gain the ability to
-change the values in the lists. Listing 15-24 shows that by using a
-`RefCell` in the `Cons` definition, we can modify the value stored in all
-the lists:
-
-Filename: src/main.rs
-
-```
-#[derive(Debug)]
-enum List {
-    Cons(Rc>, Rc),
-    Nil,
-}
-
-use List::{Cons, Nil};
-use std::rc::Rc;
-use std::cell::RefCell;
-
-fn main() {
-    let value = Rc::new(RefCell::new(5));
-
-    let a = Rc::new(Cons(Rc::clone(&value), Rc::new(Nil)));
-
-    let b = Cons(Rc::new(RefCell::new(6)), Rc::clone(&a));
-    let c = Cons(Rc::new(RefCell::new(10)), Rc::clone(&a));
-
-    *value.borrow_mut() += 10;
-
-    println!("a after = {:?}", a);
-    println!("b after = {:?}", b);
-    println!("c after = {:?}", c);
-}
-```
-
-Listing 15-24: Using `Rc>` to create a `List` that we can mutate
-
-We create a value that is an instance of `Rc>` and store it in a
-variable named `value` so we can access it directly later. Then we create a
-`List` in `a` with a `Cons` variant that holds `value`. We need to clone
-`value` so both `a` and `value` have ownership of the inner `5` value rather
-than transferring ownership from `value` to `a` or having `a` borrow from
-`value`.
-
-We wrap the list `a` in an `Rc` so when we create lists `b` and `c`, they
-can both refer to `a`, which is what we did in Listing 15-18.
-
-After we’ve created the lists in `a`, `b`, and `c`, we add 10 to the value in
-`value`. We do this by calling `borrow_mut` on `value`, which uses the
-automatic dereferencing feature we discussed in Chapter 5 (see the section
-“Where’s the `->` Operator?”) to dereference the `Rc` to the inner
-`RefCell` value. The `borrow_mut` method returns a `RefMut` smart
-pointer, and we use the dereference operator on it and change the inner value.
-
-When we print `a`, `b`, and `c`, we can see that they all have the modified
-value of 15 rather than 5:
-
-```
-a after = Cons(RefCell { value: 15 }, Nil)
-b after = Cons(RefCell { value: 6 }, Cons(RefCell { value: 15 }, Nil))
-c after = Cons(RefCell { value: 10 }, Cons(RefCell { value: 15 }, Nil))
-```
-
-This technique is pretty neat! By using `RefCell`, we have an outwardly
-immutable `List` value. But we can use the methods on `RefCell` that provide
-access to its interior mutability so we can modify our data when we need to.
-The runtime checks of the borrowing rules protect us from data races, and it’s
-sometimes worth trading a bit of speed for this flexibility in our data
-structures.
-
-The standard library has other types that provide interior mutability, such as
-`Cell`, which is similar except that instead of giving references to the
-inner value, the value is copied in and out of the `Cell`. There’s also
-`Mutex`, which offers interior mutability that’s safe to use across threads;
-we’ll discuss its use in Chapter 16. Check out the standard library docs for
-more details on the differences between these types.
-
-## Reference Cycles Can Leak Memory
-
-Rust’s memory safety guarantees make it difficult, but not impossible, to
-accidentally create memory that is never cleaned up (known as a *memory leak*).
-Preventing memory leaks entirely is not one of Rust’s guarantees in the same
-way that disallowing data races at compile time is, meaning memory leaks are
-memory safe in Rust. We can see that Rust allows memory leaks by using `Rc`
-and `RefCell`: it’s possible to create references where items refer to each
-other in a cycle. This creates memory leaks because the reference count of each
-item in the cycle will never reach 0, and the values will never be dropped.
-
-### Creating a Reference Cycle
-
-Let’s look at how a reference cycle might happen and how to prevent it,
-starting with the definition of the `List` enum and a `tail` method in Listing
-15-25:
-
-Filename: src/main.rs
-
-```
-use std::rc::Rc;
-use std::cell::RefCell;
-use List::{Cons, Nil};
-
-#[derive(Debug)]
-enum List {
-    Cons(i32, RefCell>),
-    Nil,
-}
-
-impl List {
-    fn tail(&self) -> Option<&RefCell>> {
-        match *self {
-            Cons(_, ref item) => Some(item),
-            Nil => None,
-        }
-    }
-}
-```
-
-Listing 15-25: A cons list definition that holds a `RefCell` so we can
-modify what a `Cons` variant is referring to
-
-We’re using another variation of the `List` definition in Listing 15-5. The
-second element in the `Cons` variant is now `RefCell>`, meaning that
-instead of having the ability to modify the `i32` value as we did in Listing
-15-24, we want to modify which `List` value a `Cons` variant is pointing to.
-We’re also adding a `tail` method to make it convenient for us to access the
-second item if we have a `Cons` variant.
-
-In Listing 15-26, we’re adding a `main` function that uses the definitions in
-Listing 15-25. This code creates a list in `a` and a list in `b` that points to
-the list in `a`. Then it modifies the list in `a` to point to `b`, creating a
-reference cycle. There are `println!` statements along the way to show what the
-reference counts are at various points in this process.
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let a = Rc::new(Cons(5, RefCell::new(Rc::new(Nil))));
-
-    println!("a initial rc count = {}", Rc::strong_count(&a));
-    println!("a next item = {:?}", a.tail());
-
-    let b = Rc::new(Cons(10, RefCell::new(Rc::clone(&a))));
-
-    println!("a rc count after b creation = {}", Rc::strong_count(&a));
-    println!("b initial rc count = {}", Rc::strong_count(&b));
-    println!("b next item = {:?}", b.tail());
-
-    if let Some(link) = a.tail() {
-        *link.borrow_mut() = Rc::clone(&b);
-    }
-
-    println!("b rc count after changing a = {}", Rc::strong_count(&b));
-    println!("a rc count after changing a = {}", Rc::strong_count(&a));
-
-    // Uncomment the next line to see that we have a cycle;
-    // it will overflow the stack
-    // println!("a next item = {:?}", a.tail());
-}
-```
-
-Listing 15-26: Creating a reference cycle of two `List` values pointing to each
-other
-
-We create an `Rc` instance holding a `List` value in the variable `a`
-with an initial list of `5, Nil`. We then create an `Rc` instance
-holding another `List` value in the variable `b` that contains the value 10 and
-points to the list in `a`.
-
-We modify `a` so it points to `b` instead of `Nil`, creating a cycle. We
-do that by using the `tail` method to get a reference to the
-`RefCell>` in `a`, which we put in the variable `link`. Then we use
-the `borrow_mut` method on the `RefCell>` to change the value inside
-from an `Rc` that holds a `Nil` value to the `Rc` in `b`.
-
-When we run this code, keeping the last `println!` commented out for the
-moment, we’ll get this output:
-
-```
-a initial rc count = 1
-a next item = Some(RefCell { value: Nil })
-a rc count after b creation = 2
-b initial rc count = 1
-b next item = Some(RefCell { value: Cons(5, RefCell { value: Nil }) })
-b rc count after changing a = 2
-a rc count after changing a = 2
-```
-
-The reference count of the `Rc` instances in both `a` and `b` are 2
-after we change the list in `a` to point to `b`. At the end of `main`, Rust
-will try to drop `b` first, which will decrease the count in each of the
-`Rc` instances in `a` and `b` by 1.
-
-However, because `a` is still referencing the `Rc` that was in `b`, that
-`Rc` has a count of 1 rather than 0, so the memory the `Rc` has on
-the heap won’t be dropped. The memory will just sit there with a count of 1,
-forever. To visualize this reference cycle, we’ve created a diagram in Figure
-15-4.
-
-Reference cycle of lists
-
-Figure 15-4: A reference cycle of lists `a` and `b` pointing to each other
-
-If you uncomment the last `println!` and run the program, Rust will try to
-print this cycle with `a` pointing to `b` pointing to `a` and so forth until it
-overflows the stack.
-
-In this case, right after we create the reference cycle, the program ends. The
-consequences of this cycle aren’t very dire. However, if a more complex program
-allocated lots of memory in a cycle and held onto it for a long time, the
-program would use more memory than it needed and might overwhelm the system,
-causing it to run out of available memory.
-
-Creating reference cycles is not easily done, but it’s not impossible either.
-If you have `RefCell` values that contain `Rc` values or similar nested
-combinations of types with interior mutability and reference counting, you must
-ensure that you don’t create cycles; you can’t rely on Rust to catch them.
-Creating a reference cycle would be a logic bug in your program that you should
-use automated tests, code reviews, and other software development practices to
-minimize.
-
-Another solution for avoiding reference cycles is reorganizing your data
-structures so that some references express ownership and some references don’t.
-As a result, you can have cycles made up of some ownership relationships and
-some non-ownership relationships, and only the ownership relationships affect
-whether or not a value can be dropped. In Listing 15-25, we always want `Cons`
-variants to own their list, so reorganizing the data structure isn’t possible.
-Let’s look at an example using graphs made up of parent nodes and child nodes
-to see when non-ownership relationships are an appropriate way to prevent
-reference cycles.
-
-### Preventing Reference Cycles: Turning an `Rc` into a `Weak`
-
-So far, we’ve demonstrated that calling `Rc::clone` increases the
-`strong_count` of an `Rc` instance, and an `Rc` instance is only cleaned
-up if its `strong_count` is 0. You can also create a *weak reference* to the
-value within an `Rc` instance by calling `Rc::downgrade` and passing a
-reference to the `Rc`. When you call `Rc::downgrade`, you get a smart
-pointer of type `Weak`. Instead of increasing the `strong_count` in the
-`Rc` instance by 1, calling `Rc::downgrade` increases the `weak_count` by 1.
-The `Rc` type uses `weak_count` to keep track of how many `Weak`
-references exist, similar to `strong_count`. The difference is the `weak_count`
-doesn’t need to be 0 for the `Rc` instance to be cleaned up.
-
-Strong references are how you can share ownership of an `Rc` instance. Weak
-references don’t express an ownership relationship. They won’t cause a
-reference cycle because any cycle involving some weak references will be broken
-once the strong reference count of values involved is 0.
-
-Because the value that `Weak` references might have been dropped, to do
-anything with the value that a `Weak` is pointing to, you must make sure the
-value still exists. Do this by calling the `upgrade` method on a `Weak`
-instance, which will return an `Option>`. You’ll get a result of `Some`
-if the `Rc` value has not been dropped yet and a result of `None` if the
-`Rc` value has been dropped. Because `upgrade` returns an `Option`, Rust
-will ensure that the `Some` case and the `None` case are handled, and there
-won’t be an invalid pointer.
-
-As an example, rather than using a list whose items know only about the next
-item, we’ll create a tree whose items know about their children items *and*
-their parent items.
-
-#### Creating a Tree Data Structure: a `Node` with Child Nodes
-
-To start, we’ll build a tree with nodes that know about their child nodes.
-We’ll create a struct named `Node` that holds its own `i32` value as well as
-references to its children `Node` values:
-
-Filename: src/main.rs
-
-```
-use std::rc::Rc;
-use std::cell::RefCell;
-
-#[derive(Debug)]
-struct Node {
-    value: i32,
-    children: RefCell>>,
-}
-```
-
-We want a `Node` to own its children, and we want to share that ownership with
-variables so we can access each `Node` in the tree directly. To do this, we
-define the `Vec` items to be values of type `Rc`. We also want to
-modify which nodes are children of another node, so we have a `RefCell` in
-`children` around the `Vec>`.
-
-Next, we’ll use our struct definition and create one `Node` instance named
-`leaf` with the value 3 and no children, and another instance named `branch`
-with the value 5 and `leaf` as one of its children, as shown in Listing 15-27:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let leaf = Rc::new(Node {
-        value: 3,
-        children: RefCell::new(vec![]),
-    });
-
-    let branch = Rc::new(Node {
-        value: 5,
-        children: RefCell::new(vec![Rc::clone(&leaf)]),
-    });
-}
-```
-
-Listing 15-27: Creating a `leaf` node with no children and a `branch` node with
-`leaf` as one of its children
-
-We clone the `Rc` in `leaf` and store that in `branch`, meaning the
-`Node` in `leaf` now has two owners: `leaf` and `branch`. We can get from
-`branch` to `leaf` through `branch.children`, but there’s no way to get from
-`leaf` to `branch`. The reason is that `leaf` has no reference to `branch` and
-doesn’t know they’re related. We want `leaf` to know that `branch` is its
-parent. We’ll do that next.
-
-#### Adding a Reference from a Child to Its Parent
-
-To make the child node aware of its parent, we need to add a `parent` field to
-our `Node` struct definition. The trouble is in deciding what the type of
-`parent` should be. We know it can’t contain an `Rc`, because that would
-create a reference cycle with `leaf.parent` pointing to `branch` and
-`branch.children` pointing to `leaf`, which would cause their `strong_count`
-values to never be 0.
-
-Thinking about the relationships another way, a parent node should own its
-children: if a parent node is dropped, its child nodes should be dropped as
-well. However, a child should not own its parent: if we drop a child node, the
-parent should still exist. This is a case for weak references!
-
-So instead of `Rc`, we’ll make the type of `parent` use `Weak`,
-specifically a `RefCell>`. Now our `Node` struct definition looks
-like this:
-
-Filename: src/main.rs
-
-```
-use std::rc::{Rc, Weak};
-use std::cell::RefCell;
-
-#[derive(Debug)]
-struct Node {
-    value: i32,
-    parent: RefCell>,
-    children: RefCell>>,
-}
-```
-
-A node will be able to refer to its parent node but doesn’t own its parent.
-In Listing 15-28, we update `main` to use this new definition so the `leaf`
-node will have a way to refer to its parent, `branch`:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let leaf = Rc::new(Node {
-        value: 3,
-        parent: RefCell::new(Weak::new()),
-        children: RefCell::new(vec![]),
-    });
-
-    println!("leaf parent = {:?}", leaf.parent.borrow().upgrade());
-
-    let branch = Rc::new(Node {
-        value: 5,
-        parent: RefCell::new(Weak::new()),
-        children: RefCell::new(vec![Rc::clone(&leaf)]),
-    });
-
-    *leaf.parent.borrow_mut() = Rc::downgrade(&branch);
-
-    println!("leaf parent = {:?}", leaf.parent.borrow().upgrade());
-}
-```
-
-Listing 15-28: A `leaf` node with a weak reference to its parent node `branch`
-
-Creating the `leaf` node looks similar to how creating the `leaf` node looked
-in Listing 15-27 with the exception of the `parent` field: `leaf` starts out
-without a parent, so we create a new, empty `Weak` reference instance.
-
-At this point, when we try to get a reference to the parent of `leaf` by using
-the `upgrade` method, we get a `None` value. We see this in the output from the
-first `println!` statement:
-
-```
-leaf parent = None
-```
-
-When we create the `branch` node, it will also have a new `Weak`
-reference in the `parent` field, because `branch` doesn’t have a parent node.
-We still have `leaf` as one of the children of `branch`. Once we have the
-`Node` instance in `branch`, we can modify `leaf` to give it a `Weak`
-reference to its parent. We use the `borrow_mut` method on the
-`RefCell>` in the `parent` field of `leaf`, and then we use the
-`Rc::downgrade` function to create a `Weak` reference to `branch` from
-the `Rc` in `branch.`
-
-When we print the parent of `leaf` again, this time we’ll get a `Some` variant
-holding `branch`: now `leaf` can access its parent! When we print `leaf`, we
-also avoid the cycle that eventually ended in a stack overflow like we had in
-Listing 15-26; the `Weak` references are printed as `(Weak)`:
-
-```
-leaf parent = Some(Node { value: 5, parent: RefCell { value: (Weak) },
-children: RefCell { value: [Node { value: 3, parent: RefCell { value: (Weak) },
-children: RefCell { value: [] } }] } })
-```
-
-The lack of infinite output indicates that this code didn’t create a reference
-cycle. We can also tell this by looking at the values we get from calling
-`Rc::strong_count` and `Rc::weak_count`.
-
-#### Visualizing Changes to `strong_count` and `weak_count`
-
-Let’s look at how the `strong_count` and `weak_count` values of the `Rc`
-instances change by creating a new inner scope and moving the creation of
-`branch` into that scope. By doing so, we can see what happens when `branch` is
-created and then dropped when it goes out of scope. The modifications are shown
-in Listing 15-29:
-
-Filename: src/main.rs
-
-```
-fn main() {
-    let leaf = Rc::new(Node {
-        value: 3,
-        parent: RefCell::new(Weak::new()),
-        children: RefCell::new(vec![]),
-    });
-
-    println!(
-        "leaf strong = {}, weak = {}",
-        Rc::strong_count(&leaf),
-        Rc::weak_count(&leaf),
-    );
-
-    {
-        let branch = Rc::new(Node {
-            value: 5,
-            parent: RefCell::new(Weak::new()),
-            children: RefCell::new(vec![Rc::clone(&leaf)]),
-        });
-
-        *leaf.parent.borrow_mut() = Rc::downgrade(&branch);
-
-        println!(
-            "branch strong = {}, weak = {}",
-            Rc::strong_count(&branch),
-            Rc::weak_count(&branch),
-        );
-
-        println!(
-            "leaf strong = {}, weak = {}",
-            Rc::strong_count(&leaf),
-            Rc::weak_count(&leaf),
-        );
-    }
-
-    println!("leaf parent = {:?}", leaf.parent.borrow().upgrade());
-    println!(
-        "leaf strong = {}, weak = {}",
-        Rc::strong_count(&leaf),
-        Rc::weak_count(&leaf),
-    );
-}
-```
-
-Listing 15-29: Creating `branch` in an inner scope and examining strong and
-weak reference counts
-
-After `leaf` is created, its `Rc` has a strong count of 1 and a weak
-count of 0. In the inner scope, we create `branch` and associate it with
-`leaf`, at which point when we print the counts, the `Rc` in `branch`
-will have a strong count of 1 and a weak count of 1 (for `leaf.parent` pointing
-to `branch` with a `Weak`). When we print the counts in `leaf`, we’ll see
-it will have a strong count of 2, because `branch` now has a clone of the
-`Rc` of `leaf` stored in `branch.children`, but will still have a weak
-count of 0.
-
-When the inner scope ends, `branch` goes out of scope and the strong count of
-the `Rc` decreases to 0, so its `Node` is dropped. The weak count of 1
-from `leaf.parent` has no bearing on whether or not `Node` is dropped, so we
-don’t get any memory leaks!
-
-If we try to access the parent of `leaf` after the end of the scope, we’ll get
-`None` again. At the end of the program, the `Rc` in `leaf` has a strong
-count of 1 and a weak count of 0, because the variable `leaf` is now the only
-reference to the `Rc` again.
-
-All of the logic that manages the counts and value dropping is built into
-`Rc` and `Weak` and their implementations of the `Drop` trait. By
-specifying that the relationship from a child to its parent should be a
-`Weak` reference in the definition of `Node`, you’re able to have parent
-nodes point to child nodes and vice versa without creating a reference cycle
-and memory leaks.
-
-## Summary
-
-This chapter covered how to use smart pointers to make different guarantees and
-trade-offs than those Rust makes by default with regular references. The
-`Box` type has a known size and points to data allocated on the heap. The
-`Rc` type keeps track of the number of references to data on the heap so
-that data can have multiple owners. The `RefCell` type with its interior
-mutability gives us a type that we can use when we need an immutable type but
-need to change an inner value of that type; it also enforces the borrowing
-rules at runtime instead of at compile time.
-
-Also discussed were the `Deref` and `Drop` traits, which enable a lot of the
-functionality of smart pointers. We explored reference cycles that can cause
-memory leaks and how to prevent them using `Weak`.
-
-If this chapter has piqued your interest and you want to implement your own
-smart pointers, check out “The Rustonomicon” at
-*https://doc.rust-lang.org/stable/nomicon/* for more useful information.
-
-Next, we’ll talk about concurrency in Rust. You’ll even learn about a few new
-smart pointers.
diff --git a/src/doc/book/second-edition/nostarch/chapter16.md b/src/doc/book/second-edition/nostarch/chapter16.md
deleted file mode 100644
index b614d11e9c..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter16.md
+++ /dev/null
@@ -1,1306 +0,0 @@
-
-[TOC]
-
-# Fearless Concurrency
-
-Handling concurrent programming safely and efficiently is another of Rust’s
-major goals. *Concurrent programming*, where different parts of a program
-execute independently, and *parallel programming*, where different parts of a
-program execute at the same time, are becoming increasingly important as more
-computers take advantage of their multiple processors. Historically,
-programming in these contexts has been difficult and error prone: Rust hopes to
-change that.
-
-Initially, the Rust team thought that ensuring memory safety and preventing
-concurrency problems were two separate challenges to be solved with different
-methods. Over time, the team discovered that the ownership and type systems are
-a powerful set of tools to help manage memory safety *and* concurrency
-problems! By leveraging ownership and type checking, many concurrency errors
-are *compile time* errors in Rust rather than runtime errors. Therefore, rather
-than you spending lots of time trying to reproduce the exact circumstances
-under which a runtime concurrency bug occurs, incorrect code will refuse to
-compile and present an error explaining the problem. As a result, you can fix
-your code while you’re working on it rather than potentially after it has been
-shipped to production. We’ve nicknamed this aspect of Rust *fearless*
-*concurrency*. Fearless concurrency allows you to write code that is free of
-subtle bugs and is easy to refactor without introducing new bugs.
-
-> Note: For simplicity’s sake, we’ll refer to many of the problems as
-> concurrent rather than being more precise by saying concurrent and/or
-> parallel. If this book was specifically about concurrency and/or parallelism,
-> we’d be more specific. For this chapter, please mentally substitute
-> concurrent and/or parallel whenever we use concurrent.
-
-Many languages are dogmatic about the solutions they offer for handling
-concurrent problems. For example, Erlang has elegant functionality for message
-passing concurrency but has only obscure ways to share state between threads.
-Supporting only a subset of possible solutions is a reasonable strategy for
-higher-level languages, because a higher-level language promises benefits from
-giving up some control to gain abstractions. However, lower-level languages are
-expected to provide the solution with the best performance in any given
-situation and have fewer abstractions over the hardware. Therefore, Rust offers
-a variety of tools for modeling problems in whatever way is appropriate for
-your situation and requirements.
-
-Here are the topics we’ll cover in this chapter:
-
-* How to create threads to run multiple pieces of code at the same time
-* *Message passing* concurrency, where channels send messages between threads
-* *Shared state* concurrency, where multiple threads have access to some piece
-  of data
-* The `Sync` and `Send` traits, which extend Rust’s concurrency guarantees to
-  user-defined types as well as types provided by the standard library
-
-## Using Threads to Run Code Simultaneously
-
-In most current operating systems, an executed program’s code is run in a
-*process*, and the operating system manages multiple processes at once. Within
-your program, you can also have independent parts that run simultaneously. The
-feature that runs these independent parts is called *threads*.
-
-Splitting the computation in your program into multiple threads can improve
-performance because the program does multiple tasks at the same time, but it
-also adds complexity. Because threads can run simultaneously, there’s no
-inherent guarantee about the order in which parts of your code on different
-threads will run. This can lead to problems, such as:
-
-* Race conditions, where threads are accessing data or resources in an
-  inconsistent order
-* Deadlocks, where two threads are waiting for each other to finish using a
-  resource the other thread has, preventing both threads from continuing
-* Bugs that only happen in certain situations and are hard to reproduce and fix
-  reliably
-
-Rust attempts to mitigate the negative effects of using threads. Programming in
-a multithreaded context still takes careful thought and requires a code
-structure that is different from programs that run in a single thread.
-
-Programming languages implement threads in a few different ways. Many operating
-systems provide an API for creating new threads. This model where a language
-calls the operating system APIs to create threads is sometimes called *1:1*,
-one operating system thread per one language thread.
-
-Many programming languages provide their own special implementation of threads.
-Programming language-provided threads are known as *green* threads, and
-languages that use these green threads will execute them in the context of a
-different number of operating system threads. For this reason, the green
-threaded model is called the *M:N* model: `M` green threads per `N` operating
-system threads, where `M` and `N` are not necessarily the same number.
-
-Each model has its own advantages and trade-offs, and the trade-off most
-important to Rust is runtime support. Runtime is a confusing term and can have
-different meanings in different contexts.
-
-In this context, by *runtime* we mean code that is included by the language in
-every binary. This code can be large or small depending on the language, but
-every non-assembly language will have some amount of runtime code. For that
-reason, colloquially when people say a language has “no runtime,” they often
-mean “small runtime.” Smaller runtimes have fewer features but have the
-advantage of resulting in smaller binaries, which make it easier to combine the
-language with other languages in more contexts. Although many languages are
-okay with increasing the runtime size in exchange for more features, Rust needs
-to have nearly no runtime and cannot compromise on being able to call into C to
-maintain performance.
-
-The green threading M:N model requires a larger language runtime to manage
-threads. As such, the Rust standard library only provides an implementation of
-1:1 threading. Because Rust is such a low-level language, there are crates that
-implement M:N threading if you would rather trade overhead for aspects such as
-more control over which threads run when and lower costs of context switching,
-for example.
-
-Now that we’ve defined threads in Rust, let’s explore how to use the
-thread-related API provided by the standard library.
-
-### Creating a New Thread with `spawn`
-
-To create a new thread, we call the `thread::spawn` function and pass it a
-closure (we talked about closures in Chapter 13) containing the code we want to
-run in the new thread. The example in Listing 16-1 prints some text from a main
-thread and other text from a new thread:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::time::Duration;
-
-fn main() {
-    thread::spawn(|| {
-        for i in 1..10 {
-            println!("hi number {} from the spawned thread!", i);
-            thread::sleep(Duration::from_millis(1));
-        }
-    });
-
-    for i in 1..5 {
-        println!("hi number {} from the main thread!", i);
-        thread::sleep(Duration::from_millis(1));
-    }
-}
-```
-
-Listing 16-1: Creating a new thread to print one thing while the main thread
-prints something else
-
-Note that with this function, the new thread will be stopped when the main
-thread ends, whether or not it has finished running. The output from this
-program might be a little different every time, but it will look similar to the
-following:
-
-```
-hi number 1 from the main thread!
-hi number 1 from the spawned thread!
-hi number 2 from the main thread!
-hi number 2 from the spawned thread!
-hi number 3 from the main thread!
-hi number 3 from the spawned thread!
-hi number 4 from the main thread!
-hi number 4 from the spawned thread!
-hi number 5 from the spawned thread!
-```
-
-The calls to `thread::sleep` force a thread to stop its execution for a short
-duration, which allows a different thread to run. The threads will probably
-take turns, but that isn’t guaranteed: it depends on how your operating system
-schedules the threads. In this run, the main thread printed first, even though
-the print statement from the spawned thread appears first in the code. And even
-though we told the spawned thread to print until `i` is 9, it only got to 5
-before the main thread shut down.
-
-If you run this code and only see output from the main thread, or don’t see any
-overlap, try increasing the numbers in the ranges to create more opportunities
-for the operating system to switch between the threads.
-
-### Waiting for All Threads to Finish Using `join` Handles
-
-The code in Listing 16-1 not only stops the spawned thread prematurely most of
-the time due to the main thread ending, but there is no guarantee that the
-spawned thread will get to run at all. The reason is that there is no guarantee
-on the order in which threads run!
-
-We can fix the problem of the spawned thread not getting to run, or not getting
-to run completely, by saving the return value of `thread::spawn` in a variable.
-The return type of `thread::spawn` is `JoinHandle`. A `JoinHandle` is an owned
-value that, when we call the `join` method on it, will wait for its thread to
-finish. Listing 16-2 shows how to use the `JoinHandle` of the thread we created
-in Listing 16-1 and call `join` to make sure the spawned thread finishes before
-`main` exits:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::time::Duration;
-
-fn main() {
-    let handle = thread::spawn(|| {
-        for i in 1..10 {
-            println!("hi number {} from the spawned thread!", i);
-            thread::sleep(Duration::from_millis(1));
-        }
-    });
-
-    for i in 1..5 {
-        println!("hi number {} from the main thread!", i);
-        thread::sleep(Duration::from_millis(1));
-    }
-
-    handle.join().unwrap();
-}
-```
-
-Listing 16-2: Saving a `JoinHandle` from `thread::spawn` to guarantee the
-thread is run to completion
-
-Calling `join` on the handle blocks the thread currently running until the
-thread represented by the handle terminates. *Blocking* a thread means that
-thread is prevented from performing work or exiting. Because we’ve put the call
-to `join` after the main thread’s `for` loop, running Listing 16-2 should
-produce output similar to this:
-
-```
-hi number 1 from the main thread!
-hi number 2 from the main thread!
-hi number 1 from the spawned thread!
-hi number 3 from the main thread!
-hi number 2 from the spawned thread!
-hi number 4 from the main thread!
-hi number 3 from the spawned thread!
-hi number 4 from the spawned thread!
-hi number 5 from the spawned thread!
-hi number 6 from the spawned thread!
-hi number 7 from the spawned thread!
-hi number 8 from the spawned thread!
-hi number 9 from the spawned thread!
-```
-
-The two threads continue alternating, but the main thread waits because of the
-call to `handle.join()` and does not end until the spawned thread is finished.
-
-But let’s see what happens when we instead move `handle.join()` before the
-`for` loop in `main`, like this:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::time::Duration;
-
-fn main() {
-    let handle = thread::spawn(|| {
-        for i in 1..10 {
-            println!("hi number {} from the spawned thread!", i);
-            thread::sleep(Duration::from_millis(1));
-        }
-    });
-
-    handle.join().unwrap();
-
-    for i in 1..5 {
-        println!("hi number {} from the main thread!", i);
-        thread::sleep(Duration::from_millis(1));
-    }
-}
-```
-
-The main thread will wait for the spawned thread to finish and then run its
-`for` loop, so the output won’t be interleaved anymore, as shown here:
-
-```
-hi number 1 from the spawned thread!
-hi number 2 from the spawned thread!
-hi number 3 from the spawned thread!
-hi number 4 from the spawned thread!
-hi number 5 from the spawned thread!
-hi number 6 from the spawned thread!
-hi number 7 from the spawned thread!
-hi number 8 from the spawned thread!
-hi number 9 from the spawned thread!
-hi number 1 from the main thread!
-hi number 2 from the main thread!
-hi number 3 from the main thread!
-hi number 4 from the main thread!
-```
-
-Thinking about such a small detail as where to call `join` can affect whether
-or not your threads run at the same time.
-
-### Using `move` Closures with Threads
-
-The `move` closure, which we mentioned briefly in Chapter 13, is often used
-alongside `thread::spawn` because it allows us to use data from one thread in
-another thread.
-
-In Chapter 13, we said that “If we want to force the closure to take ownership
-of the values it uses in the environment, we can use the `move` keyword before
-the parameter list. This technique is mostly useful when passing a closure to a
-new thread to move the data so it’s owned by the new thread.”
-
-Now that we’re creating new threads, we’ll talk about capturing values in
-closures.
-
-Notice in Listing 16-1 that the closure we pass to `thread::spawn` takes no
-arguments: we’re not using any data from the main thread in the spawned
-thread’s code. To do so, the spawned thread’s closure must capture the values
-it needs. Listing 16-3 shows an attempt to create a vector in the main thread
-and use it in the spawned thread. However, this won’t yet work, as you’ll see
-in a moment:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-
-fn main() {
-    let v = vec![1, 2, 3];
-
-    let handle = thread::spawn(|| {
-        println!("Here's a vector: {:?}", v);
-    });
-
-    handle.join().unwrap();
-}
-```
-
-Listing 16-3: Attempting to use a vector created by the main thread in another
-thread
-
-The closure uses `v`, so it will capture `v` and make it part of the closure’s
-environment. Because `thread::spawn` runs this closure in a new thread, we
-should be able to access `v` inside that new thread. But when we compile this
-example, we get the following error:
-
-```
-error[E0373]: closure may outlive the current function, but it borrows `v`,
-which is owned by the current function
- --> src/main.rs:6:32
-  |
-6 |     let handle = thread::spawn(|| {
-  |                                ^^ may outlive borrowed value `v`
-7 |         println!("Here's a vector: {:?}", v);
-  |                                           - `v` is borrowed here
-  |
-help: to force the closure to take ownership of `v` (and any other referenced
-variables), use the `move` keyword
-  |
-6 |     let handle = thread::spawn(move || {
-  |                                ^^^^^^^
-```
-
-Rust *infers* how to capture `v`, and because `println!` only needs a reference
-to `v`, the closure tries to borrow `v`. However, there’s a problem: Rust can’t
-tell how long the spawned thread will run, so it doesn’t know if the reference
-to `v` will always be valid.
-
-Listing 16-4 provides a scenario that’s more likely to have a reference to `v`
-that won’t be valid:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-
-fn main() {
-    let v = vec![1, 2, 3];
-
-    let handle = thread::spawn(|| {
-        println!("Here's a vector: {:?}", v);
-    });
-
-    drop(v); // oh no!
-
-    handle.join().unwrap();
-}
-```
-
-Listing 16-4: A thread with a closure that attempts to capture a reference to
-`v` from a main thread that drops `v`
-
-If we were allowed to run this code, there’s a possibility the spawned thread
-will be immediately put in the background without running at all. The spawned
-thread has a reference to `v` inside, but the main thread immediately drops
-`v`, using the `drop` function we discussed in Chapter 15. Then, when the
-spawned thread starts to execute, `v` is no longer valid, so a reference to it
-is also invalid. Oh no!
-
-To fix the compiler error in Listing 16-3, we can use the error message’s
-advice:
-
-```
-help: to force the closure to take ownership of `v` (and any other referenced
-variables), use the `move` keyword
-  |
-6 |     let handle = thread::spawn(move || {
-  |                                ^^^^^^^
-```
-
-By adding the `move` keyword before the closure, we force the closure to take
-ownership of the values it’s using rather than allowing Rust to infer that it
-should borrow the values. The modification to Listing 16-3 shown in Listing
-16-5 will compile and run as we intend:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-
-fn main() {
-    let v = vec![1, 2, 3];
-
-    let handle = thread::spawn(move || {
-        println!("Here's a vector: {:?}", v);
-    });
-
-    handle.join().unwrap();
-}
-```
-
-Listing 16-5: Using the `move` keyword to force a closure to take ownership of
-the values it uses
-
-What would happen to the code in Listing 16-4 where the main thread called
-`drop` if we use a `move` closure? Would `move` fix that case? Unfortunately,
-no; we would get a different error because what Listing 16-4 is trying to do
-isn’t allowed for a different reason. If we add `move` to the closure, we would
-move `v` into the closure’s environment, and we could no longer call `drop` on
-it in the main thread. We would get this compiler error instead:
-
-```
-error[E0382]: use of moved value: `v`
-  --> src/main.rs:10:10
-   |
-6  |     let handle = thread::spawn(move || {
-   |                                ------- value moved (into closure) here
-...
-10 |     drop(v); // oh no!
-   |          ^ value used here after move
-   |
-   = note: move occurs because `v` has type `std::vec::Vec`, which does
-   not implement the `Copy` trait
-```
-
-Rust’s ownership rules have saved us again! We got an error from the code in
-Listing 16-3 because Rust was being conservative and only borrowing `v` for the
-thread, which meant the main thread could theoretically invalidate the spawned
-thread’s reference. By telling Rust to move ownership of `v` to the spawned
-thread, we’re guaranteeing Rust that the main thread won’t use `v` anymore. If
-we change Listing 16-4 in the same way, we’re then violating the ownership
-rules when we try to use `v` in the main thread. The `move` keyword overrides
-Rust’s conservative default of borrowing; it doesn’t let us violate the
-ownership rules.
-
-With a basic understanding of threads and the thread API, let’s look at what we
-can *do* with threads.
-
-## Message Passing to Transfer Data Between Threads
-
-One increasingly popular approach to ensuring safe concurrency is *message
-passing*, where threads or actors communicate by sending each other messages
-containing data. Here’s the idea in a slogan from the Go language documentation:
-
-> Do not communicate by sharing memory; instead, share memory by
-> communicating.
->
-> --Effective Go at *http://golang.org/doc/effective_go.html*
-
-One major tool Rust has for accomplishing message sending concurrency is the
-*channel*, a programming concept that Rust’s standard library provides an
-implementation of. You can imagine a channel in programming like a channel of
-water, such as a stream or a river. If you put something like a rubber duck or
-a boat into a stream, it will travel downstream to the end of the river.
-
-A channel in programming has two halves: a transmitter and a receiver. The
-transmitter half is the upstream location where we put rubber ducks into the
-river, and the receiver half is where the rubber duck ends up downstream. One
-part of our code calls methods on the transmitter with the data we want to
-send, and another part checks the receiving end for arriving messages. A
-channel is said to be *closed* if either the transmitter or receiver half is
-dropped.
-
-Here, we’ll work up to a program that has one thread to generate values and
-send them down a channel, and another thread that will receive the values and
-print them out. We’ll be sending simple values between threads using a channel
-to illustrate the feature. Once you’re familiar with the technique, you could
-use channels to implement a chat system or a system where many threads perform
-parts of a calculation and send the parts to one thread that aggregates the
-results.
-
-First, in Listing 16-6, we’ll create a channel but not do anything with it.
-Note that this won’t compile yet because Rust can’t tell what type of values we
-want to send over the channel:
-
-Filename: src/main.rs
-
-```
-use std::sync::mpsc;
-
-fn main() {
-    let (tx, rx) = mpsc::channel();
-}
-```
-
-Listing 16-6: Creating a channel and assigning the two halves to `tx` and `rx`
-
-We create a new channel using the `mpsc::channel` function; `mpsc` stands for
-*multiple producer, single consumer*. In short, the way Rust’s standard library
-implements channels means a channel can have multiple *sending* ends that
-produce values but only one *receiving* end that consumes those values. Imagine
-multiple rivers and streams flowing together into one big river: everything
-sent down any of the streams will end up in one river at the end. We’ll start
-with a single producer for now, but we’ll add multiple producers when we get
-this example working.
-
-The `mpsc::channel` function returns a tuple, the first element of which is the
-sending end and the second element is the receiving end. The abbreviations `tx`
-and `rx` are traditionally used in many fields for *transmitter* and *receiver*
-respectively, so we name our variables as such to indicate each end. We’re
-using a `let` statement with a pattern that destructures the tuples; we’ll
-discuss the use of patterns in `let` statements and destructuring in Chapter
-18. Using a `let` statement this way is a convenient approach to extract the
-pieces of the tuple returned by `mpsc::channel`.
-
-Let’s move the transmitting end into a spawned thread and have it send one
-string so the spawned thread is communicating with the main thread, as shown in
-Listing 16-7. This is like putting a rubber duck in the river upstream or
-sending a chat message from one thread to another:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::sync::mpsc;
-
-fn main() {
-    let (tx, rx) = mpsc::channel();
-
-    thread::spawn(move || {
-        let val = String::from("hi");
-        tx.send(val).unwrap();
-    });
-}
-```
-
-Listing 16-7: Moving `tx` to a spawned thread and sending “hi”
-
-Again, we’re using `thread::spawn` to create a new thread and then using `move`
-to move `tx` into the closure so the spawned thread owns `tx`. The spawned
-thread needs to own the transmitting end of the channel to be able to send
-messages through the channel.
-
-The transmitting end has a `send` method that takes the value we want to send.
-The `send` method returns a `Result` type, so if the receiving end has
-already been dropped and there’s nowhere to send a value, the send operation
-will return an error. In this example, we’re calling `unwrap` to panic in case
-of an error. But in a real application, we would handle it properly: return to
-Chapter 9 to review strategies for proper error handling.
-
-In Listing 16-8, we’ll get the value from the receiving end of the channel in
-the main thread. This is like retrieving the rubber duck from the water at the
-end of the river or like getting a chat message:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::sync::mpsc;
-
-fn main() {
-    let (tx, rx) = mpsc::channel();
-
-    thread::spawn(move || {
-        let val = String::from("hi");
-        tx.send(val).unwrap();
-    });
-
-    let received = rx.recv().unwrap();
-    println!("Got: {}", received);
-}
-```
-
-Listing 16-8: Receiving the value “hi” in the main thread and printing it
-
-The receiving end of a channel has two useful methods: `recv` and `try_recv`.
-We’re using `recv`, short for *receive*, which will block the main thread’s
-execution and wait until a value is sent down the channel. Once a value is
-sent, `recv` will return it in a `Result`. When the sending end of the
-channel closes, `recv` will return an error to signal that no more values will
-be coming.
-
-The `try_recv` method doesn’t block, but will instead return a `Result`
-immediately: an `Ok` value holding a message if one is available and an `Err`
-value if there aren’t any messages this time. Using `try_recv` is useful if
-this thread has other work to do while waiting for messages: we could write a
-loop that calls `try_recv` every so often, handles a message if one is
-available, and otherwise does other work for a little while until checking
-again.
-
-We’ve used `recv` in this example for simplicity; we don’t have any other work
-for the main thread to do other than wait for messages, so blocking the main
-thread is appropriate.
-
-When we run the code in Listing 16-8, we’ll see the value printed from the main
-thread:
-
-```
-Got: hi
-```
-
-Perfect!
-
-### Channels and Ownership Transference
-
-The ownership rules play a vital role in message sending because they help us
-write safe, concurrent code. Preventing errors in concurrent programming is the
-advantage we get by making the trade-off of having to think about ownership
-throughout our Rust programs. Let’s do an experiment to show how channels and
-ownership work together to prevent problems: we’ll try to use a `val` value in
-the spawned thread *after* we’ve sent it down the channel. Try compiling the
-code in Listing 16-9:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::sync::mpsc;
-
-fn main() {
-    let (tx, rx) = mpsc::channel();
-
-    thread::spawn(move || {
-        let val = String::from("hi");
-        tx.send(val).unwrap();
-        println!("val is {}", val);
-    });
-
-    let received = rx.recv().unwrap();
-    println!("Got: {}", received);
-}
-```
-
-Listing 16-9: Attempting to use `val` after we’ve sent it down the channel
-
-Here, we try to print `val` after we’ve sent it down the channel via `tx.send`.
-Allowing this would be a bad idea: once the value has been sent to another
-thread, that thread could modify or drop it before we try to use the value
-again. Potentially, the other thread’s modifications could cause errors or
-unexpected results due to inconsistent or nonexistent data. However, Rust gives
-us an error if we try to compile the code in Listing 16-9:
-
-```
-error[E0382]: use of moved value: `val`
-  --> src/main.rs:10:31
-   |
-9  |         tx.send(val).unwrap();
-   |                 --- value moved here
-10 |         println!("val is {}", val);
-   |                               ^^^ value used here after move
-   |
-   = note: move occurs because `val` has type `std::string::String`, which does
-not implement the `Copy` trait
-```
-
-Our concurrency mistake has caused a compile time error. The `send` function
-takes ownership of its parameter, and when the value is moved, the receiver
-takes ownership of it. This stops us from accidentally using the value again
-after sending it; the ownership system checks that everything is okay.
-
-### Sending Multiple Values and Seeing the Receiver Waiting
-
-The code in Listing 16-8 compiled and ran, but it didn’t clearly show us that
-two separate threads were talking to each other over the channel. In Listing
-16-10 we’ve made some modifications that will prove the code in Listing 16-8 is
-running concurrently: the spawned thread will now send multiple messages and
-pause for a second between each message:
-
-Filename: src/main.rs
-
-```
-use std::thread;
-use std::sync::mpsc;
-use std::time::Duration;
-
-fn main() {
-    let (tx, rx) = mpsc::channel();
-
-    thread::spawn(move || {
-        let vals = vec![
-            String::from("hi"),
-            String::from("from"),
-            String::from("the"),
-            String::from("thread"),
-        ];
-
-        for val in vals {
-            tx.send(val).unwrap();
-            thread::sleep(Duration::from_secs(1));
-        }
-    });
-
-    for received in rx {
-        println!("Got: {}", received);
-    }
-}
-```
-
-Listing 16-10: Sending multiple messages and pausing between each one
-
-This time, the spawned thread has a vector of strings that we want to send to
-the main thread. We iterate over them, sending each individually, and pause
-between each by calling the `thread::sleep` function with a `Duration` value of
-one second.
-
-In the main thread, we’re not calling the `recv` function explicitly anymore:
-instead, we’re treating `rx` as an iterator. For each value received, we’re
-printing it. When the channel is closed, iteration will end.
-
-When running the code in Listing 16-10, you should see the following output
-with a one second pause in between each line:
-
-```
-Got: hi
-Got: from
-Got: the
-Got: thread
-```
-
-Because we don’t have any code that pauses or delays in the `for` loop in the
-main thread, we can tell that the main thread is waiting to receive values from
-the spawned thread.
-
-### Creating Multiple Producers by Cloning the Transmitter
-
-Earlier we mentioned that `mpsc` was an acronym for *multiple* *producer,
-single consumer*. Let’s put `mpsc` to use and expand the code in Listing 16-10
-to create multiple threads that all send values to the same receiver. We can do
-so by cloning the transmitting half of the channel, as shown in Listing 16-11:
-
-Filename: src/main.rs
-
-```
-// --snip--
-
-let (tx, rx) = mpsc::channel();
-
-let tx1 = mpsc::Sender::clone(&tx);
-thread::spawn(move || {
-    let vals = vec![
-        String::from("hi"),
-        String::from("from"),
-        String::from("the"),
-        String::from("thread"),
-    ];
-
-    for val in vals {
-        tx1.send(val).unwrap();
-        thread::sleep(Duration::from_secs(1));
-    }
-});
-
-thread::spawn(move || {
-    let vals = vec![
-        String::from("more"),
-        String::from("messages"),
-        String::from("for"),
-        String::from("you"),
-    ];
-
-    for val in vals {
-        tx.send(val).unwrap();
-        thread::sleep(Duration::from_secs(1));
-    }
-});
-
-for received in rx {
-    println!("Got: {}", received);
-}
-
-// --snip--
-```
-
-Listing 16-11: Sending multiple messages from multiple producers
-
-This time, before we create the first spawned thread, we call `clone` on the
-sending end of the channel. This will give us a new sending handle we can pass
-to the first spawned thread. We pass the original sending end of the channel to
-a second spawned thread. This gives us two threads, each sending different
-messages to the receiving end of the channel.
-
-When you run the code, you’ll *probably* see output like this:
-
-```
-Got: hi
-Got: more
-Got: from
-Got: messages
-Got: for
-Got: the
-Got: thread
-Got: you
-```
-
-You might see the values in another order; it depends on your system. This is
-what makes concurrency interesting as well as difficult. If you experiment with
-`thread::sleep`, giving it various values in the different threads, each run
-will be more non-deterministic and create different output each time.
-
-Now that we’ve looked at how channels work, let’s look at a different method of
-concurrency.
-
-## Shared State Concurrency
-
-Message passing is a fine way of handling concurrency, but it’s not the only
-one. Consider this part of the slogan from the Go language documentation again:
-“communicate by sharing memory.”
-
-What would communicating by sharing memory look like? In addition, why would
-message passing enthusiasts not use it and do the opposite instead?
-
-In a way, channels in any programming language are similar to single ownership,
-because once you transfer a value down a channel, you should no longer use that
-value. Shared memory concurrency is like multiple ownership: multiple threads
-can access the same memory location at the same time. As you saw in Chapter 15
-where smart pointers made multiple ownership possible, multiple ownership can
-add additional complexity because these different owners need managing. Rust’s
-type system and ownership rules greatly assist in getting this management
-correct. For an example, let’s look at mutexes, one of the more common
-concurrency primitives for shared memory.
-
-### Mutexes Allow Access to Data from One Thread at a Time
-
-A *mutex* is an abbreviation for “mutual exclusion,” as in, it only allows one
-thread to access some data at any given time. To access the data in a mutex, a
-thread must first signal that it wants access by asking to acquire the mutex’s
-*lock*. The lock is a data structure that is part of the mutex that keeps track
-of who currently has exclusive access to the data. Therefore, we describe the
-mutex as *guarding* the data it holds via the locking system.
-
-Mutexes have a reputation for being difficult to use because you have to
-remember two rules:
-
-1. You must attempt to acquire the lock before using the data.
-2. When you’re done with the data that the mutex guards, you must unlock the
-   data so other threads can acquire the lock.
-
-For a real-world metaphor of a mutex, imagine a panel discussion at a
-conference with only one microphone. Before a panelist can speak, they have to
-ask or signal that they want to use the microphone. When they get the
-microphone, they can talk for as long as they want to and then hand the
-microphone to the next panelist who requests to speak. If a panelist forgets to
-hand the microphone off when they’re finished with it, no one else is able to
-speak. If management of the shared microphone goes wrong, the panel wouldn’t
-work as planned!
-
-Management of mutexes can be incredibly tricky to get right, which is why so
-many people are enthusiastic about channels. However, thanks to Rust’s type
-system and ownership rules, we can’t get locking and unlocking wrong.
-
-#### The API of `Mutex`
-
-As an example of how to use a mutex, let’s start by using a mutex in a
-single-threaded context, as shown in Listing 16-12:
-
-Filename: src/main.rs
-
-```
-use std::sync::Mutex;
-
-fn main() {
-    let m = Mutex::new(5);
-
-    {
-        let mut num = m.lock().unwrap();
-        *num = 6;
-    }
-
-    println!("m = {:?}", m);
-}
-```
-
-Listing 16-12: Exploring the API of `Mutex` in a single-threaded context for
-simplicity
-
-As with many types, we create a `Mutex` using the associated function `new`.
-To access the data inside the mutex, we use the `lock` method to acquire the
-lock. This call will block the current thread so it can’t do any work until
-it’s our turn to have the lock.
-
-The call to `lock` would fail if another thread holding the lock panicked. In
-that case, no one would ever be able to get the lock, so we’ve chosen to
-`unwrap` and have this thread panic if we’re in that situation.
-
-After we’ve acquired the lock, we can treat the return value, named `num` in
-this case, as a mutable reference to the data inside. The type system ensures
-that we acquire a lock before using the value in `m`: `Mutex` is not an
-`i32`, so we *must* acquire the lock to be able to use the `i32` value. We
-can’t forget; the type system won’t let us access the inner `i32` otherwise.
-
-As you might suspect, `Mutex` is a smart pointer. More accurately, the call
-to `lock` *returns* a smart pointer called `MutexGuard`. This smart pointer
-implements `Deref` to point at our inner data; the smart pointer also has a
-`Drop` implementation that releases the lock automatically when a `MutexGuard`
-goes out of scope, which happens at the end of the inner scope in Listing
-16-12. As a result, we don’t risk forgetting to release the lock and blocking
-the mutex from being used by other threads because the lock release happens
-automatically.
-
-After dropping the lock, we can print the mutex value and see that we were able
-to change the inner `i32` to 6.
-
-#### Sharing a `Mutex` Between Multiple Threads
-
-Now, let’s try to share a value between multiple threads using `Mutex`.
-We’ll spin up 10 threads and have them each increment a counter value by 1, so
-the counter goes from 0 to 10. Note that the next few examples will have
-compiler errors, and we’ll use those errors to learn more about using
-`Mutex` and how Rust helps us use it correctly. Listing 16-13 has our
-starting example:
-
-Filename: src/main.rs
-
-```
-use std::sync::Mutex;
-use std::thread;
-
-fn main() {
-    let counter = Mutex::new(0);
-    let mut handles = vec![];
-
-    for _ in 0..10 {
-        let handle = thread::spawn(move || {
-            let mut num = counter.lock().unwrap();
-
-            *num += 1;
-        });
-        handles.push(handle);
-    }
-
-    for handle in handles {
-        handle.join().unwrap();
-    }
-
-    println!("Result: {}", *counter.lock().unwrap());
-}
-```
-
-Listing 16-13: Ten threads each increment a counter guarded by a `Mutex`
-
-We’re creating a `counter` variable to hold an `i32` inside a `Mutex`, as we
-did in Listing 16-12. Next, we’re creating 10 threads by mapping over a range
-of numbers. We use `thread::spawn` and give all the threads the same closure,
-one that moves the counter into the thread, acquires a lock on the `Mutex`
-by calling the `lock` method, and then adds 1 to the value in the mutex. When a
-thread finishes running its closure, `num` will go out of scope and release the
-lock so another thread can acquire it.
-
-In the main thread, we collect all the join handles, as we did in Listing 16-2,
-and then call `join` on each to make sure all the threads finish. At that
-point, the main thread will acquire the lock and print the result of this
-program.
-
-We hinted that this example won’t compile, now let’s find out why!
-
-```
-error[E0382]: capture of moved value: `counter`
-  --> src/main.rs:10:27
-   |
-9  |         let handle = thread::spawn(move || {
-   |                                    ------- value moved (into closure) here
-10 |             let mut num = counter.lock().unwrap();
-   |                           ^^^^^^^ value captured here after move
-   |
-   = note: move occurs because `counter` has type `std::sync::Mutex`,
-   which does not implement the `Copy` trait
-
-error[E0382]: use of moved value: `counter`
-  --> src/main.rs:21:29
-   |
-9  |         let handle = thread::spawn(move || {
-   |                                    ------- value moved (into closure) here
-...
-21 |     println!("Result: {}", *counter.lock().unwrap());
-   |                             ^^^^^^^ value used here after move
-   |
-   = note: move occurs because `counter` has type `std::sync::Mutex`,
-   which does not implement the `Copy` trait
-
-error: aborting due to 2 previous errors
-```
-
-The error message states that the `counter` value is moved into the closure and
-then is captured when we call `lock`. That description sounds like what we
-wanted, but it’s not allowed!
-
-Let’s figure this out by simplifying the program. Instead of making 10 threads
-in a `for` loop, let’s just make two threads without a loop and see what
-happens. Replace the first `for` loop in Listing 16-13 with this code instead:
-
-```
-let handle = thread::spawn(move || {
-    let mut num = counter.lock().unwrap();
-
-    *num += 1;
-});
-handles.push(handle);
-
-let handle2 = thread::spawn(move || {
-    let mut num2 = counter.lock().unwrap();
-
-    *num2 += 1;
-});
-handles.push(handle2);
-```
-
-We make two threads and change the variable names used with the second thread
-to `handle2` and `num2`. When we run the code this time, compiling gives us the
-following:
-
-```
-error[E0382]: capture of moved value: `counter`
-  --> src/main.rs:16:24
-   |
-8  |     let handle = thread::spawn(move || {
-   |                                ------- value moved (into closure) here
-...
-16 |         let mut num2 = counter.lock().unwrap();
-   |                        ^^^^^^^ value captured here after move
-   |
-   = note: move occurs because `counter` has type `std::sync::Mutex`,
-   which does not implement the `Copy` trait
-
-error[E0382]: use of moved value: `counter`
-  --> src/main.rs:26:29
-   |
-8  |     let handle = thread::spawn(move || {
-   |                                ------- value moved (into closure) here
-...
-26 |     println!("Result: {}", *counter.lock().unwrap());
-   |                             ^^^^^^^ value used here after move
-   |
-   = note: move occurs because `counter` has type `std::sync::Mutex`,
-   which does not implement the `Copy` trait
-
-error: aborting due to 2 previous errors
-```
-
-Aha! The first error message indicates that `counter` is moved into the closure
-for the thread associated with `handle`. That move is preventing us from
-capturing `counter` when we try to call `lock` on it and store the result in
-`num2` in the second thread! So Rust is telling us that we can’t move ownership
-of `counter` into multiple threads. This was hard to see earlier because our
-threads were in a loop, and Rust can’t point to different threads in different
-iterations of the loop. Let’s fix the compiler error with a multiple-ownership
-method we discussed in Chapter 15.
-
-#### Multiple Ownership with Multiple Threads
-
-In Chapter 15, we gave a value multiple owners by using the smart pointer
-`Rc` to create a reference-counted value. Let’s do the same here and see
-what happens. We’ll wrap the `Mutex` in `Rc` in Listing 16-14 and clone
-the `Rc` before moving ownership to the thread. Now that we’ve seen the
-errors, we’ll also switch back to using the `for` loop, and we’ll keep the
-`move` keyword with the closure:
-
-Filename: src/main.rs
-
-```
-use std::rc::Rc;
-use std::sync::Mutex;
-use std::thread;
-
-fn main() {
-    let counter = Rc::new(Mutex::new(0));
-    let mut handles = vec![];
-
-    for _ in 0..10 {
-        let counter = Rc::clone(&counter);
-        let handle = thread::spawn(move || {
-            let mut num = counter.lock().unwrap();
-
-            *num += 1;
-        });
-        handles.push(handle);
-    }
-
-    for handle in handles {
-        handle.join().unwrap();
-    }
-
-    println!("Result: {}", *counter.lock().unwrap());
-}
-```
-
-Listing 16-14: Attempting to use `Rc` to allow multiple threads to own the
-`Mutex`
-
-Once again, we compile and get... different errors! The compiler is teaching us
-a lot.
-
-```
-error[E0277]: the trait bound `std::rc::Rc>:
-std::marker::Send` is not satisfied in `[closure@src/main.rs:11:36:
-15:10 counter:std::rc::Rc>]`
-  --> src/main.rs:11:22
-   |
-11 |         let handle = thread::spawn(move || {
-   |                      ^^^^^^^^^^^^^ `std::rc::Rc>`
-cannot be sent between threads safely
-   |
-   = help: within `[closure@src/main.rs:11:36: 15:10
-counter:std::rc::Rc>]`, the trait `std::marker::Send` is
-not implemented for `std::rc::Rc>`
-   = note: required because it appears within the type
-`[closure@src/main.rs:11:36: 15:10 counter:std::rc::Rc>]`
-   = note: required by `std::thread::spawn`
-```
-
-Wow, that error message is very wordy! Here are some important parts to focus
-on: the first inline error says `` `std::rc::Rc>` cannot
-be sent between threads safely ``. The reason for this is in the next important
-part to focus on, the error message. The distilled error message says `` the
-trait bound `Send` is not satisfied ``. We’ll talk about `Send` in the next
-section: it’s one of the traits that ensures the types we use with threads are
-meant for use in concurrent situations.
-
-Unfortunately, `Rc` is not safe to share across threads. When `Rc`
-manages the reference count, it adds to the count for each call to `clone` and
-subtracts from the count when each clone is dropped. But it doesn’t use any
-concurrency primitives to make sure that changes to the count can’t be
-interrupted by another thread. This could lead to wrong counts—subtle bugs that
-could in turn lead to memory leaks or a value being dropped before we’re done
-with it. What we need is a type exactly like `Rc` but one that makes changes
-to the reference count in a thread-safe way.
-
-#### Atomic Reference Counting with `Arc`
-
-Fortunately, `Arc` *is* a type like `Rc` that is safe to use in
-concurrent situations. The ‘a’ stands for *atomic*, meaning it’s an *atomically
-reference counted* type. Atomics are an additional kind of concurrency
-primitive that we won’t cover in detail here: see the standard library
-documentation for `std::sync::atomic` for more details. At this point, you just
-need to know that atomics work like primitive types but are safe to share
-across threads.
-
-You might then wonder why all primitive types aren’t atomic and why standard
-library types aren’t implemented to use `Arc` by default. The reason is that
-thread safety comes with a performance penalty that you only want to pay when
-you really need to. If you’re just performing operations on values within a
-single thread, your code can run faster if it doesn’t have to enforce the
-guarantees atomics provide.
-
-Let’s return to our example: `Arc` and `Rc` have the same API, so we fix
-our program by changing the `use` line, the call to `new`, and the call to
-`clone`. The code in Listing 16-15 will finally compile and run:
-
-Filename: src/main.rs
-
-```
-use std::sync::{Mutex, Arc};
-use std::thread;
-
-fn main() {
-    let counter = Arc::new(Mutex::new(0));
-    let mut handles = vec![];
-
-    for _ in 0..10 {
-        let counter = Arc::clone(&counter);
-        let handle = thread::spawn(move || {
-            let mut num = counter.lock().unwrap();
-
-            *num += 1;
-        });
-        handles.push(handle);
-    }
-
-    for handle in handles {
-        handle.join().unwrap();
-    }
-
-    println!("Result: {}", *counter.lock().unwrap());
-}
-```
-
-Listing 16-15: Using an `Arc` to wrap the `Mutex` to be able to share
-ownership across multiple threads
-
-This code will print the following:
-
-```
-Result: 10
-```
-
-We did it! We counted from 0 to 10, which may not seem very impressive, but it
-did teach us a lot about `Mutex` and thread safety. You could also use this
-program’s structure to do more complicated operations than just incrementing a
-counter. Using this strategy, you can divide a calculation into independent
-parts, split those parts across threads, then use a `Mutex` to have each
-thread update the final result with its part.
-
-### Similarities Between `RefCell`/`Rc` and `Mutex`/`Arc`
-
-You might have noticed that `counter` is immutable, but we could get a mutable
-reference to the value inside it; this means `Mutex` provides interior
-mutability, like the `Cell` family does. In the same way we used `RefCell`
-in Chapter 15 to allow us to mutate contents inside an `Rc`, we use
-`Mutex` to mutate contents inside an `Arc`.
-
-Another detail to note is that Rust can’t protect us from all kinds of logic
-errors when we use `Mutex`. Recall in Chapter 15 that using `Rc` came
-with the risk of creating reference cycles, where two `Rc` values refer to
-each other, causing memory leaks. Similarly, `Mutex` comes with the risk of
-creating *deadlocks*. These occur when an operation needs to lock two resources
-and two threads have each acquired one of the locks, causing them to wait for
-each other forever. If you’re interested in deadlocks, try creating a Rust
-program that has a deadlock; then research deadlock mitigation strategies for
-mutexes in any language and have a go at implementing them in Rust. The
-standard library API documentation for `Mutex` and `MutexGuard` offers
-useful information.
-
-We’ll round out this chapter by talking about the `Send` and `Sync` traits, and
-how we can use them with custom types.
-
-## Extensible Concurrency with the `Sync` and `Send` Traits
-
-Interestingly, the Rust language has *very* few concurrency features. Almost
-every concurrency feature we’ve talked about so far in this chapter has been
-part of the standard library, not the language. Our options for handling
-concurrency are not limited to the language or the standard library; we can
-write our own concurrency features or use those written by others.
-
-However, two concurrency concepts are embedded in the language: the
-`std::marker` traits `Sync` and `Send`.
-
-### Allowing Transference of Ownership Between Threads with `Send`
-
-The `Send` marker trait indicates that ownership of the type implementing
-`Send` can be transferred between threads. Almost every Rust type is `Send`,
-but there are some exceptions, including `Rc`: this cannot be `Send` because
-if we cloned an `Rc` value and tried to transfer ownership of the clone to
-another thread, both threads might update the reference count at the same time.
-For this reason, `Rc` is implemented for use in single-threaded situations
-where you don’t want to pay the thread-safe performance penalty.
-
-Therefore, Rust’s type system and trait bounds ensure that we can never
-accidentally send an `Rc` value across threads unsafely. When we tried to do
-this in Listing 16-14, we got the error `the trait Send is not implemented for
-Rc>`. When we switched to `Arc`, which is `Send`, the code
-compiled.
-
-Any type composed entirely of `Send` types is automatically marked as `Send` as
-well. Almost all primitive types are `Send`, aside from raw pointers, which
-we’ll discuss in Chapter 19.
-
-### Allowing Access from Multiple Threads with `Sync`
-
-The `Sync` marker trait indicates that it is safe for the type implementing
-`Sync` to be referenced from multiple threads. In other words, any type `T` is
-`Sync` if `&T` (a reference to `T`) is `Send`, meaning the reference can be
-sent safely to another thread. Similar to `Send`, primitive types are `Sync`
-and types composed entirely of types that are `Sync` are also `Sync`.
-
-The smart pointer `Rc` is also not `Sync` for the same reasons that it’s not
-`Send`. The `RefCell` type (which we talked about in Chapter 15) and the
-family of related `Cell` types are not `Sync`. The implementation of borrow
-checking that `RefCell` does at runtime is not thread-safe. The smart
-pointer `Mutex` is `Sync` and can be used to share access with multiple
-threads, as you saw in the “Sharing a `Mutex` Between Multiple Threads”
-section.
-
-### Implementing `Send` and `Sync` Manually Is Unsafe
-
-Because types that are made up of `Send` and `Sync` traits are automatically
-also `Send` and `Sync`, we don’t have to implement those traits manually. As
-marker traits, they don’t even have any methods to implement. They’re just
-useful for enforcing invariants related to concurrency.
-
-Manually implementing these traits involves implementing unsafe Rust code.
-We’ll talk about using unsafe Rust code in Chapter 19; for now, the important
-information is that building new concurrent types not made up of `Send` and
-`Sync` parts requires careful thought to uphold the safety guarantees.
-The Rustonomicon at *https://doc.rust-lang.org/stable/nomicon/* has more
-information about these guarantees and how to uphold them.
-
-## Summary
-
-This isn’t the last you’ll see of concurrency in this book: the project in
-Chapter 20 will use the concepts examined in this chapter in a more realistic
-situation than the smaller examples discussed here.
-
-As mentioned earlier, because very little of how Rust handles concurrency is
-part of the language, many concurrency solutions are implemented as crates.
-These evolve more quickly than the standard library, so be sure to search
-online for the current, state-of-the-art crates to use in multithreaded
-situations.
-
-The Rust standard library provides channels for message passing and smart
-pointer types, such as `Mutex` and `Arc`, that are safe to use in
-concurrent contexts. The type system and the borrow checker ensure that the
-code using these solutions won’t end up with data races or invalid references.
-Once we get our code to compile, we can rest assured that it will happily run
-on multiple threads without the kinds of hard-to-track-down bugs common in
-other languages. Concurrent programming is no longer a concept to be afraid of:
-go forth and make your programs concurrent, fearlessly!
-
-Next, we’ll talk about idiomatic ways to model problems and structure solutions
-as your Rust programs get bigger. In addition, we’ll discuss how Rust’s idioms
-relate to those you might be familiar with from object-oriented programming.
diff --git a/src/doc/book/second-edition/nostarch/chapter17.md b/src/doc/book/second-edition/nostarch/chapter17.md
deleted file mode 100644
index 4bbb004b9c..0000000000
--- a/src/doc/book/second-edition/nostarch/chapter17.md
+++ /dev/null
@@ -1,1267 +0,0 @@
-
-[TOC]
-
-# Is Rust an Object-Oriented Programming Language?
-
-Object-oriented programming (OOP) is a way of modeling programs. Objects came
-from Simula in the 1960s. Those objects influenced Alan Kay’s programming
-architecture where objects pass messages to each other. He coined the term
-object-oriented programming in 1967 to describe this architecture. Many
-competing definitions describe what OOP is; some definitions would classify
-Rust as object oriented but other definitions would not. In this chapter, we’ll
-explore certain characteristics that are commonly considered object oriented
-and how those characteristics translate to idiomatic Rust. We’ll then show you
-how to implement an object-oriented design pattern in Rust and discuss the
-trade-offs of doing so versus implementing a solution using some of Rust’s
-strengths instead.
-
-## What Does Object Oriented Mean?
-
-There is no consensus in the programming community about what features a
-language needs to be considered object oriented. Rust is influenced by many
-different programming paradigms, including OOP; for example, we explored the
-features that came from functional programming in Chapter 13. Arguably, OOP
-languages share certain common characteristics, namely objects, encapsulation,
-and inheritance. Let’s look at what each of those characteristics mean and
-whether Rust supports them.
-
-### Objects Contain Data and Behavior
-
-The book *Design Patterns: Elements of Reusable Object-Oriented Software*,
-colloquially referred to as *The Gang of Four book*, is a catalog of
-object-oriented design patterns. It defines OOP this way:
-
-> Object-oriented programs are made up of objects. An *object* packages both
-> data and the procedures that operate on that data. The procedures are
-> typically called *methods* or *operations*.
-
-Using this definition, Rust is object oriented: structs and enums have data,
-and `impl` blocks provide methods on structs and enums. Even though structs and
-enums with methods aren’t *called* objects, they provide the same
-functionality, according to the Gang of Four’s definition of objects.
-
-### Encapsulation that Hides Implementation Details
-
-Another aspect commonly associated with OOP is the idea of *encapsulation*,
-which means that the implementation details of an object aren’t accessible to
-code using that object. Therefore, the only way to interact with an object is
-through its public API; code using the object shouldn’t be able to reach into
-the object’s internals and change data or behavior directly. This enables the
-programmer to change and refactor an object’s internals without needing to
-change the code that uses the object.
-
-We discussed how to control encapsulation in Chapter 7: we can use the `pub`
-keyword to decide which modules, types, functions, and methods in our code
-should be public, and by default everything else is private. For example, we
-can define a struct `AveragedCollection` that has a field containing a vector
-of `i32` values. The struct can also have a field that contains the average of
-the values in the vector, meaning the average doesn’t have to be computed
-on-demand whenever anyone needs it. In other words, `AveragedCollection` will
-cache the calculated average for us. Listing 17-1 has the definition of the
-`AveragedCollection` struct:
-
-Filename: src/lib.rs
-
-```
-pub struct AveragedCollection {
-    list: Vec,
-    average: f64,
-}
-```
-
-Listing 17-1: An `AveragedCollection` struct that maintains a list of integers
-and the average of the items in the collection
-
-The struct is marked `pub` so that other code can use it, but the fields within
-the struct remain private. This is important in this case because we want to
-ensure that whenever a value is added or removed from the list, the average is
-also updated. We do this by implementing `add`, `remove`, and `average` methods
-on the struct, as shown in Listing 17-2:
-
-Filename: src/lib.rs
-
-```
-impl AveragedCollection {
-    pub fn add(&mut self, value: i32) {
-        self.list.push(value);
-        self.update_average();
-    }
-
-    pub fn remove(&mut self) -> Option {
-        let result = self.list.pop();
-        match result {
-            Some(value) => {
-                self.update_average();
-                Some(value)
-            },
-            None => None,
-        }
-    }
-
-    pub fn average(&self) -> f64 {
-        self.average
-    }
-
-    fn update_average(&mut self) {
-        let total: i32 = self.list.iter().sum();
-        self.average = total as f64 / self.list.len() as f64;
-    }
-}
-```
-
-Listing 17-2: Implementations of the public methods `add`, `remove`, and
-`average` on `AveragedCollection`
-
-The public methods `add`, `remove`, and `average` are the only ways to modify
-an instance of `AveragedCollection`. When an item is added to `list` using the
-`add` method or removed using the `remove` method, the implementations of each
-call the private `update_average` method that handles updating the `average`
-field as well.
-
-We leave the `list` and `average` fields private so there is no way for
-external code to add or remove items to the `list` field directly; otherwise,
-the `average` field might become out of sync when the `list` changes. The
-`average` method returns the value in the `average` field, allowing external
-code to read the `average` but not modify it.
-
-Because we’ve encapsulated the implementation details of `AveragedCollection`,
-we can easily change aspects, such as the data structure, in the future. For
-instance, we could use a `HashSet` instead of a `Vec` for the `list` field. As
-long as the signatures of the `add`, `remove`, and `average` public methods
-stay the same, code using `AveragedCollection` wouldn’t need to change. If we
-made `list` public instead, this wouldn’t necessarily be the case: `HashSet`
-and `Vec` have different methods for adding and removing items, so the external
-code would likely have to change if it was modifying `list` directly.
-
-If encapsulation is a required aspect for a language to be considered object
-oriented, then Rust meets that requirement. The option to use `pub` or not for
-different parts of code enables encapsulation of implementation details.
-
-### Inheritance as a Type System and as Code Sharing
-
-*Inheritance* is a mechanism whereby an object can inherit from another
-object’s definition, thus gaining the parent object’s data and behavior without
-you having to define them again.
-
-If a language must have inheritance to be an object-oriented language, then
-Rust is not. There is no way to define a struct that inherits the parent
-struct’s fields and method implementations. However, if you’re used to having
-inheritance in your programming toolbox, you can use other solutions in Rust
-depending on your reason for reaching for inheritance in the first place.
-
-You choose inheritance for two main reasons. One is for reuse of code: you can
-implement particular behavior for one type, and inheritance enables you to
-reuse that implementation for a different type. You can share Rust code using
-default trait method implementations instead, which you saw in Listing 10-14
-when we added a default implementation of the `summarize` method on the
-`Summary` trait. Any type implementing the `Summary` trait would have the
-`summarize` method available on it without any further code. This is similar to
-a parent class having an implementation of a method and an inheriting child
-class also having the implementation of the method. We can also override the
-default implementation of the `summarize` method when we implement the
-`Summary` trait, which is similar to a child class overriding the
-implementation of a method inherited from a parent class.
-
-The other reason to use inheritance relates to the type system: to enable a
-child type to be used in the same places as the parent type. This is also
-called *polymorphism*, which means that you can substitute multiple objects for
-each other at runtime if they share certain characteristics.
-
-> ### Polymorphism
->
-> To many people, polymorphism is synonymous with inheritance. But it’s
-> actually a more general concept that refers to code that can work with data
-> of multiple types. For inheritance, those types are generally subclasses.
->
-> Rust instead uses generics to abstract over different possible types and
-> trait bounds to impose constraints on what those types must provide. This is
-> sometimes called *bounded parametric polymorphism*.
-
-Inheritance has recently fallen out of favor as a programming design solution
-in many programming languages because it’s often at risk of sharing more code
-than needs be. Subclasses shouldn’t always share all characteristics of their
-parent class but will do so with inheritance. This can make a program’s design
-less flexible and introduces the possibility of calling methods on subclasses
-that don’t make sense or that cause errors because the methods don’t apply to
-the subclass. Some languages will also only allow a subclass to inherit from
-one class, further restricting the flexibility of a program’s design.
-
-For these reasons, Rust takes a different approach, using trait objects instead
-of inheritance. Let’s look at how trait objects enable polymorphism in Rust.
-
-## Using Trait Objects that Allow for Values of Different Types
-
-In Chapter 8, we mentioned that one limitation of vectors is that they can only
-store elements of one type. We created a workaround in Listing 8-10 where we
-defined a `SpreadsheetCell` enum that had variants to hold integers, floats,
-and text. This meant we could store different types of data in each cell and
-still have a vector that represented a row of cells. This is a perfectly good
-solution when our interchangeable items are a fixed set of types that we know
-when our code is compiled.
-
-However, sometimes we want our library user to be able to extend the set of
-types that are valid in a particular situation. To show how we might achieve
-this, we’ll create an example graphical user interface (GUI) tool that iterates
-through a list of items, calling a `draw` method on each one to draw it to the
-screen—a common technique for GUI tools. We’ll create a library crate called
-`gui` that contains the structure of a GUI library. This crate might include
-some types for people to use, such as `Button` or `TextField`. In addition,
-`gui` users will want to create their own types that can be drawn: for
-instance, one programmer might add an `Image` and another might add a
-`SelectBox`.
-
-We won’t implement a fully fledged GUI library for this example but will show
-how the pieces would fit together. At the time of writing the library, we can’t
-know and define all the types other programmers might want to create. But we do
-know that `gui` needs to keep track of many values of different types, and it
-needs to call a `draw` method on each of these differently typed values. It
-doesn’t need to know exactly what will happen when we call the `draw` method,
-just that the value will have that method available for us to call.
-
-To do this in a language with inheritance, we might define a class named
-`Component` that has a method named `draw` on it. The other classes, such as
-`Button`, `Image`, and `SelectBox`, would inherit from `Component` and thus
-inherit the `draw` method. They could each override the `draw` method to define
-their custom behavior, but the framework could treat all of the types as if
-they were `Component` instances and call `draw` on them. But because Rust
-doesn’t have inheritance, we need another way to structure the `gui` library to
-allow users to extend it with new types.
-
-### Defining a Trait for Common Behavior
-
-To implement the behavior we want `gui` to have, we’ll define a trait named
-`Draw` that will have one method named `draw`. Then we can define a vector that
-takes a *trait object*. A trait object points to an instance of a type that
-implements the trait we specify. We create a trait object by specifying some
-sort of pointer, such as a `&` reference or a `Box` smart pointer, and then
-specifying the relevant trait (we’ll talk about the reason trait objects must
-use a pointer in Chapter 19 in the section “Dynamically Sized Types & Sized”).
-We can use trait objects in place of a generic or concrete type. Wherever we
-use a trait object, Rust’s type system will ensure at compile time that any
-value used in that context will implement the trait object’s trait.
-Consequently, we don’t need to know all the possible types at compile time.
-
-We’ve mentioned that in Rust we refrain from calling structs and enums
-“objects” to distinguish them from other languages’ objects. In a struct or
-enum, the data in the struct fields and the behavior in `impl` blocks are
-separated, whereas in other languages the data and behavior combined into one
-concept is often labeled an object. However, trait objects *are* more like
-objects in other languages in the sense that they combine data and behavior.
-But trait objects differ from traditional objects in that we can’t add data to
-a trait object. Trait objects aren’t as generally useful as objects in other
-languages: their specific purpose is to allow abstraction across common
-behavior.
-
-Listing 17-3 shows how to define a trait named `Draw` with one method named
-`draw`:
-
-Filename: src/lib.rs
-
-```
-pub trait Draw {
-    fn draw(&self);
-}
-```
-
-Listing 17-3: Definition of the `Draw` trait
-
-This syntax should look familiar from our discussions on how to define traits
-in Chapter 10. Next comes some new syntax: Listing 17-4 defines a struct named
-`Screen` that holds a vector named `components`. This vector is of type
-`Box`, which is a trait object: it’s a stand-in for any type inside a
-`Box` that implements the `Draw` trait.
-
-Filename: src/lib.rs
-
-```
-pub struct Screen {
-    pub components: Vec>,
-}
-```
-
-Listing 17-4: Definition of the `Screen` struct with a `components` field
-holding a vector of trait objects that implement the `Draw` trait
-
-On the `Screen` struct, we’ll define a method named `run` that will call the
-`draw` method on each of its `components`, as shown in Listing 17-5:
-
-Filename: src/lib.rs
-
-```
-impl Screen {
-    pub fn run(&self) {
-        for component in self.components.iter() {
-            component.draw();
-        }
-    }
-}
-```
-
-Listing 17-5: Implementing a `run` method on `Screen` that calls the `draw`
-method on each component
-
-This works differently than defining a struct that uses a generic type
-parameter with trait bounds. A generic type parameter can only be substituted
-with one concrete type at a time, whereas trait objects allow for multiple
-concrete types to fill in for the trait object at runtime. For example, we
-could have defined the `Screen` struct using a generic type and a trait bound
-as in Listing 17-6:
-
-Filename: src/lib.rs
-
-```
-pub struct Screen {
-    pub components: Vec,
-}
-
-impl Screen
-    where T: Draw {
-    pub fn run(&self) {
-        for component in self.components.iter() {
-            component.draw();
-        }
-    }
-}
-```
-
-Listing 17-6: An alternate implementation of the `Screen` struct and its `run`
-method using generics and trait bounds
-
-This restricts us to a `Screen` instance that has a list of components all of
-type `Button` or all of type `TextField`. If you’ll only ever have homogeneous
-collections, using generics and trait bounds is preferable because the
-definitions will be monomorphized at compile time to use the concrete types.
-
-On the other hand, with the method using trait objects, one `Screen` instance
-can hold a `Vec` that contains a `Box