nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-29 02:03:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(compiler): correct minor typos in some long error code explanations

Browse Source
This commit is contained in:
James R T 2022-01-11 10:42:51 +08:00
parent 89b9f7b284
commit 842bf71fda
No known key found for this signature in database
GPG Key ID: AA7B796B3182A439
4 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
compiler/rustc_error_codes/src/error_codes/E0038.md
View File

@ -15,7 +15,7 @@ Two general aspects of trait object types give rise to the restrictions:
these types can only be accessed through pointers, such as `&dyn Trait` or these types can only be accessed through pointers, such as `&dyn Trait` or
`Box<dyn Trait>`. The size of such a pointer is known, but the size of the `Box<dyn Trait>`. The size of such a pointer is known, but the size of the
`dyn Trait` object pointed-to by the pointer is _opaque_ to code working `dyn Trait` object pointed-to by the pointer is _opaque_ to code working
with it, and different tait objects with the same trait object type may with it, and different trait objects with the same trait object type may
have different sizes. have different sizes.
2. The pointer used to access a trait object is paired with an extra pointer 2. The pointer used to access a trait object is paired with an extra pointer
@ -167,7 +167,7 @@ implementation on-demand. If you call `foo()` with a `bool` parameter, the
compiler will only generate code for `foo::<bool>()`. When we have additional compiler will only generate code for `foo::<bool>()`. When we have additional
type parameters, the number of monomorphized implementations the compiler type parameters, the number of monomorphized implementations the compiler
generates does not grow drastically, since the compiler will only generate an generates does not grow drastically, since the compiler will only generate an
implementation if the function is called with unparametrized substitutions implementation if the function is called with unparameterized substitutions
(i.e., substitutions where none of the substituted types are themselves (i.e., substitutions where none of the substituted types are themselves
parameterized). parameterized).

4
compiler/rustc_error_codes/src/error_codes/E0183.md
View File

@ -1,4 +1,4 @@
Manual implemetation of a `Fn*` trait. Manual implementation of a `Fn*` trait.
Erroneous code example: Erroneous code example:
@ -33,7 +33,7 @@ impl FnOnce<()> for MyClosure { // ok!
} }
``` ```
The argumements must be a tuple representing the argument list. The arguments must be a tuple representing the argument list.
For more info, see the [tracking issue][iss29625]: For more info, see the [tracking issue][iss29625]:
[iss29625]: https://github.com/rust-lang/rust/issues/29625 [iss29625]: https://github.com/rust-lang/rust/issues/29625

2
compiler/rustc_error_codes/src/error_codes/E0521.md
View File

@ -10,7 +10,7 @@ let _add = |el: &str| {
}; };
``` ```
A type anotation of a closure parameter implies a new lifetime declaration. A type annotation of a closure parameter implies a new lifetime declaration.
Consider to drop it, the compiler is reliably able to infer them. Consider to drop it, the compiler is reliably able to infer them.
``` ```

2
compiler/rustc_error_codes/src/error_codes/E0581.md
View File

@ -10,7 +10,7 @@ fn main() {
} }
``` ```
The problem here is that the lifetime isn't contrained by any of the arguments, The problem here is that the lifetime isn't constrained by any of the arguments,
making it impossible to determine how long it's supposed to live. making it impossible to determine how long it's supposed to live.
To fix this issue, either use the lifetime in the arguments, or use the To fix this issue, either use the lifetime in the arguments, or use the