Merge pull request #3474 from xzmeng/fix-typos

Fix typos

text/0446-es6-unicode-escapes.md

@@ -77,7 +77,7 @@ Stage 2).
 * Status quo: don’t change the escaping syntax.
 * Add the new `\u{…}` syntax, but also keep the existing `\u` and `\U` syntax.
   This is what ES 6 does, but only to keep compatibility with ES 5.
-  We don’t have that constaint pre-1.0.
+  We don’t have that constraint pre-1.0.
 
 # Unresolved questions
 

text/0501-consistent_no_prelude_attributes.md

@@ -75,4 +75,4 @@ Finally, the old attribute name should emit a deprecated warning, and be removed
  - Keep the current behavior
  - Remove the `#[no_implicit_prelude]` attribute all together, instead forcing users to use
    `#[no_std]` in combination with `extern crate std;` and `use std::prelude::*`.
- - Generalize preludes more to allow custom ones, which might superseed the attributes from this RFC.
+ - Generalize preludes more to allow custom ones, which might supersede the attributes from this RFC.

text/1122-language-semver.md

@@ -181,7 +181,7 @@ Known areas where change is expected include the following:
 
 - Destructors semantics:
   - We plan to stop zeroing data and instead use marker flags on the stack,
-    as specified in [RFC 320]. This may affect destructors that rely on ovewriting
+    as specified in [RFC 320]. This may affect destructors that rely on overwriting
     memory or using the `unsafe_no_drop_flag` attribute.
   - Currently, panicking in a destructor can cause unintentional memory
     leaks and other poor behavior (see [#14875], [#16135]). We are

text/1574-more-api-documentation-conventions.md

@@ -192,7 +192,7 @@ pub mod option;
 /// assert_eq!(&[5], slice);
 /// ```
 ///
-/// A more compelx example. In this case, it’s the same example, because this
+/// A more complex example. In this case, it’s the same example, because this
 /// is a pretty trivial function, but use your imagination.
 ///
 /// ```

text/1717-dllimport.md

@@ -109,7 +109,7 @@ meaning that it will be common that these attributes are left off by accident.
 - Instead of enhancing `#[link]`, a `#[linked_from = "foo"]` annotation could be added.
   This has the drawback of not being able to handle native libraries whose
   name is unpredictable across platforms in an easy fashion, however.
-  Additionally, it adds an extra attribute to the comipler that wasn't known
+  Additionally, it adds an extra attribute to the compiler that wasn't known
   previously.
 
 - Support a `#[dllimport]` on extern blocks (or individual symbols, or both).

text/1733-trait-alias.md

@@ -362,7 +362,7 @@ using the `trait` keyword to define alias on *lifetimes* seems a wrong design ch
 very consistent.
 
 If we chose another keyword, like `constraint`, I feel less concerned and it would open further
-opportunies – see the `ConstraintKinds` alternative discussion above.
+opportunities – see the `ConstraintKinds` alternative discussion above.
 
 ## Which bounds need to be repeated when using a trait alias?
 

text/2126-path-clarity.md

@@ -637,7 +637,7 @@ And in addition there's been extensive discussion on internals:
 
 - [Revisiting Rust’s modules](https://internals.rust-lang.org/t/revisiting-rusts-modules/5628) - aturon, Jul 26
 - [Revisiting Rust’s modules, part 2](https://internals.rust-lang.org/t/revisiting-rust-s-modules-part-2/5700?u=carols10cents) - aturon, Aug 2
-- [Revisting Modules, take 3](https://internals.rust-lang.org/t/revisiting-modules-take-3/5715?u=carols10cents) - withoutboats, Aug 4
+- [Revisiting Modules, take 3](https://internals.rust-lang.org/t/revisiting-modules-take-3/5715?u=carols10cents) - withoutboats, Aug 4
 - [pre-RFC: inline mod](https://internals.rust-lang.org/t/pre-rfc-inline-mod/5716?u=carols10cents) - ahmedcharles, Aug 4
 - [My Preferred Module System (a fusion of earlier proposals)](https://internals.rust-lang.org/t/my-preferred-module-system-a-fusion-of-earlier-proposals/5718?u=carols10cents) - phaylon, Aug 5
 - [[Pre-RFC] Yet another take on modules](https://internals.rust-lang.org/t/pre-rfc-yet-another-take-on-modules/5717?u=carols10cents) - newpavlov, Aug 5

text/2906-cargo-workspace-deduplicate.md

@@ -447,7 +447,7 @@ implicit substitutions, if any, will be invisible to users of `cargo metadata`.
 ## Effect on `cargo read-manifest`
 
 Similar to `cargo metadata`, the `cargo read-manifest` command will perform all
-necessary subsitutions when presenting the output as JSON.
+necessary substitutions when presenting the output as JSON.
 
 ## Effect resolution for relative `path` dependencies
 

text/2912-rust-analyzer.md

@@ -156,7 +156,7 @@ However, there are a number of practical concerns with taking that approach. One
 
 Further, the "reimplement" approach would represent a constraint on the ordering in which we do our work. With the design proposed in this RFC, for example, rust-analyzer is able to make use of the chalk library already. This is only possible because rust-analyzer has a "stub" version of Rust's name resolution engine and type checker embedded in it -- this type checker is not perfect, but it's good enough to drive chalk and gain useful experience. This allows us to create an end-to-end IDE user experience sooner, in effect.
 
-In contrast, if we were to try and rebuild rust-analyzer within rustc, even if we had rustc adopt chalk or some other IDE-friendly trait resolution algorithm, that would not be of use to IDE users until we had also upgraded the name resolution algorithm and type checker to be IDE friendly. In short, having a "prototype" version of these algorithms that lives in rust-anaylzer is both a pro and a con: it means we have to maintain two versions, but it means users get benefits faster and developers can experiment more freely.
+In contrast, if we were to try and rebuild rust-analyzer within rustc, even if we had rustc adopt chalk or some other IDE-friendly trait resolution algorithm, that would not be of use to IDE users until we had also upgraded the name resolution algorithm and type checker to be IDE friendly. In short, having a "prototype" version of these algorithms that lives in rust-analyzer is both a pro and a con: it means we have to maintain two versions, but it means users get benefits faster and developers can experiment more freely.
 
 ## Require feature parity between the existing RLS and rust-analyzer
 

text/3013-conditional-compilation-checking.md

@@ -13,7 +13,7 @@ the risks is that a condition may contain misspelled identifiers, or may use ide
 obsolete or have been removed from a product. For example:
 
 ```rust
-#[cfg(feature = "widnows")]
+#[cfg(feature = "windows")]
 fn do_windows_thing() { /* ... */ }
 ```
 

text/3308-offset_of.md

@@ -127,7 +127,7 @@ As you can see, the usage is the same as before, but because we didn't specify
 `#[repr(C)]`, compiler may have changed the order or position, so the values may
 be different -- it's completely possible that `pos` is located at offset 0, for
 example! Thankfully, by using `core::mem::offset_of!`, this code is correct
-either way, and will continute to be correct, even if the layout algorithm
+either way, and will continue to be correct, even if the layout algorithm
 changes in the future.
 
 ## `offset_of!` On Other Types

text/3324-dyn-upcasting.md

@@ -283,7 +283,7 @@ The primary downside of this RFC is that it requires larger vtables, which can b
 Looking forward, there are at least two potential ways we could address this problem:
 
 * Optimization to remove unused parts of vtables: When generating a final binary artifact, we could likely reduce the size of vtables overall by analyzing which methods are invoked and which upcast slots are used. Unused slots could be made NULL, which may enable additional dead code elimination as well. This would require some rearchitecture in the compiler, since LTO currently executes at the LLVM level, and this sort of analysis would be much easier to do at the MIR level; no language changes are required, however.
-* Target options to disable upcasting or other "space hogs": We could extend compilation profiles to allow targets to disable upcasting, either always or for select traits. This would lead to a compilation error if crates used upcasting, but permit generating smaller binaries (naturally, all crates being compiled would have to be compiled with the same target opions).
+* Target options to disable upcasting or other "space hogs": We could extend compilation profiles to allow targets to disable upcasting, either always or for select traits. This would lead to a compilation error if crates used upcasting, but permit generating smaller binaries (naturally, all crates being compiled would have to be compiled with the same target options).
 
 Another option, though one that this RFC recommends against, would be to add a new form of `dyn` that does not support upcasting (e.g., `dyn =Trait` or some such). This would allow individual values to "opt out" from upcasting.
 

text/3327-lang-team-advisors.md

@@ -25,7 +25,7 @@ Lang team advisors can be useful in a number of situations:
 
 * Someone who is offered membership, but declines because they don't have time to attend meetings and the like, may find the advisors team a better fit, helping to keep them engaged in the Rust project (and to recognize their contributions).
 * Advisors is a great fit for domain experts who are consulted regularly on particular topics, but who are not interested in all aspects of Rust language design.
-* Advisors can also serve as a stepping stone to full membership: this gives the team a chance to recognize someone who is participating actively before commiting to full membership.
+* Advisors can also serve as a stepping stone to full membership: this gives the team a chance to recognize someone who is participating actively before committing to full membership.
 
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
@@ -63,7 +63,7 @@ An advisor may be removed at their request, or if the team feels they've been in
 
 ## Integration into the decision process
 
-There will be a team in the rust repo (`rust-lang/lang-team-advisors`). When a lang team FCP is initiated, we will cc this team, making them aware it is happening. Advisors will be able to raise blocking objections with the "concern" functonality of rfcbot, or equivalent functionality in future decision tooling. (As an interim measure until rfcbot includes this functionality, team members may raise concerns on behalf of advisors on request.)
+There will be a team in the rust repo (`rust-lang/lang-team-advisors`). When a lang team FCP is initiated, we will cc this team, making them aware it is happening. Advisors will be able to raise blocking objections with the "concern" functionality of rfcbot, or equivalent functionality in future decision tooling. (As an interim measure until rfcbot includes this functionality, team members may raise concerns on behalf of advisors on request.)
 
 The precise details of how advisors fit into the lang team [decision making process](https://lang-team.rust-lang.org/decision_process/reference.html) are as follows:
 

text/3346-t-opsem.md

@@ -70,9 +70,9 @@ When considering someone for membership, the qualifications below will all be ta
     - Do they "steelman", looking for ways to restate others' points in the most convincing way?
  - Is this person **active**?
     - Are they attending meetings regularly?
-    - Either in meeting or elsewhere, do they comment on disussions and otherwise?
+    - Either in meeting or elsewhere, do they comment on discussions and otherwise?
 
-The last four bullets are lighlty edited versions of a subset of the [T-lang membership qualifications][lang-qualifications].
+The last four bullets are lightly edited versions of a subset of the [T-lang membership qualifications][lang-qualifications].
 
 [lang-qualifications]: https://lang-team.rust-lang.org/membership.html
 

text/3348-c-str-literal.md

@@ -58,7 +58,7 @@ Interactions with string related macros:
   The trivial implementation of using `concat!($s, "\0")` is problematic for several reasons, including non-string input and embedded nul bytes.
   (The unstable `concat_bytes!()` solves some of the problems.)
 
-  The popular [`cstr` crate](https://crates.io/crates/cstr) is a proc macro to work around the limiations of a `macro_rules` implementation, but that also has many downsides.
+  The popular [`cstr` crate](https://crates.io/crates/cstr) is a proc macro to work around the limitations of a `macro_rules` implementation, but that also has many downsides.
 
   Even if we had the right language features for a trivial correct implementation, there are many code bases where C strings are the primary form of string,
   making `cstr!("..")` syntax quite cumbersome.

text/3391-result_ffi_guarantees.md

@@ -80,7 +80,7 @@ It's always possible to *not* strengthen the guarantees of the language.
 # Prior art
 [prior-art]: #prior-art
 
-The compiler already suports `Option` being combined with specific non-zero types, this RFC mostly expands the list of guaranteed support.
+The compiler already supports `Option` being combined with specific non-zero types, this RFC mostly expands the list of guaranteed support.
 
 # Unresolved questions
 [unresolved-questions]: #unresolved-questions

text/3424-cargo-script.md

@@ -400,7 +400,7 @@ Existing Rust solutions:
   - `--loop <expr>` for a closure to run on each line
   - `--test`, etc flags to make up for cargo not understanding thesefiles
   - `--force` to rebuild` and `--clear-cache`
-  - Communicates through scrpts through some env variables
+  - Communicates through scripts through some env variables
 - [`cargo-scripter`](https://crates.io/crates/cargo-scripter)
   - See above with 8 more commits
 - [`cargo-eval`](https://crates.io/crates/cargo-eval)