diff --git a/text/1298-incremental-compilation.md b/text/1298-incremental-compilation.md index 4ca31c9d..a7b8fcbf 100644 --- a/text/1298-incremental-compilation.md +++ b/text/1298-incremental-compilation.md @@ -149,7 +149,7 @@ saved. The effect of saving fewer things (such as only saving object code) will simply be to make incremental compilation somewhat less effective, since we will be forced to re-type-check and re-trans functions where we might have gotten away with only generating new -object code. However, this is expected to be be a second order effect +object code. However, this is expected to be a second order effect overall, particularly since LLVM optimization time can be a very large portion of compilation. diff --git a/text/1398-kinds-of-allocators.md b/text/1398-kinds-of-allocators.md index fdc9ffef..a303d0e4 100644 --- a/text/1398-kinds-of-allocators.md +++ b/text/1398-kinds-of-allocators.md @@ -917,7 +917,7 @@ comes, it may come with a new trait (call it `GcAwareAllocator`). option we choose can be incorporated into the meta-data for a crate.) -Allocators that are are GC-compatible have to explicitly declare +Allocators that are GC-compatible have to explicitly declare themselves as such, by implementing `GcAwareAllocator`, which will then impose new conditions on the methods of `Allocator`, for example ensuring e.g. that allocated blocks of memory can be scanned diff --git a/text/2091-inline-semantic.md b/text/2091-inline-semantic.md index dc51623c..8bff3c99 100644 --- a/text/2091-inline-semantic.md +++ b/text/2091-inline-semantic.md @@ -330,7 +330,7 @@ information in such a strange way. There are two restrictions that force us to a solution for systems languages like Rust because optimization often collapses multiple levels of function calls. In some embedded systems, the backtrace may even be unavailable! -2. Solutions that use default function arguments alongside normal arguments are are often used in +2. Solutions that use default function arguments alongside normal arguments are often used in languages that do not perform inference higher than statement level, e.g. Swift and C#. Rust does not (yet) support default function arguments or function overloading because they interfere with type inference, so such solutions are ruled out. diff --git a/text/2203-const-repeat-expr.md b/text/2203-const-repeat-expr.md index 3adde66e..76714087 100644 --- a/text/2203-const-repeat-expr.md +++ b/text/2203-const-repeat-expr.md @@ -175,7 +175,7 @@ argues that the change is quite intuitive. The alternative, in addition to simply not doing this, is to modify a host of other constructs such as [`mem::uninitialized()`], for loops over iterators, -[`ptr::write`] to be `const`, which is is a larger change. The design offered by +[`ptr::write`] to be `const`, which is a larger change. The design offered by this RFC is therefore the simplest and most non-intrusive design. It is also the most consistent. diff --git a/text/2585-unsafe-block-in-unsafe-fn.md b/text/2585-unsafe-block-in-unsafe-fn.md index ca2ddbbd..f292dc95 100644 --- a/text/2585-unsafe-block-in-unsafe-fn.md +++ b/text/2585-unsafe-block-in-unsafe-fn.md @@ -164,7 +164,7 @@ fn` for functions that are "unsafe to call" but do not implicitly have an trait` for traits, though the behavior would be the same as `unsafe trait`. We could introduce named proof obligations (proposed by @Centril) such that the -compiler can be be told (to some extend) if the assumptions made by the `unsafe +compiler can be told (to some extend) if the assumptions made by the `unsafe fn` are sufficient to discharge the requirements of the unsafe operations. We could restrict this requirement to use `unsafe` blocks in `unsafe fn` to diff --git a/text/2603-rust-symbol-name-mangling-v0.md b/text/2603-rust-symbol-name-mangling-v0.md index 5e23add4..1e8e6562 100644 --- a/text/2603-rust-symbol-name-mangling-v0.md +++ b/text/2603-rust-symbol-name-mangling-v0.md @@ -348,7 +348,7 @@ and `NCNvNtC7mycrate3foo3bars_0` respectively. Methods are nested within `impl` or `trait` items. As such it would be possible to construct their symbol names as paths like `my_crate::foo::{{impl}}::some_method` where `{{impl}}` somehow identifies -the the `impl` in question. Since `impl`s don't have names, we'd have to +the `impl` in question. Since `impl`s don't have names, we'd have to use an indexing scheme like the one used for closures (and indeed, this is what the compiler does internally). Adding in generic arguments to, this would lead to symbol names looking like diff --git a/text/3308-offset_of.md b/text/3308-offset_of.md index ed3836d2..460f7286 100644 --- a/text/3308-offset_of.md +++ b/text/3308-offset_of.md @@ -202,7 +202,7 @@ types: In this case, `$field` must share a name or tuple index with a field which: - Exists on `$Container`. - Is visible at the location where `offset_of!` is invoked (but there is no - requirement that fields other than than `$field` be visible there) + requirement that fields other than `$field` be visible there) 2. An anonymous tuple type. diff --git a/text/3535-constants-in-patterns.md b/text/3535-constants-in-patterns.md index 131a2d5b..1b3e1c5b 100644 --- a/text/3535-constants-in-patterns.md +++ b/text/3535-constants-in-patterns.md @@ -245,7 +245,7 @@ Some possible alternatives include: - **Reject pointers completely.** This was considered, but matching against sentinel values of raw pointers is a pretty common pattern, so we should have a really good reason to break that code---and we do not. - **Involve `Eq`.** - This RFC is is completely defined in terms of `PartialEq`; the `Eq` trait plays no role. + This RFC is completely defined in terms of `PartialEq`; the `Eq` trait plays no role. This is primarily because we allow floating-point values in patterns, which means that we cannot require the constant to implement `Eq` in the first place. - **Do not require `PartialEq`.** Currently we check both that the constant value has recursive structural equality, and that its type implements `PartialEq`.