mirror of https://github.com/rust-lang/book
Propagate ch14 tech review changes to src
This commit is contained in:
parent
8c110c6234
commit
39f263f00c
|
@ -542,6 +542,7 @@ UnsafeCell
|
|||
unsafety
|
||||
unsized
|
||||
unsynchronized
|
||||
Unyank
|
||||
URIs
|
||||
UsefulType
|
||||
username
|
||||
|
|
|
@ -253,7 +253,9 @@ the `art` crate</span>
|
|||
|
||||
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.
|
||||
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
|
||||
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
|
||||
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
|
||||
$ 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
|
||||
|
@ -447,6 +453,8 @@ to start depending on a version again:
|
|||
|
||||
```console
|
||||
$ 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
|
||||
|
|
|
@ -24,11 +24,10 @@ $ 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. Instead, it will start
|
||||
with a `[workspace]` section that will allow us to add members to the workspace
|
||||
by specifying the path to the package with our binary crate; in this case,
|
||||
that path is *adder*:
|
||||
configure the entire workspace. This file won’t have a `[package]` section.
|
||||
Instead, it will start with a `[workspace]` section that will allow us to add
|
||||
members to the workspace by specifying the path to the package with our binary
|
||||
crate; in this case, that path is *adder*:
|
||||
|
||||
<span class="filename">Filename: Cargo.toml</span>
|
||||
|
||||
|
|
Loading…
Reference in New Issue