Merge pull request #1573 from Natramit/main

Fix some text issues.

assets/writing-material/style_guide/naming.md

@@ -227,4 +227,4 @@ std = []
 
 它们都使用了`谓语-宾语-错误`的词序，如果我们想要表达一个网络地址无法分析的错误，由于词序一致性的原则，命名应该如下`ParseAddrError`,而不是`AddrParseError`。
 
-词序和个人习惯有很大关系，想要注意的是，你可以选择合适的词序，但是要在包的范畴内保持一致性，就如标准库中的包一样。
+词序和个人习惯有很大关系，需要注意的是，你可以选择合适的词序，但是要在包的范畴内保持一致性，就如标准库中的包一样。

src/advance/concurrency-with-threads/sync1.md

@@ -204,7 +204,7 @@ Result: 10
 
 正因为这种困难性，导致很多用户都热衷于使用消息传递的方式来实现同步，例如 Go 语言直接把`channel`内置在语言特性中，甚至还有无锁的语言，例如`erlang`，完全使用`Actor`模型，依赖消息传递来完成共享和同步。幸好 Rust 的类型系统、所有权机制、智能指针等可以很好的帮助我们减轻使用锁时的负担。
 
-另一个值的注意的是在使用`Mutex<T>`时，Rust 无法帮我们避免所有的逻辑错误，例如在之前章节，我们提到过使用`Rc<T>`可能会导致[循环引用的问题](https://course.rs/advance/circle-self-ref/circle-reference.html)。类似的，`Mutex<T>`也存在使用上的风险，例如创建死锁(deadlock)：当一个操作试图锁住两个资源，然后两个线程各自获取其中一个锁，并试图获取另一个锁时，就会造成死锁。
+另一个值得注意的是在使用`Mutex<T>`时，Rust 无法帮我们避免所有的逻辑错误，例如在之前章节，我们提到过使用`Rc<T>`可能会导致[循环引用的问题](https://course.rs/advance/circle-self-ref/circle-reference.html)。类似的，`Mutex<T>`也存在使用上的风险，例如创建死锁(deadlock)：当一个操作试图锁住两个资源，然后两个线程各自获取其中一个锁，并试图获取另一个锁时，就会造成死锁。
 
 ## 死锁
 

src/advance/macro.md

@@ -1,6 +1,6 @@
 # Macro 宏编程
 
-在编程世界可以说是谈“宏”色变，原因在于 C 语言中的宏是非常危险的东东，但并不是所有语言都像 C 这样，例如对于古老的语言 Lisp 来说，宏就是就是一个非常强大的好帮手。
+在编程世界可以说是谈“宏”色变，原因在于 C 语言中的宏是非常危险的东东，但并不是所有语言都像 C 这样，例如对于古老的语言 Lisp 来说，宏就是一个非常强大的好帮手。
 
 那话说回来，在 Rust 中宏到底是好是坏呢？本章将带你揭开它的神秘面纱。
 

src/basic/lifetime.md

@@ -138,7 +138,7 @@ help: consider introducing a named lifetime parameter // 考虑引入一个生
 
 > 生命周期标注并不会改变任何引用的实际作用域 -- 鲁迅
 
-鲁迅说过的话，总是值得重点标注，当你未来更加理解生命周期时，你才会发现这句话的精髓和重要！现在先简单记住，**标记的生命周期只是为了取悦编译器，让编译器不要难为我们**，记住了吗？没记住，再回头看一遍，这对未来你遇到生命周期问题时会有很大的帮助！
+鲁迅说过的话，总是值得重点关注，当你未来更加理解生命周期时，你才会发现这句话的精髓和重要！现在先简单记住，**标记的生命周期只是为了取悦编译器，让编译器不要难为我们**，记住了吗？没记住，再回头看一遍，这对未来你遇到生命周期问题时会有很大的帮助！
 
 在很多时候编译器是很聪明的，但是总有些时候，它会化身大聪明，自以为什么都很懂，然后去拒绝我们代码的执行，此时，就需要我们通过生命周期标注来告诉这个大聪明：别自作聪明了，听我的就好。
 

src/cargo/guide/why-exist.md

@@ -27,9 +27,9 @@ Hello, world!
 
 总之，`Cargo` 为了实现目标，做了四件事：
 
-- 引入两个元数据文件，包含项目的方方面面信息: `Cargo.toml` 和 `Cargo.lock`
+- 引入两个元数据文件，包含项目方方面面的信息: `Cargo.toml` 和 `Cargo.lock`
 - 获取和构建项目的依赖，例如 `Cargo.toml` 中的依赖包版本描述，以及从 `crates.io` 下载包
-- 调用 `rustc` (或其它编译器) 并使用的正确的参数来构建项目，例如 `cargo build`
+- 调用 `rustc` (或其它编译器) 并使用正确的参数来构建项目，例如 `cargo build`
 - 引入一些惯例，让项目的使用更加简单
 
 毫不夸张的说，得益于 `Cargo` 的标准化，只要你使用它构建过一个项目，那构建其它使用 `Cargo` 的项目，也将不存在任何困难。

src/compiler/fight-with-compiler/lifetime/loop.md

@@ -68,7 +68,7 @@ error[E0499]: cannot borrow `arr[_]` as mutable more than once at a time
 2. `&mut arr[i]`报错，因为在上一次循环中，已经借用过同样的可变引用`&mut arr[i]`
 3. `tile`的生命周期跟`arr`不一致
 
-奇了怪了，跟我们之前的分析完全背道而驰，按理来说`arr.len()`的借用应该在调用后立刻结束，而不是持续到后面的代码行；同时可变借用`&mut arr[i]`也应该随着每次循环的结束而结束，为什么会前后两次循环会因为同一处的引用而报错？
+奇了怪了，跟我们之前的分析完全背道而驰，按理来说`arr.len()`的借用应该在调用后立刻结束，而不是持续到后面的代码行；同时可变借用`&mut arr[i]`也应该随着每次循环的结束而结束，为什么前后两次循环会因为同一处的引用而报错？
 
 ## 尝试去掉中间变量
 

src/logs/about-log.md

@@ -30,7 +30,7 @@
 #### 输出位置
 通常来说，日志可以输出两个地方：终端控制台和文件。对于前者，我们还有一个称呼标准输出，例如使用 `println!` 打印到终端的信息就是输出到标准输出中。
 
-如果没有日志持久化的需求，你只是为了调试程序，建议输出到控制台即可。悄悄的说一句，我们还可以为不同的级别设定不同的输出位置，例如 `Debug` 日志输出到控制台，既方便开发查看，但又不会占用硬盘，而 `Info` 和 `Warning` 日志可以输出到文件 `info.log` 中，至于 `Error`、`Fatal` 则可以输出到 `error.log` 中。
+如果没有日志持久化的需求，你只是为了调试程序，建议输出到控制台即可。悄悄的说一句，我们还可以为不同的级别设定不同的输出位置，例如 `Debug` 日志输出到控制台，既方便开发查看，又不会占用硬盘，而 `Info` 和 `Warning` 日志可以输出到文件 `info.log` 中，至于 `Error`、`Fatal` 则可以输出到 `error.log` 中。
 
 但是如果大家以为只有输出到文件才能持久化日志，那你就错了，在后面的日志采集我们会详细介绍，先来看看日志查看。
 

src/too-many-lists/bad-stack/final-code.md

@@ -171,7 +171,7 @@ test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured
 <details>
   <summary>点击这里展开答案</summary>
 
-`self.pop()` 的会返回 `Option<i32>`, 而我们之前的实现仅仅对智能指针 `Box<Node>` 进行操作。前者会对值进行拷贝，而后者仅仅使用的是指针类型。
+`self.pop()` 会返回 `Option<i32>`, 而我们之前的实现仅仅对智能指针 `Box<Node>` 进行操作。前者会对值进行拷贝，而后者仅仅使用的是指针类型。
 
 当链表中包含的值是其他较大的类型时，那这个拷贝的开销将变得非常高昂。
 </details>

src/too-many-lists/do-we-need-it.md

@@ -22,7 +22,7 @@ $ cargo new --lib lists
 $ cd lists
 ```
 
-之后，我们会将每个一个链表放入单独的文件中，需要注意的是我们会尽量模拟真实的 Rust 开发场景：你写了一段代码，然后编译器开始跳出试图教你做事，只有这样才能真正学会 Rust，温室环境是无法培养出强大的 Rustacean 的。
+之后，我们会将每一个链表放入单独的文件中，需要注意的是我们会尽量模拟真实的 Rust 开发场景：你写了一段代码，然后编译器开始跳出试图教你做事，只有这样才能真正学会 Rust，温室环境是无法培养出强大的 Rustacean 的。
 
 #### 义务告知
 首先，本书不是保姆式教程，而且我个人认为编程应该是快乐，这种快乐往往需要你自己发现而不是别人的事无巨细的讲解。