summaryrefslogtreecommitdiffstats
path: root/src/doc/reference/src
diff options
context:
space:
mode:
Diffstat (limited to 'src/doc/reference/src')
-rw-r--r--src/doc/reference/src/behavior-considered-undefined.md2
-rw-r--r--src/doc/reference/src/destructors.md2
-rw-r--r--src/doc/reference/src/expressions/if-expr.md2
-rw-r--r--src/doc/reference/src/expressions/operator-expr.md2
-rw-r--r--src/doc/reference/src/items/external-blocks.md2
-rw-r--r--src/doc/reference/src/linkage.md2
-rw-r--r--src/doc/reference/src/patterns.md47
-rw-r--r--src/doc/reference/src/trait-bounds.md2
8 files changed, 30 insertions, 31 deletions
diff --git a/src/doc/reference/src/behavior-considered-undefined.md b/src/doc/reference/src/behavior-considered-undefined.md
index f8bffd13e..31963d1e5 100644
--- a/src/doc/reference/src/behavior-considered-undefined.md
+++ b/src/doc/reference/src/behavior-considered-undefined.md
@@ -25,7 +25,7 @@ code.
* Data races.
* Evaluating a [dereference expression] (`*expr`) on a raw pointer that is
[dangling] or unaligned, even in [place expression context]
- (e.g. `addr_of!(&*expr)`).
+ (e.g. `addr_of!(*expr)`).
* Breaking the [pointer aliasing rules]. `Box<T>`, `&mut T` and `&T` follow
LLVM’s scoped [noalias] model, except if the `&T` contains an
[`UnsafeCell<U>`]. References and boxes must not be [dangling] while they are
diff --git a/src/doc/reference/src/destructors.md b/src/doc/reference/src/destructors.md
index f89fde157..84aac89d3 100644
--- a/src/doc/reference/src/destructors.md
+++ b/src/doc/reference/src/destructors.md
@@ -162,7 +162,7 @@ smallest scope that contains the expression and is one of the following:
* The `else` block of an `if` expression.
* The condition expression of an `if` or `while` expression, or a `match`
guard.
-* The expression for a match arm.
+* The body expression for a match arm.
* The second operand of a [lazy boolean expression].
> **Notes**:
diff --git a/src/doc/reference/src/expressions/if-expr.md b/src/doc/reference/src/expressions/if-expr.md
index 591437fc9..fe387c828 100644
--- a/src/doc/reference/src/expressions/if-expr.md
+++ b/src/doc/reference/src/expressions/if-expr.md
@@ -129,7 +129,7 @@ The expression cannot be a [lazy boolean operator expression][_LazyBooleanOperat
Use of a lazy boolean operator is ambiguous with a planned feature change of the language (the implementation of if-let chains - see [eRFC 2947][_eRFCIfLetChain_]).
When lazy boolean operator expression is desired, this can be achieved by using parenthesis as below:
-<!-- ignore: psuedo code -->
+<!-- ignore: pseudo code -->
```rust,ignore
// Before...
if let PAT = EXPR && EXPR { .. }
diff --git a/src/doc/reference/src/expressions/operator-expr.md b/src/doc/reference/src/expressions/operator-expr.md
index 9f7e8edac..691f801e8 100644
--- a/src/doc/reference/src/expressions/operator-expr.md
+++ b/src/doc/reference/src/expressions/operator-expr.md
@@ -600,7 +600,7 @@ It will then set the value of the assigned operand's place to the value of perfo
> **Note**: This is different than other expressions in that the right operand is evaluated before the left one.
-Otherwise, this expression is syntactic sugar for calling the function of the overloading compound assigment trait of the operator (see the table earlier in this chapter).
+Otherwise, this expression is syntactic sugar for calling the function of the overloading compound assignment trait of the operator (see the table earlier in this chapter).
A mutable borrow of the assigned operand is automatically taken.
For example, the following expression statements in `example` are equivalent:
diff --git a/src/doc/reference/src/items/external-blocks.md b/src/doc/reference/src/items/external-blocks.md
index d89536968..ce2190829 100644
--- a/src/doc/reference/src/items/external-blocks.md
+++ b/src/doc/reference/src/items/external-blocks.md
@@ -90,6 +90,7 @@ There are also some platform-specific ABI strings:
`__fastcall` and GCC and clang's `__attribute__((fastcall))`
* `extern "vectorcall"` -- The `vectorcall` ABI -- corresponds to MSVC's
`__vectorcall` and clang's `__attribute__((vectorcall))`
+* `extern "efiapi"` -- The ABI used for [UEFI] functions.
## Variadic functions
@@ -288,6 +289,7 @@ Attributes on extern function parameters follow the same rules and
restrictions as [regular function parameters].
[IDENTIFIER]: ../identifiers.md
+[UEFI]: https://uefi.org/specifications
[WebAssembly module]: https://webassembly.github.io/spec/core/syntax/modules.html
[functions]: functions.md
[statics]: static-items.md
diff --git a/src/doc/reference/src/linkage.md b/src/doc/reference/src/linkage.md
index b15200511..82864b004 100644
--- a/src/doc/reference/src/linkage.md
+++ b/src/doc/reference/src/linkage.md
@@ -73,7 +73,7 @@ be ignored in favor of only building the artifacts specified by command line.
being built for a different target.
Note that these outputs are stackable in the sense that if multiple are
-specified, then the compiler will produce each form of output at once without
+specified, then the compiler will produce each form of output without
having to recompile. However, this only applies for outputs specified by the
same method. If only `crate_type` attributes are specified, then they will all
be built, but if one or more `--crate-type` command line flags are specified,
diff --git a/src/doc/reference/src/patterns.md b/src/doc/reference/src/patterns.md
index 14bbac155..370e1990c 100644
--- a/src/doc/reference/src/patterns.md
+++ b/src/doc/reference/src/patterns.md
@@ -380,16 +380,19 @@ match tuple {
> **<sup>Syntax</sup>**\
> _RangePattern_ :\
-> &nbsp;&nbsp; &nbsp;&nbsp; _InclusiveRangePattern_\
-> &nbsp;&nbsp; | _HalfOpenRangePattern_\
+> &nbsp;&nbsp; &nbsp;&nbsp; _RangeInclusivePattern_\
+> &nbsp;&nbsp; | _RangeFromPattern_\
+> &nbsp;&nbsp; | _RangeToInclusivePattern_\
> &nbsp;&nbsp; | _ObsoleteRangePattern_
>
-> _InclusiveRangePattern_ :\
+> _RangeInclusivePattern_ :\
> &nbsp;&nbsp; &nbsp;&nbsp; _RangePatternBound_ `..=` _RangePatternBound_
>
-> _HalfOpenRangePattern_ :\
+> _RangeFromPattern_ :\
> &nbsp;&nbsp; &nbsp;&nbsp; _RangePatternBound_ `..`
-> &nbsp;&nbsp; | `..=` _RangePatternBound_
+>
+> _RangeToInclusivePattern_ :\
+> &nbsp;&nbsp; &nbsp;&nbsp; `..=` _RangePatternBound_
>
> _ObsoleteRangePattern_ :\
> &nbsp;&nbsp; _RangePatternBound_ `...` _RangePatternBound_
@@ -402,16 +405,13 @@ match tuple {
> &nbsp;&nbsp; | [_PathExpression_]
*Range patterns* match scalar values within the range defined by their bounds.
-A bound on the left of its sigils is a *lower bound*.
+They comprise a *sigil* (one of `..`, `..=`, or `...`) and a bound on one or both sides.
+A bound on the left of the sigil is a *lower bound*.
A bound on the right is an *upper bound*.
-A range pattern may be closed or half-open.
-
-A range pattern is *closed* if it has both a lower and an upper bound.
-The only closed ranged pattern is the inclusive range pattern.
-*Inclusive range patterns* match all the values between and including both of its bounds.
-It is written as its lower bounds, followed by `..=`, followed by its upper bounds.
-The type of it is the type unification of its upper and lower bounds.
+A range pattern with both a lower and upper bound will match all values between and including both of its bounds.
+It is written as its lower bound, followed by `..=`, followed by its upper bound.
+The type of the range pattern is the type unification of its upper and lower bounds.
For example, a pattern `'m'..='p'` will match only the values `'m'`, `'n'`, `'o'`, and `'p'`.
@@ -419,19 +419,15 @@ The lower bound cannot be greater than the upper bound.
That is, in `a..=b`, a &le; b must be the case.
For example, it is an error to have a range pattern `10..=0`.
-Range patterns are *half-open* if they have only an upper or lower bound.
-They have the same type as their upper or lower bound.
-
-A half open range with only a lower bound is written as its lower bound followed by `..`.
-These range patterns will match on any value greater than or equal to the lower bound.
+A range pattern with only a lower bound will match any value greater than or equal to the lower bound.
+It is written as its lower bound followed by `..`, and has the same type as its lower bound.
For example, `1..` will match 1, 9, or 9001, or 9007199254740991 (if it is of an appropriate size), but not 0, and not negative numbers for signed integers.
-The bounds can be literals or paths that point to constant values.
-A half open range with only an upper bound is written as `..=` followed by its upper bound.
-These range patterns will match on any value less than or equal to the upper bound.
-For example, `..=10` will match 10, 1, 0, and for signed interger types, all negative values.
+A range pattern with only an upper bound matches any value less than or equal to the upper bound.
+It is written as `..=` followed by its upper bound, and has the same type as its upper bound.
+For example, `..=10` will match 10, 1, 0, and for signed integer types, all negative values.
-Half-open range patterns cannot be used as the top-level pattern for subpatterns in [slice patterns](#slice-patterns).
+Range patterns with only one bound cannot be used as the top-level pattern for subpatterns in [slice patterns](#slice-patterns).
The bounds is written as one of:
@@ -529,7 +525,7 @@ The range of values for a `char` type are precisely those ranges containing all
Floating point range patterns are deprecated and may be removed in a future Rust release.
See [issue #41620](https://github.com/rust-lang/rust/issues/41620) for more information.
-> **Edition Differences**: Before the 2021 edition, closed range patterns may also be written using `...` as an alternative to `..=`, with the same meaning.
+> **Edition Differences**: Before the 2021 edition, range patterns with both a lower and upper bound may also be written using `...` in place of `..=`, with the same meaning.
> **Note**: Although range patterns use the same syntax as [range expressions], there are no exclusive range patterns.
> That is, neither `x .. y` nor `.. x` are valid range patterns.
@@ -747,7 +743,8 @@ match v[..] {
Slice patterns are irrefutable when matching an array as long as each element is irrefutable.
When matching a slice, it is irrefutable only in the form with a single `..` [rest pattern](#rest-patterns) or [identifier pattern](#identifier-patterns) with the `..` rest pattern as a subpattern.
-Within a slice, a half-open range pattern like `a..` must be enclosed in parentheses, as in `(a..)`, to clarify it is intended to match a single value.
+Within a slice, a range pattern without both lower and upper bound must be enclosed in parentheses, as in `(a..)`, to clarify it is intended to match against a single slice element.
+A range pattern with both lower and upper bound, like `a..=b`, is not required to be enclosed in parentheses.
## Path patterns
diff --git a/src/doc/reference/src/trait-bounds.md b/src/doc/reference/src/trait-bounds.md
index c8dab3f1c..0a6731288 100644
--- a/src/doc/reference/src/trait-bounds.md
+++ b/src/doc/reference/src/trait-bounds.md
@@ -27,7 +27,7 @@ provided on any type in a [where clause]. There are also shorter forms for
certain common cases:
* Bounds written after declaring a [generic parameter][generic]:
- `fn f<A: Copy>() {}` is the same as `fn f<A> where A: Copy () {}`.
+ `fn f<A: Copy>() {}` is the same as `fn f<A>() where A: Copy {}`.
* In trait declarations as [supertraits]: `trait Circle : Shape {}` is
equivalent to `trait Circle where Self : Shape {}`.
* In trait declarations as bounds on [associated types]: