chore: remove repetitive words

Signed-off-by: growfrow <growfrow@outlook.com>
This commit is contained in:
growfrow 2024-04-18 16:50:13 +08:00
parent 766f61b343
commit 9d706c0b18
8 changed files with 8 additions and 8 deletions

View File

@ -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.

View File

@ -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

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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`.