mirror of https://github.com/rust-lang/rfcs
chore: remove repetitive words
Signed-off-by: growfrow <growfrow@outlook.com>
This commit is contained in:
parent
766f61b343
commit
9d706c0b18
|
@ -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
|
code) will simply be to make incremental compilation somewhat less
|
||||||
effective, since we will be forced to re-type-check and re-trans
|
effective, since we will be forced to re-type-check and re-trans
|
||||||
functions where we might have gotten away with only generating new
|
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
|
overall, particularly since LLVM optimization time can be a very large
|
||||||
portion of compilation.
|
portion of compilation.
|
||||||
|
|
||||||
|
|
|
@ -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
|
option we choose can be incorporated into the meta-data for a
|
||||||
crate.)
|
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
|
themselves as such, by implementing `GcAwareAllocator`, which will
|
||||||
then impose new conditions on the methods of `Allocator`, for example
|
then impose new conditions on the methods of `Allocator`, for example
|
||||||
ensuring e.g. that allocated blocks of memory can be scanned
|
ensuring e.g. that allocated blocks of memory can be scanned
|
||||||
|
|
|
@ -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
|
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!
|
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
|
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
|
does not (yet) support default function arguments or function overloading because they interfere
|
||||||
with type inference, so such solutions are ruled out.
|
with type inference, so such solutions are ruled out.
|
||||||
|
|
|
@ -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
|
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,
|
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
|
this RFC is therefore the simplest and most non-intrusive design. It is also
|
||||||
the most consistent.
|
the most consistent.
|
||||||
|
|
||||||
|
|
|
@ -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`.
|
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
|
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.
|
fn` are sufficient to discharge the requirements of the unsafe operations.
|
||||||
|
|
||||||
We could restrict this requirement to use `unsafe` blocks in `unsafe fn` to
|
We could restrict this requirement to use `unsafe` blocks in `unsafe fn` to
|
||||||
|
|
|
@ -348,7 +348,7 @@ and `NCNvNtC7mycrate3foo3bars_0` respectively.
|
||||||
Methods are nested within `impl` or `trait` items. As such it would be
|
Methods are nested within `impl` or `trait` items. As such it would be
|
||||||
possible to construct their symbol names as paths like
|
possible to construct their symbol names as paths like
|
||||||
`my_crate::foo::{{impl}}::some_method` where `{{impl}}` somehow identifies
|
`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
|
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
|
what the compiler does internally). Adding in generic arguments to, this
|
||||||
would lead to symbol names looking like
|
would lead to symbol names looking like
|
||||||
|
|
|
@ -202,7 +202,7 @@ types:
|
||||||
In this case, `$field` must share a name or tuple index with a field which:
|
In this case, `$field` must share a name or tuple index with a field which:
|
||||||
- Exists on `$Container`.
|
- Exists on `$Container`.
|
||||||
- Is visible at the location where `offset_of!` is invoked (but there is no
|
- 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.
|
2. An anonymous tuple type.
|
||||||
|
|
||||||
|
|
|
@ -245,7 +245,7 @@ Some possible alternatives include:
|
||||||
- **Reject pointers completely.**
|
- **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.
|
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`.**
|
- **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.
|
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`.**
|
- **Do not require `PartialEq`.**
|
||||||
Currently we check both that the constant value has recursive structural equality, and that its type implements `PartialEq`.
|
Currently we check both that the constant value has recursive structural equality, and that its type implements `PartialEq`.
|
||||||
|
|
Loading…
Reference in New Issue