rust
/
book
mirror of https://github.com/rust-lang/book
1
0
Fork 0
Code Issues Releases Wiki Activity

Propagate ch14 tech review changes to src

This commit is contained in:
Carol (Nichols || Goulding) 2022-06-04 10:07:47 -04:00
parent 8c110c6234
commit 39f263f00c
No known key found for this signature in database
GPG Key ID: E907EE5A736F87D4
3 changed files with 15 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
ci/dictionary.txt
View File

@ -542,6 +542,7 @@ UnsafeCell
unsafety unsafety
unsized unsized
unsynchronized unsynchronized
Unyank
URIs URIs
UsefulType UsefulType
username username

12
src/ch14-02-publishing-to-crates-io.md
View File

@ -253,7 +253,9 @@ the `art` crate</span>
In cases where there are many nested modules, re-exporting the types at the top 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 level with `pub use` can make a significant difference in the experience of
people who use the crate. people who use the crate. Another common use of `pub use` is to re-export
definitions of a dependency in the current crate to make that crate's
definitions part of your crate’s public API.
Creating a useful public API structure is more of an art than a science, and 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 you can iterate to find the API that works best for your users. Choosing `pub
@ -436,10 +438,14 @@ yank means that all projects with a *Cargo.lock* will not break, and any future
To yank a version of a crate, in the directory of the crate that you’ve To yank a version of a crate, in the directory of the crate that you’ve
previously published, run `cargo yank` and specify which version you want to previously published, run `cargo yank` and specify which version you want to
yank: yank. For example, if we've published a crate named `guessing_game` version
1.0.1 and we want to yank it, in the project directory for `guessing_game` we'd
run:
```console ```console
$ cargo yank --vers 1.0.1 $ cargo yank --vers 1.0.1
Updating crates.io index
Yank guessing_game:1.0.1
``` ```
By adding `--undo` to the command, you can also undo a yank and allow projects By adding `--undo` to the command, you can also undo a yank and allow projects
@ -447,6 +453,8 @@ to start depending on a version again:
```console ```console
$ cargo yank --vers 1.0.1 --undo $ cargo yank --vers 1.0.1 --undo
Updating crates.io index
Unyank guessing_game_:1.0.1
``` ```
A yank *does not* delete any code. It cannot, for example, delete accidentally A yank *does not* delete any code. It cannot, for example, delete accidentally

9
src/ch14-03-cargo-workspaces.md
View File

@ -24,11 +24,10 @@ $ cd add
``` ```
Next, in the *add* directory, we create the *Cargo.toml* file that will 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 configure the entire workspace. This file won’t have a `[package]` section.
the metadata we’ve seen in other *Cargo.toml* files. Instead, it will start Instead, it will start with a `[workspace]` section that will allow us to add
with a `[workspace]` section that will allow us to add members to the workspace members to the workspace by specifying the path to the package with our binary
by specifying the path to the package with our binary crate; in this case, crate; in this case, that path is *adder*:
that path is *adder*:
<span class="filename">Filename: Cargo.toml</span> <span class="filename">Filename: Cargo.toml</span>