auto merge of #16925 : jbcrail/rust/doc-spelling-errors, r=alexcrichton
I fixed spelling mistakes in the documentation.
This commit is contained in:
commit
dfbd4669cd
|
@ -83,7 +83,7 @@ We want to maintain the option to parametrize at runtime. We may eventually chan
|
|||
|
||||
## Why aren't values type-parametric? Why only items?
|
||||
|
||||
Doing so would make type inference much more complex, and require the implementation strategy of runtime parametrization.
|
||||
Doing so would make type inference much more complex, and require the implementation strategy of runtime parameterization.
|
||||
|
||||
## Why are enumerations nominal and closed?
|
||||
|
||||
|
|
|
@ -1808,7 +1808,7 @@ our code in this file. We'll talk about multiple-file projects later on in the
|
|||
guide.
|
||||
|
||||
Before we move on, let me show you one more Cargo command: `run`. `cargo run`
|
||||
is kind of like `cargo build`, but it also then runs the produced exectuable.
|
||||
is kind of like `cargo build`, but it also then runs the produced executable.
|
||||
Try it out:
|
||||
|
||||
```{notrust,ignore}
|
||||
|
|
|
@ -1954,7 +1954,7 @@ On `struct`s:
|
|||
|
||||
- `repr` - specifies the representation to use for this struct. Takes a list
|
||||
of options. The currently accepted ones are `C` and `packed`, which may be
|
||||
combined. `C` will use a C ABI comptible struct layout, and `packed` will
|
||||
combined. `C` will use a C ABI compatible struct layout, and `packed` will
|
||||
remove any padding between fields (note that this is very fragile and may
|
||||
break platforms which require aligned access).
|
||||
|
||||
|
@ -2367,7 +2367,7 @@ One can indicate the stability of an API using the following attributes:
|
|||
These levels are directly inspired by
|
||||
[Node.js' "stability index"](http://nodejs.org/api/documentation.html).
|
||||
|
||||
Stability levels are inherited, so an items's stability attribute is the
|
||||
Stability levels are inherited, so an item's stability attribute is the
|
||||
default stability for everything nested underneath it.
|
||||
|
||||
There are lints for disallowing items marked with certain levels: `deprecated`,
|
||||
|
@ -2444,7 +2444,7 @@ The currently implemented features of the reference compiler are:
|
|||
|
||||
* `concat_idents` - Allows use of the `concat_idents` macro, which is in many
|
||||
ways insufficient for concatenating identifiers, and may
|
||||
be removed entirely for something more wholsome.
|
||||
be removed entirely for something more wholesome.
|
||||
|
||||
* `default_type_params` - Allows use of default type parameters. The future of
|
||||
this feature is uncertain.
|
||||
|
@ -3604,7 +3604,7 @@ of the type.[^structtype]
|
|||
|
||||
New instances of a `struct` can be constructed with a [struct expression](#structure-expressions).
|
||||
|
||||
The memory layout of a `struct` is undefined by default to allow for compiler optimziations like
|
||||
The memory layout of a `struct` is undefined by default to allow for compiler optimizations like
|
||||
field reordering, but it can be fixed with the `#[repr(...)]` attribute.
|
||||
In either case, fields may be given in any order in a corresponding struct *expression*;
|
||||
the resulting `struct` value will always have the same memory layout.
|
||||
|
@ -4202,7 +4202,7 @@ be ignored in favor of only building the artifacts specified by command line.
|
|||
purpose of this output type is to create a static library containing all of
|
||||
the local crate's code along with all upstream dependencies. The static
|
||||
library is actually a `*.a` archive on linux and osx and a `*.lib` file on
|
||||
windows. This format is recommended for use in situtations such as linking
|
||||
windows. This format is recommended for use in situations such as linking
|
||||
Rust code into an existing non-Rust application because it will not have
|
||||
dynamic dependencies on other Rust code.
|
||||
|
||||
|
|
Loading…
Reference in New Issue