mirror of https://github.com/rust-lang/rfcs.git
Fix typos in RFCs 2501-2750
This commit is contained in:
parent
6bdce2fa52
commit
53b478875d
|
@ -193,7 +193,7 @@ union U<T> { x:(), f: ManuallyDrop<T> }
|
|||
|
||||
fn main() {
|
||||
let mut u : U<(Vec<i32>,)> = U { x: () };
|
||||
unsafe { u.f.0 = Vec::new() }; // uninitialized `Vec` being droped
|
||||
unsafe { u.f.0 = Vec::new() }; // uninitialized `Vec` being dropped
|
||||
}
|
||||
```
|
||||
This requires `unsafe` because it desugars to `ManuallyDrop::deref_mut(&mut u.f).0`,
|
||||
|
|
|
@ -52,7 +52,7 @@ fn foo() -> __foo_return {
|
|||
}
|
||||
```
|
||||
|
||||
The generated type `__foo_return` is not exposed: it is automatically contructed from any valid type (as in `(3)`).
|
||||
The generated type `__foo_return` is not exposed: it is automatically constructed from any valid type (as in `(3)`).
|
||||
|
||||
Note that, in order for the type inference to support argument-position `impl Trait`, which may be polymorphic (just like a generic parameter), the inference used here is actually a more expressive form of type inference similar to ML-style let polymorphism. Here, the inference of function types may result in additional generic parameters, specifically relating to the occurrences of argument-position `impl Trait`.
|
||||
|
||||
|
@ -96,7 +96,7 @@ fn foo() -> Baz {
|
|||
}
|
||||
```
|
||||
|
||||
However, if the function is parameterised, it may be necessary to add explicit parameters to the type alias (due to the return-type being within the scope of the function's generic paramters, unlike the type alias).
|
||||
However, if the function is parameterised, it may be necessary to add explicit parameters to the type alias (due to the return-type being within the scope of the function's generic parameters, unlike the type alias).
|
||||
|
||||
Using `Baz` in multiple locations constrains all occurrences of the inferred type to be the same, just as with `existential type`.
|
||||
|
||||
|
|
|
@ -80,7 +80,7 @@ A pointer returned from one library can now be passed to the other library witho
|
|||
In the standard library:
|
||||
|
||||
* Create a new `core::ffi` module.
|
||||
* Move the `enum` definiton of `c_void` there.
|
||||
* Move the `enum` definition of `c_void` there.
|
||||
* In `c_void`’s former location (`std::os::raw`), replace it with a `pub use` reexport.
|
||||
* For consistency between `core` and `std`, also add a similar `pub use` reexport at `std::ffi::c_void`.
|
||||
(Note that the `std::ffi` module already exists.)
|
||||
|
@ -91,7 +91,7 @@ Once the above lands in Nightly, in the `libc` crate:
|
|||
(for example by executing `$RUSTC` with a temporary file like
|
||||
`#![crate_type = "lib"] #![no_std] pub use core::ffi::c_void;`)
|
||||
and conditionally set a compilation flag for the library.
|
||||
* In the library, based on the precence of that flag,
|
||||
* In the library, based on the presence of that flag,
|
||||
make `c_void` be either `pub use core::ffi::c_void;` or its current `enum` definition,
|
||||
to keep compatibility with older Rust versions.
|
||||
|
||||
|
@ -147,7 +147,7 @@ for example, `ptr::null::<c_void>()` and `<*mut c_void>::offset(n)` would not be
|
|||
|
||||
We could deprecated `c_void` and replace it with a new differently-named extern type,
|
||||
but forcing the ecosystem through that transition seems too costly for this theoretical nicety.
|
||||
Plus, this woud still be a nominal type.
|
||||
Plus, this would still be a nominal type.
|
||||
If this new type is to be present if both `libc` and `std`,
|
||||
it would still have to be in `core` as well.
|
||||
|
||||
|
@ -176,5 +176,5 @@ This is left for a future RFC.
|
|||
This RFC does not propose any change such as moving to libcore for the C types other than `c_void`.
|
||||
|
||||
Although some in previous discussions have expressed desire for using C-compatible types
|
||||
without linking to the C runtime libray (which the `libc` crate does) or depending on `std`.
|
||||
without linking to the C runtime library (which the `libc` crate does) or depending on `std`.
|
||||
This use case is also left for a future proposal or RFC.
|
||||
|
|
|
@ -19,7 +19,7 @@ compile if the type `MyType` doesn't implement the trait `MyTrait`:
|
|||
```rust
|
||||
const _FOO: () = {
|
||||
use std::marker::PhantomData;
|
||||
struct ImpelementsMyTrait<T: MyTrait>(PhantomData<T>);
|
||||
struct ImplementsMyTrait<T: MyTrait>(PhantomData<T>);
|
||||
let _ = ImplementsMyTrait::<MyType>(PhantomData); // type checking error if MyType: !MyTrait
|
||||
()
|
||||
};
|
||||
|
|
|
@ -976,7 +976,7 @@ associated type include:
|
|||
type Output = Self;
|
||||
|
||||
// OK to assume what `Output` really is because any overriding
|
||||
// must override both `Outout` and `finish`.
|
||||
// must override both `Output` and `finish`.
|
||||
fn finish(self) -> Self::Output { self }
|
||||
}
|
||||
}
|
||||
|
@ -1403,7 +1403,7 @@ impl Bar for Theta {
|
|||
|
||||
impl Bar for Iota {
|
||||
// We have overridden `Bar` which is in the root group.
|
||||
// Since all other items are decendants of the same group as `Bar` is in,
|
||||
// Since all other items are descendants of the same group as `Bar` is in,
|
||||
// they are allowed to depend on what `Bar` is.
|
||||
type Bar = u8;
|
||||
|
||||
|
|
|
@ -527,7 +527,7 @@ param : pat<no_top_alt> ':' ty_sum ;
|
|||
For closures we now have:
|
||||
|
||||
```rust
|
||||
inferrable_param : pat<no_top_alt> maybe_ty_ascription ;
|
||||
inferable_param : pat<no_top_alt> maybe_ty_ascription ;
|
||||
```
|
||||
|
||||
Finally, `pat` macro fragment specifiers will also match the `pat<no_top_alt>`
|
||||
|
@ -851,7 +851,7 @@ There is support for or-patterns in [various lisp libraries][lisp_libs].
|
|||
# Unresolved questions
|
||||
[unresolved]: #unresolved-questions
|
||||
|
||||
1. Should we allow `top_pat` or `pat<allow_top_alt>` in `inferrable_param` such
|
||||
1. Should we allow `top_pat` or `pat<allow_top_alt>` in `inferable_param` such
|
||||
that closures permit `|Ok(x) | Err(x)|` without first wrapping in parenthesis?
|
||||
|
||||
We defer this decision to stabilization as it may depend on experimentation.
|
||||
|
|
|
@ -30,7 +30,7 @@ For an example of multiple attributes, say we want to have two attribute macros
|
|||
(`sparkles` and `crackles`), but only when `feature = "magic"` is enabled. We
|
||||
can write this as:
|
||||
|
||||
```rust,igore
|
||||
```rust,ignore
|
||||
#[cfg_attr(feature = "magic", sparkles, crackles)]
|
||||
fn bewitched() {}
|
||||
```
|
||||
|
@ -86,7 +86,7 @@ mod os;
|
|||
For an example of multiple attributes, say we want to have two attribute macros,
|
||||
but only when `feature = "magic"` is enabled. We can write this as:
|
||||
|
||||
```rust,igore
|
||||
```rust,ignore
|
||||
#[cfg_attr(feature = "magic", sparkles, crackles)]
|
||||
fn bewitched() {}
|
||||
```
|
||||
|
@ -122,7 +122,7 @@ Today, an attribute can look like:
|
|||
* ``name = `TokenTree` ``
|
||||
|
||||
where `TokenStream` is a sequence of tokens that only has the restriction that
|
||||
delimiters match and `TokenTree` is a single identifer, literal, punctuation
|
||||
delimiters match and `TokenTree` is a single identifier, literal, punctuation
|
||||
mark, or a delimited `TokenStream`.
|
||||
|
||||
With this RFC accepted, the following cannot ever be parsed as attributes:
|
||||
|
|
|
@ -31,7 +31,7 @@ from the standard library.
|
|||
as it was guaranteed to have the same memory layout.
|
||||
This was replaced with more specific and less wildly unsafe
|
||||
`std::slice::from_raw_parts` and `std::slice::from_raw_parts_mut` functions,
|
||||
together with `as_ptr` and `len` methods that extract each fat pointer component separatly.
|
||||
together with `as_ptr` and `len` methods that extract each fat pointer component separately.
|
||||
|
||||
For trait objects, where we still have an unstable `std::raw::TraitObject` type
|
||||
that can only be used with `transmute`:
|
||||
|
@ -46,7 +46,7 @@ pub struct TraitObject {
|
|||
|
||||
[`std::raw::Repr`]: https://doc.rust-lang.org/1.10.0/std/raw/trait.Repr.html
|
||||
[`std::raw::Slice`]: https://doc.rust-lang.org/1.10.0/std/raw/struct.Slice.html
|
||||
[`std::raw::TraitObjet`]: https://doc.rust-lang.org/1.30.0/std/raw/struct.TraitObject.html
|
||||
[`std::raw::TraitObject`]: https://doc.rust-lang.org/1.30.0/std/raw/struct.TraitObject.html
|
||||
|
||||
|
||||
# Motivation
|
||||
|
@ -100,7 +100,7 @@ struct WithMeta<T: ?Sized> {
|
|||
Since [unsized rvalues] are not implemented yet,
|
||||
our constructor is going to “unsize” from a concrete type that implements our trait.
|
||||
The `Unsize` bound ensures we can cast from `&S` to a `&Dyn` trait object
|
||||
and construct the appopriate metadata.
|
||||
and construct the appropriate metadata.
|
||||
|
||||
[unsized rvalues]: https://github.com/rust-lang/rust/issues/48055
|
||||
|
||||
|
@ -373,7 +373,7 @@ Except for `DynMetadata`’s methods, this RFC proposes a subset of what that th
|
|||
This might reduce monomorphization cost,
|
||||
but would force that the size, alignment, and destruction pointers
|
||||
be in the same location (offset) for every vtable.
|
||||
But keeping them in the same location is probaly desirable anyway to keep code size small.
|
||||
But keeping them in the same location is probably desirable anyway to keep code size small.
|
||||
|
||||
* The name of `Thin`.
|
||||
This name is short and sweet but `T: Thin` suggests that `T` itself is thin,
|
||||
|
@ -385,7 +385,7 @@ Except for `DynMetadata`’s methods, this RFC proposes a subset of what that th
|
|||
Or could it ever make sense to have fat pointers to statically-sized types?
|
||||
|
||||
* Are there other generic standard library APIs like `ptr::null()`
|
||||
that have an (implicit) `T: Sized` bound that unneccesarily excludes extern types?
|
||||
that have an (implicit) `T: Sized` bound that unnecessarily excludes extern types?
|
||||
|
||||
* Should `<*mut _>::from_raw_parts` and friends be `unsafe fn`s?
|
||||
|
||||
|
|
|
@ -18,7 +18,7 @@ Currently, if one wants to create a raw pointer pointing to something, one has n
|
|||
The problem with this is that there are some invariants that we want to attach to references, that have to *always hold*.
|
||||
The details of this are not finally decided yet, but true in practice because of annotations we emit to LLVM.
|
||||
It is also the next topic of discussion in the [Unsafe Code Guidelines](https://github.com/rust-rfcs/unsafe-code-guidelines/).
|
||||
In particular, references must be aligned and dereferencable, even when they are created and never used.
|
||||
In particular, references must be aligned and dereferenceable, even when they are created and never used.
|
||||
|
||||
One consequence of these rules is that it becomes essentially impossible to create a raw pointer pointing to an unaligned struct field:
|
||||
`&packed.field as *const _` creates an intermediate unaligned reference, triggering undefined behavior because it is not aligned.
|
||||
|
@ -63,7 +63,7 @@ let x = unsafe { &packed.field }; // `x` is not aligned -> undefined behavior
|
|||
```
|
||||
|
||||
There is no situation in which the above code is correct, and hence it is a hard error to write this (after a transition period).
|
||||
This applies to most ways of creating a reference, i.e., all of the following are UB if `X` is not properly aligned and dereferencable:
|
||||
This applies to most ways of creating a reference, i.e., all of the following are UB if `X` is not properly aligned and dereferenceable:
|
||||
|
||||
```rust
|
||||
fn foo() -> &T {
|
||||
|
|
|
@ -67,7 +67,7 @@ The implementation of this features uses interval arithmetic and an extension of
|
|||
|
||||
This feature has already [been implemented](https://github.com/rust-lang/rust/pull/50912), so the code there may be used for further reference. The source contains detailed comments about the implementation.
|
||||
|
||||
For `usize` and `isize`, no assumptions about the maximimum value are permitted. To exhaustively match on either pointer-size integer type a wildcard pattern (`_`) must be used (or if [open-ended range patterns are added](https://github.com/rust-lang/rfcs/issues/947), ranges must be open ended [e.g. `0..`]). An unstable feature `precise_pointer_size_matching` will be added to permit matching exactly on pointer-size integer types.
|
||||
For `usize` and `isize`, no assumptions about the maximum value are permitted. To exhaustively match on either pointer-size integer type a wildcard pattern (`_`) must be used (or if [open-ended range patterns are added](https://github.com/rust-lang/rfcs/issues/947), ranges must be open ended [e.g. `0..`]). An unstable feature `precise_pointer_size_matching` will be added to permit matching exactly on pointer-size integer types.
|
||||
|
||||
# Drawbacks
|
||||
[drawbacks]: #drawbacks
|
||||
|
|
|
@ -404,7 +404,7 @@ The various discussions outlined in the historical context section above cover t
|
|||
path to these APIs from futures 0.1. But, in a nutshell, there are three major shifts:
|
||||
|
||||
- The use of `Pin<&mut self>` rather than just `&mut self`, which is necessary
|
||||
to support borrowing withing `async` blocks. The `Unpin` marker trait can be used
|
||||
to support borrowing within `async` blocks. The `Unpin` marker trait can be used
|
||||
to restore ergonomics and safety similar to futures 0.1 when writing futures by hand.
|
||||
|
||||
- Dropping *built in* errors from `Future`, in favor of futures returning a `Result`
|
||||
|
|
|
@ -110,7 +110,7 @@ pub const THIS_IS_OKAY: GenericUnion<()> = GenericUnion { field: () };
|
|||
pub const THIS_IS_OKAY_TOO: GenericEnum<()> = GenericEnum::Variant((), ());
|
||||
```
|
||||
|
||||
Transparent `enum`s have the addtional restriction that they require exactly one variant:
|
||||
Transparent `enum`s have the additional restriction that they require exactly one variant:
|
||||
|
||||
```rust
|
||||
// Error: transparent enum needs exactly one variant, but has 0
|
||||
|
@ -219,7 +219,7 @@ In summary, many of the questions regarding `#[repr(transparent)]` on a `union`
|
|||
# Unresolved questions
|
||||
[unresolved]: #unresolved-questions
|
||||
|
||||
The role of `#[repr(transparent)]` in nonnull-style optimizations is not entirely clear. Specifically, it is unclear whether the user can rely on these optimizations to be performed when they make a type transparent. [Transparent `union`s somewhat complicate the matter](https://github.com/rust-lang/rfcs/pull/2645#issuecomment-470699497). General concensus seems to be that the compiler is free to decide where and when to perform nonnull-style optimizations on `union`s (regardless of whether or not the `union` is transaprent), and no guarantees are made to the user about when and if those optimizations will be applied. It is still an open question exactly what guarantees (if any) Rust makes about transparent `struct`s (and `enum`s) and nonnull-style optimizations.
|
||||
The role of `#[repr(transparent)]` in nonnull-style optimizations is not entirely clear. Specifically, it is unclear whether the user can rely on these optimizations to be performed when they make a type transparent. [Transparent `union`s somewhat complicate the matter](https://github.com/rust-lang/rfcs/pull/2645#issuecomment-470699497). General consensus seems to be that the compiler is free to decide where and when to perform nonnull-style optimizations on `union`s (regardless of whether or not the `union` is transparent), and no guarantees are made to the user about when and if those optimizations will be applied. It is still an open question exactly what guarantees (if any) Rust makes about transparent `struct`s (and `enum`s) and nonnull-style optimizations.
|
||||
|
||||
This RFC doesn't propose any changes to transparent `struct`s, and so does not strictly depend on this question being resolved. But since this RFC is attempting to round out the `#[repr(transparent)]` feature, it seems reasonable to dedicate some time to attempting to round out the guarantees about `#[repr(transparent)]` on `struct`s.
|
||||
|
||||
|
|
|
@ -274,7 +274,7 @@ these working groups.
|
|||
|
||||
## Async Foundations and Async Ecosystem
|
||||
|
||||
The 2018 roadmap comissioned a "Networking Services" domain working group.
|
||||
The 2018 roadmap commissioned a "Networking Services" domain working group.
|
||||
Since then, that working group has [split into two
|
||||
parts](https://blog.yoshuawuyts.com/async-ecosystem-wg/):
|
||||
|
||||
|
|
Loading…
Reference in New Issue