From 4f9fe856a25ab29345b90e7725509e9ee38a37be Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Wed, 17 Apr 2024 14:19:41 +0200 Subject: Adding upstream version 1.69.0+dfsg1. Signed-off-by: Daniel Baumann --- .../reference/src/behavior-considered-undefined.md | 2 +- src/doc/reference/src/destructors.md | 2 +- src/doc/reference/src/expressions/if-expr.md | 2 +- src/doc/reference/src/expressions/operator-expr.md | 2 +- src/doc/reference/src/items/external-blocks.md | 2 + src/doc/reference/src/linkage.md | 2 +- src/doc/reference/src/patterns.md | 47 ++++++++++------------ src/doc/reference/src/trait-bounds.md | 2 +- 8 files changed, 30 insertions(+), 31 deletions(-) (limited to 'src/doc/reference') 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`, `&mut T` and `&T` follow LLVM’s scoped [noalias] model, except if the `&T` contains an [`UnsafeCell`]. 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: - + ```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 { > **Syntax**\ > _RangePattern_ :\ ->       _InclusiveRangePattern_\ ->    | _HalfOpenRangePattern_\ +>       _RangeInclusivePattern_\ +>    | _RangeFromPattern_\ +>    | _RangeToInclusivePattern_\ >    | _ObsoleteRangePattern_ > -> _InclusiveRangePattern_ :\ +> _RangeInclusivePattern_ :\ >       _RangePatternBound_ `..=` _RangePatternBound_ > -> _HalfOpenRangePattern_ :\ +> _RangeFromPattern_ :\ >       _RangePatternBound_ `..` ->    | `..=` _RangePatternBound_ +> +> _RangeToInclusivePattern_ :\ +>       `..=` _RangePatternBound_ > > _ObsoleteRangePattern_ :\ >    _RangePatternBound_ `...` _RangePatternBound_ @@ -402,16 +405,13 @@ match tuple { >    | [_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 ≤ 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() {}` is the same as `fn f where A: Copy () {}`. + `fn f() {}` is the same as `fn f() 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]: -- cgit v1.2.3