diff --git a/text/0048-traits.md b/text/0048-traits.md index 80725f77aba..ae0ca2aca2f 100644 --- a/text/0048-traits.md +++ b/text/0048-traits.md @@ -26,7 +26,7 @@ put onto a surer footing. ## Use cases -### Poor interaction with overloadable deref and index +### Poor interaction with overloadable deref and index { #overload } *Addressed by:* New method resolution algorithm. @@ -66,7 +66,7 @@ manually specified by making the receiver type fully explicit: `(&mut address this problem, as well as the question of how to handle copies and moves of the referent (use #3 in my list above). -### Lack of backtracking +### Lack of backtracking { #backtrack } *Addressed by:* New method resolution algorithm. @@ -190,7 +190,7 @@ property. And the popularity and usefulness of blanket impls cannot be denied. Therefore, I think this property ("always being able to add impls") is not especially useful or important. -### Hokey implementation +### Hokey implementation { #hokey } *Addressed by:* Gradual vtable resolution algorithm @@ -298,7 +298,7 @@ personal preference, if we can achieve it). The coherence rules fall into two categories: the *orphan* restriction and the *overlapping implementations* restriction. - + *Orphan check*: Every implementation must meet one of the following conditions: @@ -679,9 +679,9 @@ probably an error. DEFERRED obligations are ok until we reach the end of the function. For details, please refer to the [prototype][prototype]. -# Alternatives and downsides +# Alternatives and downsides { #alternatives } -## Autoderef and ambiguity +## Autoderef and ambiguity { #ambig } The addition of a `Deref` trait makes autoderef complicated, because we may encounter situations where the smart pointer *and* its @@ -707,20 +707,20 @@ needs to be evaluated. # Footnotes - + **Note 1:** when combining with DST, the `in` keyword goes first, and then any other qualifiers. For example, `in unsized RHS` or `in type RHS` etc. (The precise qualifier in use will depend on the DST proposal.) - + **Note 2:** Note that the `DerefMut` trait extends `Deref`, so if a type supports mutable derefs, it must also support immutable derefs. - + **Note 3:** The restriction that inputs must precede outputs is not strictly necessary. I added it to keep options open concerning @@ -728,25 +728,25 @@ associated types and so forth. See the [Alternatives section](#alternatives), specifically the section on [associated types](#assoc). - + **Note 4:** The prioritization of inherent methods could be reconsidered after DST has been implemented. It is currently needed to make impls like `impl Trait for ~Trait` work. - + **Note 5:** The set of in-scope traits is currently defined as those that are imported by name. PR #37 proposes possible changes to this rule. - + **Note 6:** In the section on [autoderef and ambiguity](#ambig), I discuss alternate rules that might allow us to lift the requirement that the receiver be named `self`. - + **Note 7:** I am considering introducing mechanisms in a subsequent RFC that could be used to express mutual exclusion of traits. diff --git a/text/0116-no-module-shadowing.md b/text/0116-no-module-shadowing.md index 2cba84d175f..3be88db09cf 100644 --- a/text/0116-no-module-shadowing.md +++ b/text/0116-no-module-shadowing.md @@ -181,11 +181,11 @@ released. Right now its legal to write this: ```rust -fn main() { + fn main() { use Bar = std::result::Result; use Bar = std::option::Option; let x: Bar = None; -} + } ``` where the latter `use` shadows the former. This would have to be forbidden as well, however the current semantic seems like a accident anyway. diff --git a/text/0256-remove-refcounting-gc-of-t.md b/text/0256-remove-refcounting-gc-of-t.md index 1145022ca58..27685a16490 100644 --- a/text/0256-remove-refcounting-gc-of-t.md +++ b/text/0256-remove-refcounting-gc-of-t.md @@ -47,7 +47,7 @@ still in place; the move to a library type `Gc` was just a shift in perspective from the end-user's point of view (and that of the parser). -## Recent history: Removing uses of Gc from the compiler +## Recent history: Removing uses of `Gc` from the compiler Largely due to the tireless efforts of `eddyb`, one of the primary clients of `Gc`, namely the `rustc` compiler itself, has little to diff --git a/text/0736-privacy-respecting-fru.md b/text/0736-privacy-respecting-fru.md index f79f0bd6581..6ca14868db2 100644 --- a/text/0736-privacy-respecting-fru.md +++ b/text/0736-privacy-respecting-fru.md @@ -309,7 +309,7 @@ Here is an attempt to transcribe/summarize them: This seems pretty fragile; i.e., easy to forget. - 6. Outlaw the trivial FRU form Foo { .. }. That is, to use + 6. Outlaw the trivial FRU form `Foo { .. }`. That is, to use FRU, you have to use at least one field in the constructing expression. Again, this implies that types like Vec and HashMap will not be subject to the vulnerability outlined here. diff --git a/text/0738-variance.md b/text/0738-variance.md index a9c6865872a..ec00be8870f 100644 --- a/text/0738-variance.md +++ b/text/0738-variance.md @@ -348,8 +348,7 @@ contravariant. **Why contravariance?** To see why contravariance is correct, you have to consider what it means for `Self` to be contravariant for a marker trait. It means that if I have evidence that `T : Copy`, then I can -use that as evidence to show that `U -: Copy` if `U <: T`. More formally: +use that as evidence to show that `U : Copy` if `U <: T`. More formally: (T : Copy) <: (U : Copy) // I can use `T:Copy` where `U:Copy` is expected... U <: T // ...so long as `U <: T` diff --git a/text/0771-std-iter-once.md b/text/0771-std-iter-once.md index b7386b39f30..cdd62c4c156 100644 --- a/text/0771-std-iter-once.md +++ b/text/0771-std-iter-once.md @@ -12,7 +12,7 @@ This is a common task when working with iterators. Currently, this can be done i # Detailed design -`once` will return a new struct, `std::iter::Once`, implementing Iterator. Internally, `Once` is simply a newtype wrapper around `std::option::IntoIter`. The actual body of `once` is thus trivial: +`once` will return a new struct, `std::iter::Once`, implementing `Iterator`. Internally, `Once` is simply a newtype wrapper around `std::option::IntoIter`. The actual body of `once` is thus trivial: ```rust pub struct Once(std::option::IntoIter); diff --git a/text/1228-placement-left-arrow.md b/text/1228-placement-left-arrow.md index 347701a28de..d483e184a48 100644 --- a/text/1228-placement-left-arrow.md +++ b/text/1228-placement-left-arrow.md @@ -59,10 +59,10 @@ applied to the original `in (PLACE_EXPR) VALUE_EXPR` syntax): * [p1start](https://github.com/rust-lang/rfcs/pull/809#issuecomment-73837430) - > I’m not a fan of in { }, simply because the + > I’m not a fan of `in { }`, simply because the > requirement of a block suggests that it’s some kind of control > flow structure, or that all the statements inside will be - > somehow run ‘in’ the given (or perhaps, as @m13253 + > somehow run ‘in’ the given `` (or perhaps, as @m13253 > seems to have interpreted it, for all box expressions to go > into the given place). It would be our first syntactical > construct which is basically just an operator that has to diff --git a/text/1298-incremental-compilation.md b/text/1298-incremental-compilation.md index a7b8fcbf298..7bf1c4ad2f0 100644 --- a/text/1298-incremental-compilation.md +++ b/text/1298-incremental-compilation.md @@ -247,7 +247,7 @@ I've uncovered a few fishy cases where we using the node id from external crates to index into the local crate's HIR map, which is certainly incorrect. --nmatsakis - + ## Identifying and tracking dependencies ### Core idea: a fine-grained dependency graph diff --git a/text/1398-kinds-of-allocators.md b/text/1398-kinds-of-allocators.md index a303d0e4fb2..a636839cced 100644 --- a/text/1398-kinds-of-allocators.md +++ b/text/1398-kinds-of-allocators.md @@ -166,10 +166,10 @@ So, an interaction between a program, a collection library, and an allocator might look like this: + If you cannot see the SVG linked here, try the [ASCII art version][ascii-art] appendix. Also, if you have suggestions for changes to the SVG, feel free to write them as a comment in that appendix; (but be sure to be clear that you are pointing out a suggestion for the SVG). - In general, an allocator might be the backing memory pool itself; or an allocator might merely be a *handle* that references the memory diff --git a/text/1644-default-and-expanded-rustc-errors.md b/text/1644-default-and-expanded-rustc-errors.md index ba8da51a49a..1ba2196bb39 100644 --- a/text/1644-default-and-expanded-rustc-errors.md +++ b/text/1644-default-and-expanded-rustc-errors.md @@ -251,8 +251,8 @@ subsequent style RFC. ## Expanded error messages -Currently, --explain text focuses on the error code. You invoke the compiler with --explain - and receive a verbose description of what causes errors of that number. The resulting +Currently, --explain text focuses on the error code. You invoke the compiler with `--explain +` and receive a verbose description of what causes errors of that number. The resulting message can be helpful, but it uses generic sample code which makes it feel less connected to the user's code. diff --git a/text/2025-nested-method-calls.md b/text/2025-nested-method-calls.md index 8a6a29756e1..0d6efafa574 100644 --- a/text/2025-nested-method-calls.md +++ b/text/2025-nested-method-calls.md @@ -50,7 +50,7 @@ directions. See the Alternatives section for more details. ## Why do we get an error in the first place? You may wonder why this code isn't accepted in the first place. To see -why, consider what the (somewhat simplified) resulting MIR looks like: +why, consider what the (somewhat simplified[^simp]) resulting MIR looks like: [^simp]: This MIR is mildly simplified; the real MIR has multiple basic blocks to account for the possibility of panics. diff --git a/text/2457-non-ascii-idents.md b/text/2457-non-ascii-idents.md index 770f9b2f62e..5590b5d334d 100644 --- a/text/2457-non-ascii-idents.md +++ b/text/2457-non-ascii-idents.md @@ -65,7 +65,7 @@ Note: The supported Unicode version should be stated in the documentation. The lexer defines identifiers as: -> **Lexer:** +> **Lexer:** > IDENTIFIER_OR_KEYWORD: >    XID_Start XID_Continue\* >    | `_` XID_Continue* diff --git a/text/3502-cargo-script.md b/text/3502-cargo-script.md index 55736f7f144..02c66422a5f 100644 --- a/text/3502-cargo-script.md +++ b/text/3502-cargo-script.md @@ -334,7 +334,7 @@ Inferred / defaulted manifest fields: manifest at the cost of potentially breaking scripts on rust upgrades - Warn when `edition` is unspecified. Since piped commands are run with `--quiet`, this may not show up. - Based on feedback, we might add `cargo-` proxies to put in `#!` as a shorthand - - Based on feedback, we can switch to "edition is required as of edition" + - Based on feedback, we can switch to "edition is required as of <future> edition" Note: As of [rust-lang/cargo#123](https://github.com/rust-lang/cargo/pull/12786), when `package.version` is missing, diff --git a/text/3537-msrv-resolver.md b/text/3537-msrv-resolver.md index d11d9d49880..8e5699d2c61 100644 --- a/text/3537-msrv-resolver.md +++ b/text/3537-msrv-resolver.md @@ -31,7 +31,7 @@ likely only needing to follow the FCP process. ## Status Quo -
Ensuring you have a `Cargo.lock` with dependencies compatible with your minimum-supported Rust version (MSRV) is an arduous task of running `cargo update --precise ` until it works. +
Ensuring you have a Cargo.lock with dependencies compatible with your minimum-supported Rust version (MSRV) is an arduous task of running cargo update <dep> --precise <ver> until it works Let's step through a simple scenario where a user develops with the latest Rust version but production uses an older version: diff --git a/text/3662-mergeable-rustdoc-cross-crate-info.md b/text/3662-mergeable-rustdoc-cross-crate-info.md index 37b604701da..022a15a75ee 100644 --- a/text/3662-mergeable-rustdoc-cross-crate-info.md +++ b/text/3662-mergeable-rustdoc-cross-crate-info.md @@ -135,7 +135,7 @@ $ tree . -a │ ├── static.files │ │ ├── COPYRIGHT-23e9bde6c69aea69.txt │ │ ├── favicon-2c020d218678b618.svg -│ │ └── +│ │ └── <rest of the contents excluded> │ ├── trait-crate │ │ ├── all.html │ │ ├── index.html