-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking issue for ..X
, and ..=X
(#![feature(half_open_range_patterns)]
)
#67264
Comments
Introduce `X..`, `..X`, and `..=X` range patterns Tracking issue: rust-lang#67264 Feature gate: `#![feature(half_open_range_patterns)]` --------------------------- In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns. These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds). --------------------------- Noteworthy: - The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size). - `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well. - `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov). - In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end). - Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR. - The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern. - Like with rust-lang#35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for rust-lang#35712 to finalize and confirm the ideas with the larger community. Closes rust-lang/rfcs#947. --------------------------- r? @varkor cc @matthewjasper @oli-obk I would recommend reviewing this (in particular HAIR-lowering and pattern parsing changes) with whitespace changes ignored.
Introduce `X..`, `..X`, and `..=X` range patterns Tracking issue: rust-lang#67264 Feature gate: `#![feature(half_open_range_patterns)]` --------------------------- In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns. These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds). --------------------------- Noteworthy: - The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size). - `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well. - `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov). - In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end). - Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR. - The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern. - Like with rust-lang#35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for rust-lang#35712 to finalize and confirm the ideas with the larger community. Closes rust-lang/rfcs#947. --------------------------- r? @varkor cc @matthewjasper @oli-obk I would recommend reviewing this (in particular HAIR-lowering and pattern parsing changes) with whitespace changes ignored.
Introduce `X..`, `..X`, and `..=X` range patterns Tracking issue: rust-lang#67264 Feature gate: `#![feature(half_open_range_patterns)]` --------------------------- In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns. These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds). --------------------------- Noteworthy: - The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size). - `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well. - `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov). - In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end). - Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR. - The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern. - Like with rust-lang#35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for rust-lang#35712 to finalize and confirm the ideas with the larger community. Closes rust-lang/rfcs#947. --------------------------- r? @varkor cc @matthewjasper @oli-obk I would recommend reviewing this (in particular HAIR-lowering and pattern parsing changes) with whitespace changes ignored.
Introduce `X..`, `..X`, and `..=X` range patterns Tracking issue: rust-lang#67264 Feature gate: `#![feature(half_open_range_patterns)]` --------------------------- In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns. These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds). --------------------------- Noteworthy: - The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size). - `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well. - `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov). - In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end). - Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR. - The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern. - Like with rust-lang#35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for rust-lang#35712 to finalize and confirm the ideas with the larger community. Closes rust-lang/rfcs#947. --------------------------- r? @varkor cc @matthewjasper @oli-obk I would recommend reviewing this (in particular HAIR-lowering and pattern parsing changes) with whitespace changes ignored.
Introduce `X..`, `..X`, and `..=X` range patterns Tracking issue: rust-lang#67264 Feature gate: `#![feature(half_open_range_patterns)]` --------------------------- In this PR, we introduce range-from (`X..`), range-to (`..X`), and range-to-inclusive (`..=X`) patterns. These correspond to the `RangeFrom`, `RangeTo`, and `RangeToInclusive` expression forms introduced with the same syntaxes. The correspondence is both syntactic and semantic (in the sense that e.g. a `X..` pattern matching on a scrutinee `s` holds exactly when `(X..).contains(&s)` holds). --------------------------- Noteworthy: - The compiler complexity added with this PR is around 10 lines (discounting new tests, which account for the large PR size). - `...X` is accepted syntactically with the same meaning as `..=X`. This is done primarily to simplify and unify the implementation & spec. If-and-when we decide to make `X...Y` a hard error on a new edition, we can do the same for `...X` patterns as well. - `X...` and `X..=` is rejected syntactically just like it is for the expression equivalents. We should perhaps make these into semantic restrictions (cc @petrochenkov). - In HAIR, these half-open ranges are represented by inserting the max/min values for the approprate types. That is, `X..` where `X: u8` would become `X..=u8::MAX` in HAIR (note the `..=` since `RangeFrom` includes the end). - Exhaustive integer / char matching does not (yet) allow for e.g. exhaustive matching on `0usize..` or `..5usize | 5..` (same idea for `isize`). This would be a substantially more invasive change, and could be added in some other PR. - The issues with slice pattern syntax has been resolved as we decided to use `..` to mean a "rest-pattern" and `[xs @ ..]` to bind the rest to a name in a slice pattern. - Like with rust-lang#35712, which provided `X..Y` range patterns, this is not yet backed up by an RFC. I'm providing this experimental implementation now to have something concrete to discuss. I would be happy to provide an RFC for this PR as well as for rust-lang#35712 to finalize and confirm the ideas with the larger community. Closes rust-lang/rfcs#947. --------------------------- r? @varkor cc @matthewjasper @oli-obk I would recommend reviewing this (in particular HAIR-lowering and pattern parsing changes) with whitespace changes ignored.
The implementation in #67258 landed on 2020-01-11. The PR was written by @Centril and reviewed by @oli-obk.
|
In #68120, which landed on 2020-01-11, the Everything should be well tested and implemented now. Once we have a new bootstrap compiler, we can start using it internally in the compiler, and eventually consider stabilization together with |
…=matthewjasper Stabilize `#![feature(slice_patterns)]` in 1.42.0 # Stabilization report The following is the stabilization report for `#![feature(slice_patterns)]`. This report is the collaborative effort of @matthewjasper and @Centril. Tracking issue: rust-lang#62254 [Version target](https://forge.rust-lang.org/#current-release-versions): 1.42 (2020-01-30 => beta, 2020-03-12 => stable). ## Backstory: slice patterns It is already possible to use slice patterns on stable Rust to match on arrays and slices. For example, to match on a slice, you may write: ```rust fn foo(slice: &[&str]) { match slice { [] => { dbg!() } [a] => { dbg!(a); } [a, b] => { dbg!(a, b); } _ => {} // ^ Fallback -- necessary because the length is unknown! } } ``` To match on an array, you may instead write: ```rust fn bar([a, b, c]: [u8; 3]) {} // --------- Length is known, so pattern is irrefutable. ``` However, on stable Rust, it is not yet possible to match on a subslice or subarray. ## A quick user guide: Subslice patterns The ability to match on a subslice or subarray is gated under `#![feature(slice_patterns)]` and is what is proposed for stabilization here. ### The syntax of subslice patterns Subslice / subarray patterns come in two flavors syntactically. Common to both flavors is they use the token `..`, referred as a *"rest pattern"* in a pattern context. This rest pattern functions as a variable-length pattern, matching whatever amount of elements that haven't been matched already before and after. When `..` is used syntactically as an element of a slice-pattern, either directly (1), or as part of a binding pattern (2), it becomes a subslice pattern. On stable Rust, a rest pattern `..` can also be used in a tuple or tuple-struct pattern with `let (x, ..) = (1, 2, 3);` and `let TS(x, ..) = TS(1, 2, 3);` respectively. ### (1) Matching on a subslice without binding it ```rust fn base(string: &str) -> u8 { match string.as_bytes() { [b'0', b'x', ..] => 16, [b'0', b'o', ..] => 8, [b'0', b'b', ..] => 2, _ => 10, } } fn main() { assert_eq!(base("0xFF"), 16); assert_eq!(base("0x"), 16); } ``` In the function `base`, the pattern `[b'0', b'x', ..]` will match on any byte-string slice with the *prefix* `0x`. Note that `..` may match on nothing, so `0x` is a valid match. ### (2) Binding a subslice: ```rust fn main() { #[derive(PartialEq, Debug)] struct X(u8); let xs: Vec<X> = vec![X(0), X(1), X(2)]; if let [start @ .., end] = &*xs { // --- bind on last element, assuming there is one. // ---------- bind the initial elements, if there are any. assert_eq!(start, &[X(0), X(1)] as &[X]); assert_eq!(end, &X(2)); let _: &[X] = start; let _: &X = end; } } ``` In this case, `[start @ .., end]` will match any non-empty slice, binding the last element to `end` and any elements before that to `start`. Note in particular that, as above, `start` may match on the empty slice. ### Only one `..` per slice pattern In today's stable Rust, a tuple (struct) pattern `(a, b, c)` can only have one subtuple pattern (e.g., `(a, .., c)`). That is, if there is a rest pattern, it may only occur once. Any `..` that follow, as in e.g., `(a, .., b, ..)` will cause an error, as there is no way for the compiler to know what `b` applies to. This rule also applies to slice patterns. That is, you may also not write `[a, .., b, ..]`. ## Motivation [PR rust-lang#67569]: https://github.com/rust-lang/rust/pull/67569/files Slice patterns provide a natural and efficient way to pattern match on slices and arrays. This is particularly useful as slices and arrays are quite a common occurence in modern software targeting modern hardware. However, as aforementioned, it's not yet possible to perform incomplete matches, which is seen in `fn base`, an example taken from the `rustc` codebase itself. This is where subslice patterns come in and extend slice patterns with the natural syntax `xs @ ..` and `..`, where the latter is already used for tuples and tuple structs. As an example of how subslice patterns can be used to clean up code, we have [PR rust-lang#67569]. In this PR, slice patterns enabled us to improve readability and reduce unsafety, at no loss to performance. ## Technical specification ### Grammar The following specification is a *sub-set* of the grammar necessary to explain what interests us here. Note that stabilizing subslice patterns does not alter the stable grammar. The stabilization contains purely semantic changes. ```rust Binding = reference:"ref"? mutable:"mut"? name:IDENT; Pat = | ... // elided | Rest: ".." | Binding:{ binding:Binding { "@" subpat:Pat }? } | Slice:{ "[" elems:Pat* %% "," "]" } | Paren:{ "(" pat:Pat ")" } | Tuple:{ path:Path? "(" elems:Pat* &% "," ")" } ; ``` Notes: 1. `(..)` is interpreted as a `Tuple`, not a `Paren`. This means that `[a, (..)]` is interpreted as `Slice[Binding(a), Tuple[Rest]]` and not `Slice[Binding(a), Paren(Rest)]`. ### Name resolution [resolve_pattern_inner]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.LateResolutionVisitor.html#method.resolve_pattern_inner [product context]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/enum.PatBoundCtx.html#variant.Product A slice pattern is [resolved][resolve_pattern_inner] as a [product context] and `..` is given no special treatment. ### Abstract syntax of slice patterns The abstract syntax (HIR level) is defined like so: ```rust enum PatKind { ... // Other unimportant stuff. Wild, Binding { binding: Binding, subpat: Option<Pat>, }, Slice { before: List<Pat>, slice: Option<Pat>, after: List<Pat>, }, } ``` [`hir::PatKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.PatKind.html The executable definition is found in [`hir::PatKind`]. ### Lowering to abstract syntax Lowering a slice pattern to its abstract syntax proceeds by: 1. Lowering each element pattern of the slice pattern, where: 1. `..` is lowered to `_`, recording that it was a subslice pattern, 2. `binding @ ..` is lowered to `binding @ _`, recording that it was a subslice pattern, 3. and all other patterns are lowered as normal, recording that it was not a subslice pattern. 2. Taking all lowered elements until the first subslice pattern. 3. Take all following elements. If there are any, 1. The head is the sub-`slice` pattern. 2. The tail (`after`) must not contain a subslice pattern, or an error occurs. [`LoweringContext::lower_pat_slice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/lowering/struct.LoweringContext.html#method.lower_pat_slice The full executable definition can be found in [`LoweringContext::lower_pat_slice`]. ### Type checking slice patterns #### Default binding modes [non-reference pattern]: https://doc.rust-lang.org/nightly/reference/patterns.html#binding-modes [`is_non_ref_pat`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.is_non_ref_pat [peel_off_references]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.peel_off_references A slice pattern is a [non-reference pattern] as defined in [`is_non_ref_pat`]. This means that when type checking a slice pattern, as many immediate reference types are [peeled off][peel_off_references] from the `expected` type as possible and the default binding mode is adjusted to by-reference before checking the slice pattern. See rust-lang#63118 for an algorithmic description. [RFC 2359]: https://github.com/rust-lang/rfcs/blob/master/text/2359-subslice-pattern-syntax.md [rfc-2359-gle]: https://github.com/rust-lang/rfcs/blob/master/text/2359-subslice-pattern-syntax.md#guide-level-explanation See [RFC 2359]'s [guide-level explanation][rfc-2359-gle] and the tests listed below for examples of what effect this has. #### Checking the pattern Type checking a slice pattern proceeds as follows: 1. Resolve any type variables by a single level. If the result still is a type variable, error. 2. Determine the expected type for any subslice pattern (`slice_ty`) and for elements (`inner_ty`) depending on the expected type. 1. If the expected type is an array (`[E; N]`): 1. Evaluate the length of the array. If the length couldn't be evaluated, error. This may occur when we have e.g., `const N: usize`. Now `N` is known. 2. If there is no sub-`slice` pattern, check `len(before) == N`, and otherwise error. 3. Otherwise, set `S = N - len(before) - len(after)`, and check `N >= 0` and otherwise error. Set `slice_ty = [E; S]`. Set `inner_ty = E`. 2. If the expected type is a slice (`[E]`), set `inner_ty = E` and `slice_ty = [E]`. 3. Otherwise, error. 3. Check each element in `before` and `after` against `inner_ty`. 4. If it exists, check `slice` against `slice_ty`. [`check_pat_slice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.check_pat_slice For an executable definition, see [`check_pat_slice`]. ### Typed abstract syntax of slice and array patterns The typed abstract syntax (HAIR level) is defined like so: ```rust enum PatKind { ... // Other unimportant stuff. Wild, Binding { ... // Elided. } Slice { prefix: List<Pat>, slice: Option<Pat>, suffix: List<Pat>, }, Array { prefix: List<Pat>, slice: Option<Pat>, suffix: List<Pat>, }, } ``` [`hair::pattern::PatKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/pattern/enum.PatKind.html The executable definition is found in [`hair::pattern::PatKind`]. ### Lowering to typed abstract syntax Lowering a slice pattern to its typed abstract syntax proceeds by: 1. Lowering each pattern in `before` into `prefix`. 2. Lowering the `slice`, if it exists, into `slice`. 1. A `Wild` pattern in abstract syntax is lowered to `Wild`. 2. A `Binding` pattern in abstract syntax is lowered to `Binding { .. }`. 3. Lowering each pattern in `after` into `after`. 4. If the type is `[E; N]`, construct `PatKind::Array { prefix, slice, after }`, otherwise `PatKind::Slice { prefix, slice, after }`. [`PatCtxt::slice_or_array_pattern`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/pattern/struct.PatCtxt.html#method.slice_or_array_pattern The executable definition is found in [`PatCtxt::slice_or_array_pattern`]. ### Exhaustiveness checking Let `E` be the element type of a slice or array. - For array types, `[E; N]` with a known length `N`, the full set of constructors required for an exahustive match is the sequence `ctors(E)^N` where `ctors` denotes the constructors required for an exhaustive match of `E`. - Otherwise, for slice types `[E]`, or for an array type with an unknown length `[E; ?L]`, the full set of constructors is the infinite sequence `⋃_i=0^∞ ctors(E)^i`. This entails that an exhaustive match without a cover-all pattern (e.g. `_` or `binding`) or a subslice pattern (e.g., `[..]` or `[_, _, ..]`) is impossible. - `PatKind::{Slice, Array}(prefix, None, suffix @ [])` cover a sequence of of `len(prefix)` covered by `patterns`. Note that `suffix.len() > 0` with `slice == None` is unrepresentable. - `PatKind::{Slice, Array}(prefix, Some(s), suffix)` cover a `sequence` with `prefix` as the start and `suffix` as the end and where `len(prefix) + len(suffix) <= len(sequence)`. The `..` in the middle is interpreted as an unbounded number of `_`s in terms of exhaustiveness checking. ### MIR representation The relevant MIR representation for the lowering into MIR, which is discussed in the next section, includes: ```rust enum Rvalue { // ... /// The length of a `[X]` or `[X; N]` value. Len(Place), } struct Place { base: PlaceBase, projection: List<PlaceElem>, } enum ProjectionElem { // ... ConstantIndex { offset: Nat, min_length: Nat, from_end: bool, }, Subslice { from: Nat, to: Nat, from_end: bool, }, } ``` ### Lowering to MIR * For a slice pattern matching a slice, where the pattern has `N` elements specified, there is a check that the `Rvalue::Len` of the slice is at least `N` to decide if the pattern can match. * There are two kinds of `ProjectionElem` used for slice patterns: 1. `ProjectionElem::ConstantIndex` is an array or slice element with a known index. As a shorthand it's written `base[offset of min_length]` if `from_end` is false and `base[-offset of min_length]` if `from_end` is true. `base[-offset of min_length]` is the `len(base) - offset`th element of `base`. 2. `ProjectionElem::Subslice` is a subslice of an array or slice with known bounds. As a shorthand it's written `base[from..to]` if `from_end` is false and `base[from:-to]` if `from_end` is true. `base[from:-to]` is the subslice `base[from..len(base) - to]`. * Note that `ProjectionElem::Index` is used for indexing expressions, but not for slice patterns. It's written `base[idx]`. * When binding an array pattern, any individual element binding is lowered to an assignment or borrow of `base[offset of len]` where `offset` is the element's index in the array and `len` is the array's length. * When binding a slice pattern, let `N` be the number of elements that have patterns. Elements before the subslice pattern (`prefix`) are lowered to `base[offset of N]` where `offset` is the element's index from the start. Elements after the subslice pattern (`suffix`) are lowered to `base[-offset of N]` where `offset` is the element's index from the end, plus 1. * Subslices of arrays are lowered to `base[from..to]` where `from` is the number of elements before the subslice pattern and `to = len(array) - len(suffix)` is the length of the array minus the number of elements after the subslice pattern. * Subslices of slices are lowered to `base[from:-to]` where `from` is the number of elements before the subslice pattern (`len(prefix)`) and `to` is the number of elements after the subslice pattern (`len(suffix)`). ### Safety and const checking * Subslice patterns do not introduce any new unsafe operations. * As subslice patterns for arrays are irrefutable, they are allowed in const contexts. As are `[..]` and `[ref y @ ..]` patterns for slices. However, `ref mut` bindings are only allowed with `feature(const_mut_refs)` for now. * As other subslice patterns for slices require a `match`, `if let`, or `while let`, they are only allowed with `feature(const_if_match, const_fn)` for now. * Subslice patterns may occur in promoted constants. ### Borrow and move checking * A subslice pattern can be moved from if it has an array type `[E; N]` and the parent array can be moved from. * Moving from an array subslice pattern moves from all of the elements of the array within the subslice. * If the subslice contains at least one element, this means that dynamic indexing (`arr[idx]`) is no longer allowed on the array. * The array can be reinitialized and can still be matched with another slice pattern that uses a disjoint set of elements. * A subslice pattern can be mutably borrowed if the parent array/slice can be mutably borrowed. * When determining whether an access conflicts with a borrow and at least one is a slice pattern: * `x[from..to]` always conflicts with `x` and `x[idx]` (where `idx` is a variable). * `x[from..to]` conflicts with `x[idx of len]` if `from <= idx` and `idx < to` (that is, `idx ∈ from..to`). * `x[from..to]` conflicts with `x[from2..to2]` if `from < to2` and `from2 < to` (that is, `(from..to) ∩ (from2..to2) ≠ ∅`). * `x[from:-to]` always conflicts with `x`, `x[idx]`, and `x[from2:-to2]`. * `x[from:-to]` conflicts with `x[idx of len]` if `from <= idx`. * `x[from:-to]` conflicts with `x[-idx of len]` if `to < idx`. * A constant index from the end conflicts with other elements as follows: * `x[-idx of len]` always conflicts with `x` and `x[idx]`. * `x[-idx of len]` conflicts with `x[-idx2 of len2]` if `idx == idx2`. * `x[-idx of len]` conflicts with `x[idx2 of len2]` if `idx + idx2 >= max(len, len2)`. ## Tests The tests can be primarily seen in the PR itself. Here are some of them: ### Parsing (3) * Testing that `..` patterns are syntactically allowed in all pattern contexts (2) * [pattern/rest-pat-syntactic.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/rest-pat-syntactic.rs) * [ignore-all-the-things.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/ignore-allthe-things.rs) * Slice patterns allow a trailing comma, including after `..` (1) * [trailing-comma.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/trailing-comma.rs) ### Lowering (2) * `@ ..` isn't allowed outside of slice patterns and only allowed once in each pattern (1) * [pattern/rest-pat-semantic-disallowed.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/rest-pat-semantic-disallowed.rs) * Mulitple `..` patterns are not allowed (1) * [parser/match-vec-invalid.rs](https://github.com/rust-lang/rust/blob/53712f8637dbe326df569a90814aae1cc5429710/src/test/ui/parser/match-vec-invalid.rs) ### Type checking (5) * Default binding modes apply to slice patterns (2) * [rfc-2005-default-binding-mode/slice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/rfc-2005-default-binding-mode/slice.rs) * [rfcs/rfc-2005-default-binding-mode/slice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/rfcs/rfc-2005-default-binding-mode/slice.rs) * Array patterns cannot have more elements in the pattern than in the array (2) * [match/match-vec-mismatch.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/match/match-vec-mismatch.rs) * [error-codes/E0528.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/error-codes/E0528.rs) * Array subslice patterns have array types (1) * [array-slice-vec/subslice-patterns-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-pass.rs) ### Exhaustiveness and usefulness checking (20) * Large subslice matches don't stack-overflow the exhaustiveness checker (1) * [pattern/issue-53820-slice-pattern-large-array.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/issue-53820-slice-pattern-large-array.rs) * Array patterns with subslices are irrefutable (1) * [issues/issue-7784.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-7784.rs) * `[xs @ ..]` slice patterns are irrefutable (1) * [binding/irrefutable-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/irrefutable-slice-patterns.rs) * Subslice patterns can match zero-length slices (2) * [issues/issue-15080.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-15080.rs) * [issues/issue-15104.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-15104.rs) * General tests (13) * [issues/issue-12369.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-12369.rs) * [issues/issue-37598.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-37598.rs) * [pattern/usefulness/match-vec-unreachable.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/match-vec-unreachable.rs) * [pattern/usefulness/non-exhaustive-match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/non-exhaustive-match.rs) * [pattern/usefulness/non-exhaustive-match-nested.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/non-exhaustive-match-nested.rs) * [pattern/usefulness/non-exhaustive-pattern-witness.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/non-exhaustive-pattern-witness.rs) * [pattern/usefulness/65413-constants-and-slices-exhaustiveness.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/65413-constants-and-slices-exhaustiveness.rs) * [pattern/usefulness/match-byte-array-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/match-byte-array-patterns.rs) * [pattern/usefulness/match-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/match-slice-patterns.rs) * [pattern/usefulness/slice-patterns-exhaustiveness.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/slice-patterns-exhaustiveness.rs) * [pattern/usefulness/slice-patterns-irrefutable.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/slice-patterns-irrefutable.rs) * [pattern/usefulness/slice-patterns-reachability.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/slice-patterns-reachability.rs) * [uninhabited/uninhabited-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/uninhabited/uninhabited-patterns.rs) * Interactions with or-patterns (2) * [or-patterns/exhaustiveness-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/or-patterns/exhaustiveness-pass.rs) * [or-patterns/exhaustiveness-unreachable-pattern.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/or-patterns/exhaustiveness-unreachable-pattern.rs) ### Borrow checking (28) * Slice patterns can only move from owned, fixed-length arrays (4) * [borrowck/borrowck-move-out-of-vec-tail.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-of-vec-tail.rs) * [moves/move-out-of-slice-2.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/moves/move-out-of-slice-2.rs) * [moves/move-out-of-array-ref.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/moves/move-out-of-array-ref.rs) * [issues/issue-12567.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-12567.rs) * Moves from arrays are tracked by element (2) * [borrowck/borrowck-move-out-from-array-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array-no-overlap.rs) * [borrowck/borrowck-move-out-from-array-use-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array-use-no-overlap.rs) * Slice patterns cannot be used on moved-from slices/arrays (2) * [borrowck/borrowck-move-out-from-array.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array.rs) * [borrowck/borrowck-move-out-from-array-use.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array-use.rs) * Slice patterns cannot be used with conflicting borrows (3) * [borrowck/borrowck-describe-lvalue.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-describe-lvalue.rs) * [borrowck/borrowck-slice-pattern-element-loan-array.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-array.rs) * [borrowck/borrowck-slice-pattern-element-loan-slice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-slice.rs) * Borrows from slice patterns are tracked and only conflict when there is possible overlap (6) * [borrowck/borrowck-slice-pattern-element-loan-array-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-array-no-overlap.rs) * [borrowck/borrowck-slice-pattern-element-loan-slice-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-slice-no-overlap.rs) * [borrowck/borrowck-slice-pattern-element-loan-rpass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-rpass.rs) * [borrowck/borrowck-vec-pattern-element-loan.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-element-loan.rs) * [borrowck/borrowck-vec-pattern-loan-from-mut.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-loan-from-mut.rs) * [borrowck/borrowck-vec-pattern-tail-element-loan.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-tail-element-loan.rs) * Slice patterns affect indexing expressions (1) * [borrowck/borrowck-vec-pattern-move-tail.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-move-tail.rs) * Borrow and move interactions with `box` patterns (1) * [borrowck/borrowck-vec-pattern-move-tail.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-move-tail.rs) * Slice patterns correctly affect inference of closure captures (2) * [borrowck/borrowck-closures-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-closures-slice-patterns.rs) * [borrowck/borrowck-closures-slice-patterns-ok.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-closures-slice-patterns-ok.rs) * Interactions with `#![feature(bindings_after_at)]` (7) * [pattern/bindings-after-at/borrowck-move-and-move.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-move-and-move.rs) * [pattern/bindings-after-at/borrowck-pat-at-and-box-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-at-and-box-pass.rs) * [pattern/bindings-after-at/borrowck-pat-at-and-box.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-at-and-box.rs) * [pattern/bindings-after-at/borrowck-pat-by-copy-bindings-in-at.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-by-copy-bindings-in-at.rs) * [pattern/bindings-after-at/borrowck-pat-ref-both-sides.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-ref-both-sides.rs) * [pattern/bindings-after-at/borrowck-pat-ref-mut-and-ref.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-ref-mut-and-ref.rs) * [pattern/bindings-after-at/borrowck-pat-ref-mut-twice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-ref-mut-twice.rs) * Misc (1) * [issues/issue-26619.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-26619.rs) ### MIR lowering (1) * [uniform_array_move_out.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/mir-opt/uniform_array_move_out.rs) ### Evaluation (19) * Slice patterns don't cause leaks or double drops (2) * [drop/dynamic-drop.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/drop/dynamic-drop.rs) * [drop/dynamic-drop-async.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/drop/dynamic-drop-async.rs) * General run-pass tests (10) * [array-slice-vec/subslice-patterns-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-pass.rs) * [array-slice-vec/vec-matching-fixed.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching-fixed.rs) * [array-slice-vec/vec-matching-fold.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching-fold.rs) * [array-slice-vec/vec-matching-legal-tail-element-borrow.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching-legal-tail-element-borrow.rs) * [array-slice-vec/vec-matching.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching.rs) * [array-slice-vec/vec-tail-matching.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-tail-matching.rs) * [binding/irrefutable-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/irrefutable-slice-patterns.rs) * [binding/match-byte-array-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/match-byte-array-patterns.rs) * [binding/match-vec-alternatives.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/match-vec-alternatives.rs) * [borrowck/borrowck-slice-pattern-element-loan-rpass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-rpass.rs) * Matching a large by-value array (1) * [issues/issue-17877.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-17877.rs) * Uninhabited elements (1) * [binding/empty-types-in-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/empty-types-in-patterns.rs) * Zero-sized elements (3) * [binding/zero_sized_subslice_match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/zero_sized_subslice_match.rs) * [array-slice-vec/subslice-patterns-const-eval.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval.rs) * [array-slice-vec/subslice-patterns-const-eval-match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval-match.rs) * Evaluation in const contexts (2) * [array-slice-vec/subslice-patterns-const-eval.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval.rs) * [array-slice-vec/subslice-patterns-const-eval-match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval-match.rs) ## Misc (1) * Exercising a case where const-prop cased an ICE (1) * [consts/const_prop_slice_pat_ice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/consts/const_prop_slice_pat_ice.rs) ## History - 2012-12-08, commit rust-lang@1968cb3 Author: Jakub Wieczorek Reviewers: @graydon This is where slice patterns were first implemented. It is particularly instructive to read the `vec-tail-matching.rs` test. - 2013-08-20, issue rust-lang#8636 Author: @huonw Fixed by @mikhail-m1 in rust-lang#51894 The issue describes a problem wherein the borrow-checker would not consider disjointness when checking mutable references in slice patterns. - 2014-09-03, RFC rust-lang/rfcs#164 Author: @brson Reviewers: The Core Team The RFC decided to feature gate slice patterns due to concerns over lack of oversight and the exhaustiveness checking logic not having seen much love. Since then, the exhaustivenss checking algorithm, in particular for slice patterns, has been substantially refactored and tests have been added. - 2014-09-03, RFC rust-lang/rfcs#202 Author: @krdln Reviewers: The Core Team > Change syntax of subslices matching from `..xs` to `xs..` to be more consistent with the rest of the language and allow future backwards compatible improvements. In 2019, rust-lang/rfcs#2359 changed the syntax again in favor of `..` and `xs @ ..`. - 2014-09-08, PR rust-lang#17052 Author: @pcwalton Reviewers: @alexcrichton and @sfackler This implemented the feature gating as specified in rust-lang/rfcs#164. - 2015-03-06, RFC rust-lang/rfcs#495 Author: @P1start Reviewers: The Core Team The RFC changed array and slice patterns like so: - Made them only match on arrays (`[T; N]`) and slice types (`[T]`), not references to slice types (`& mut? [T]`). - Made subslice matching yield a value of type `[T; N]` or `[T]`, not `& mut? [T]`. - Allowed multiple mutable references to be made to different parts of the same array or slice in array patterns. These changes were made to fit with the introduction of DSTs like `[T]` as well as with e.g. `box [a, b, c]` (`Box<[T]>`) in the future. All points remain true today, in particular with the advent of default binding modes. - 2015-03-22, PR rust-lang#23361 Author: @petrochenkov Reviewers: Unknown The PR adjusted codegen ("trans") such that `let ref a = *"abcdef"` would no longer ICE, paving the way for rust-lang/rfcs#495. - 2015-05-28, PR rust-lang#23794 Author: @brson Reviewers: @nrc The PR feature gated slice patterns in more contexts. - 2016-06-09, PR rust-lang#32202 Author: @arielb1 Reviewers: @eddyb and @nikomatsakis This implemented RFC rust-lang/rfcs#495 via a MIR based implementation fixing some bugs. - 2016-09-16, PR rust-lang#36353 Author: @arielb1 Reviewers: @nagisa, @pnkfelix, and @nikomatsakis The PR made move-checker improvements prohibiting moves out of slices. - 2018-02-17, PR rust-lang#47926 Author: @mikhail-m1 Reviewers: @nikomatsakis This added the `UniformArrayMoveOut` which converted move-out-from-array by `Subslice` and `ConstIndex {.., from_end: true }` to `ConstIndex` move out(s) from the beginning of the array. This fixed some problems with the MIR borrow-checker and drop-elaboration of arrays. Unfortunately, the transformation ultimately proved insufficient for soundness and was removed and replaced in rust-lang#66650. - 2018-02-19, PR rust-lang#48355 Author: @mikhail-m1 Reviewers: @nikomatsakis After rust-lang#47926, this restored some MIR optimizations after drop-elaboration and borrow-checking. - 2018-03-20, PR rust-lang#48516 Author: @petrochenkov Reviewers: @nikomatsakis This stabilized fixed length slice patterns `[a, b, c]` without variable length subslices and moved subslice patterns into `#![feature(slice_patterns)`. See rust-lang#48836 wherein the language team accepted the proposal to stabilize. - 2018-07-06, PR rust-lang#51894 Author: @mikhail-m1 Reviewers: @nikomatsakis rust-lang#8636 was fixed such that the borrow-checker would consider disjointness with respect to mutable references in slice patterns. - 2019-06-30, RFC rust-lang/rfcs#2359 Author: @petrochenkov Reviewers: The Language Team The RFC switched the syntax of subslice patterns to `{$binding @}? ..` as opposed to `.. $pat?` (which was what the RFC originally proposed). This RFC reignited the work towards finishing the implementation and the testing of slice patterns which eventually lead to this stabilization proposal. - 2019-06-30, RFC rust-lang/rfcs#2707 Author: @petrochenkov Reviewers: The Language Team This RFC built upon rust-lang/rfcs#2359 turning `..` into a full-fledged pattern (`Pat |= Rest:".." ;`), as opposed to a special part of slice and tuple patterns, moving previously syntactic restrictions into semantic ones. - 2019-07-03, PR rust-lang#62255 Author: @Centril Reviewers: @varkor This closed the old tracking issue (rust-lang#23121) in favor of the new one (rust-lang#62254) due to the new RFCs having been accepted. - 2019-07-28, PR rust-lang#62550 Author: @Centril Reviewers: @petrochenkov and @eddyb Implemented RFCs rust-lang/rfcs#2707 and rust-lang/rfcs#2359 by introducing the `..` syntactic rest pattern form as well as changing the lowering to subslice and subtuple patterns and the necessary semantic restrictions as per the RFCs. Moreover, the parser was cleaned up to use a more generic framework for parsing sequences of things. This framework was employed in parsing slice patterns. Finally, the PR introduced parser recovery for half-open ranges (e.g., `..X`, `..=X`, and `X..`), demonstrating in practice that the RFCs proposed syntax will enable half-open ranges if we want to add those (which is done in rust-lang#67258). - 2019-07-30, PR rust-lang#63111 Author: @Centril Reviewers: @estebank Added a test which comprehensively exercised the parsing of `..` rest patterns. That is, the PR exercised the specification in rust-lang/rfcs#2707. Moreover, a test was added for the semantic restrictions noted in the RFC. - 2019-07-31, PR rust-lang#63129 Author: @Centril Reviewers: @oli-obk Hardened the test-suite for subslice and subarray patterns with a run-pass tests. This test exercises both type checking and dynamic semantics. - 2019-09-15, PR rust-lang/rust-analyzer#1848 Author: @ecstatic-morse Reviewers: @matklad This implemented the syntactic change (rest patterns, `..`) in rust-analyzer. - 2019-11-05, PR rust-lang#65874 Author: @Nadrieril Reviewers: @varkor, @arielb1, and @Centril Usefulness / exhaustiveness checking saw a major refactoring clarifying the analysis by emphasizing that each row of the matrix can be seen as a sort of stack from which we pop constructors. - 2019-11-12, PR rust-lang#66129 Author: @Nadrieril Reviewers: @varkor, @Centril, and @estebank Usefulness / exhaustiveness checking of slice patterns were refactored in favor of clearer code. Before the PR, variable-length slice patterns were eagerly expanded into a union of fixed-length slices. They now have their own special constructor, which allows expanding them more lazily. As a side-effect, this improved diagnostics. Moreover, the test suite for exhaustiveness checking of slice patterns was hardened. - 2019-11-20, PR rust-lang#66497 Author: @Nadrieril Reviewers: @varkor and @Centril Building on the previous PR, this one fixed a bug rust-lang#53820 wherein sufficiently large subarray patterns (`match [0u8; 16*1024] { [..] => {}}`) would result in crashing the compiler with a stack-overflow. The PR did this by treating array patterns in a more first-class way (using a variable-length mechanism also used for slices) rather than like large tuples. This also had the effect of improving diagnostics for non-exhaustive matches. - 2019-11-28, PR rust-lang#66603 Author: @Nadrieril Reviewers: @varkor Fixed a bug rust-lang#65413 wherein constants, slice patterns, and exhaustiveness checking interacted in a suboptimal way conspiring to suggest that a reachable arm was in fact unreachable. - 2019-12-12, PR rust-lang#66650 Author: @matthewjasper Reviewers: @pnkfelix and @Centril Removed the `UniformArrayMoveOut` MIR transformation pass in favor of baking the necessary logic into the borrow-checker, drop elaboration and MIR building itself. This fixed a number of bugs, including a soundness hole rust-lang#66502. Moreover, the PR added a slew of tests for borrow- and move-checking of slice patterns as well as a test for the dynamic semantics of dropping subslice patterns. - 2019-12-16, PR rust-lang#67318 Author: @Centril Reviewers: @matthewjasper Improved documentation for AST->HIR lowering + type checking of slice as well as minor code simplification. - 2019-12-21, PR rust-lang#67467 Author: @matthewjasper Reviewers: @oli-obk, @RalfJung, and @Centril Fixed bugs in the const evaluation of slice patterns and added tests for const evaluation as well as borrow- and move-checking. - 2019-12-22, PR rust-lang#67439 Author: @Centril Reviewers: @matthewjasper Cleaned up HAIR lowering of slice patterns, removing special cased dead code for the unrepresentable `[a, b] @ ..`. The PR also refactored type checking for slice patterns. - 2019-12-23, PR rust-lang#67546 Author: @oli-obk Reviewers: @varkor and @RalfJung Fixed an ICE in the MIR interpretation of slice patterns. - 2019-12-24, PR rust-lang#66296 Author: @Centril Reviewers: @pnkfelix and @matthewjasper This implemented `#![feature(bindings_after_at)]` which allows writing e.g. `a @ Some([_, b @ ..])`. This is not directly linked to slice patterns other than with patterns in general. However, the combination of the feature and `slice_patterns` received some testing in the PR. - 2020-01-09, PR rust-lang#67990 Author: @Centril Reviewers: @matthewjasper This hardened move-checker tests for `match` expressions in relation to rust-lang#53114. - This PR stabilizes `slice_patterns`. ## Related / possible future work There is on-going work to improve pattern matching in other ways (the relevance of some of these are indirect, and only by composition): - OR-patterns, `pat_0 | .. | pat_n` is almost implemented. Tracking issue: rust-lang#54883 - Bindings after `@`, e.g., `x @ Some(y)` is implemented. Tracking issue: rust-lang#65490 - Half-open range patterns, e.g., `X..`, `..X`, and `..=X` as well as exclusive range patterns, e.g., `X..Y`. Tracking issue: rust-lang#67264 and rust-lang#37854 The relevance here is that this work demonstrates, in practice, that there are no syntactic conflicts introduced by the stabilization of subslice patterns. As for more direct improvements to slice patterns, some avenues could be: - Box patterns, e.g., `box [a, b, .., c]` to match on `Box<[T]>`. Tracking issue: rust-lang#29641 This issue currently has no path to stabilization. Note that it is currently possible to match on `Box<[T]>` or `Vec<T>` by first dereferencing them to slices. - `DerefPure`, which would allow e.g., using slice patterns to match on `Vec<T>` (e.g., moving out of it). Another idea which was raised by [RFC 2707](https://github.com/rust-lang/rfcs/blob/master/text/2707-dotdot-patterns.md#future-possibilities) and [RFC 2359](https://github.com/rust-lang/rfcs/blob/master/text/2359-subslice-pattern-syntax.md#pat-vs-pat) was to allow binding a subtuple pattern. That is, we could allow `(a, xs @ .., b)`. However, while we could allow by-value bindings to `..` as in `xs @ ..` at zero cost, the same cannot be said of by-reference bindings, e.g. `(a, ref xs @ .., b)`. The issue here becomes that for a reference to be legal, we have to represent `xs` contiguously in memory. In effect, we are forced into a [`HList`](https://docs.rs/frunk/0.3.1/frunk/hlist/struct.HCons.html) based representation for tuples.
…=matthewjasper Stabilize `#![feature(slice_patterns)]` in 1.42.0 # Stabilization report The following is the stabilization report for `#![feature(slice_patterns)]`. This report is the collaborative effort of @matthewjasper and @Centril. Tracking issue: rust-lang#62254 [Version target](https://forge.rust-lang.org/#current-release-versions): 1.42 (2020-01-30 => beta, 2020-03-12 => stable). ## Backstory: slice patterns It is already possible to use slice patterns on stable Rust to match on arrays and slices. For example, to match on a slice, you may write: ```rust fn foo(slice: &[&str]) { match slice { [] => { dbg!() } [a] => { dbg!(a); } [a, b] => { dbg!(a, b); } _ => {} // ^ Fallback -- necessary because the length is unknown! } } ``` To match on an array, you may instead write: ```rust fn bar([a, b, c]: [u8; 3]) {} // --------- Length is known, so pattern is irrefutable. ``` However, on stable Rust, it is not yet possible to match on a subslice or subarray. ## A quick user guide: Subslice patterns The ability to match on a subslice or subarray is gated under `#![feature(slice_patterns)]` and is what is proposed for stabilization here. ### The syntax of subslice patterns Subslice / subarray patterns come in two flavors syntactically. Common to both flavors is they use the token `..`, referred as a *"rest pattern"* in a pattern context. This rest pattern functions as a variable-length pattern, matching whatever amount of elements that haven't been matched already before and after. When `..` is used syntactically as an element of a slice-pattern, either directly (1), or as part of a binding pattern (2), it becomes a subslice pattern. On stable Rust, a rest pattern `..` can also be used in a tuple or tuple-struct pattern with `let (x, ..) = (1, 2, 3);` and `let TS(x, ..) = TS(1, 2, 3);` respectively. ### (1) Matching on a subslice without binding it ```rust fn base(string: &str) -> u8 { match string.as_bytes() { [b'0', b'x', ..] => 16, [b'0', b'o', ..] => 8, [b'0', b'b', ..] => 2, _ => 10, } } fn main() { assert_eq!(base("0xFF"), 16); assert_eq!(base("0x"), 16); } ``` In the function `base`, the pattern `[b'0', b'x', ..]` will match on any byte-string slice with the *prefix* `0x`. Note that `..` may match on nothing, so `0x` is a valid match. ### (2) Binding a subslice: ```rust fn main() { #[derive(PartialEq, Debug)] struct X(u8); let xs: Vec<X> = vec![X(0), X(1), X(2)]; if let [start @ .., end] = &*xs { // --- bind on last element, assuming there is one. // ---------- bind the initial elements, if there are any. assert_eq!(start, &[X(0), X(1)] as &[X]); assert_eq!(end, &X(2)); let _: &[X] = start; let _: &X = end; } } ``` In this case, `[start @ .., end]` will match any non-empty slice, binding the last element to `end` and any elements before that to `start`. Note in particular that, as above, `start` may match on the empty slice. ### Only one `..` per slice pattern In today's stable Rust, a tuple (struct) pattern `(a, b, c)` can only have one subtuple pattern (e.g., `(a, .., c)`). That is, if there is a rest pattern, it may only occur once. Any `..` that follow, as in e.g., `(a, .., b, ..)` will cause an error, as there is no way for the compiler to know what `b` applies to. This rule also applies to slice patterns. That is, you may also not write `[a, .., b, ..]`. ## Motivation [PR rust-lang#67569]: https://github.com/rust-lang/rust/pull/67569/files Slice patterns provide a natural and efficient way to pattern match on slices and arrays. This is particularly useful as slices and arrays are quite a common occurence in modern software targeting modern hardware. However, as aforementioned, it's not yet possible to perform incomplete matches, which is seen in `fn base`, an example taken from the `rustc` codebase itself. This is where subslice patterns come in and extend slice patterns with the natural syntax `xs @ ..` and `..`, where the latter is already used for tuples and tuple structs. As an example of how subslice patterns can be used to clean up code, we have [PR rust-lang#67569]. In this PR, slice patterns enabled us to improve readability and reduce unsafety, at no loss to performance. ## Technical specification ### Grammar The following specification is a *sub-set* of the grammar necessary to explain what interests us here. Note that stabilizing subslice patterns does not alter the stable grammar. The stabilization contains purely semantic changes. ```rust Binding = reference:"ref"? mutable:"mut"? name:IDENT; Pat = | ... // elided | Rest: ".." | Binding:{ binding:Binding { "@" subpat:Pat }? } | Slice:{ "[" elems:Pat* %% "," "]" } | Paren:{ "(" pat:Pat ")" } | Tuple:{ path:Path? "(" elems:Pat* &% "," ")" } ; ``` Notes: 1. `(..)` is interpreted as a `Tuple`, not a `Paren`. This means that `[a, (..)]` is interpreted as `Slice[Binding(a), Tuple[Rest]]` and not `Slice[Binding(a), Paren(Rest)]`. ### Name resolution [resolve_pattern_inner]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/struct.LateResolutionVisitor.html#method.resolve_pattern_inner [product context]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_resolve/late/enum.PatBoundCtx.html#variant.Product A slice pattern is [resolved][resolve_pattern_inner] as a [product context] and `..` is given no special treatment. ### Abstract syntax of slice patterns The abstract syntax (HIR level) is defined like so: ```rust enum PatKind { ... // Other unimportant stuff. Wild, Binding { binding: Binding, subpat: Option<Pat>, }, Slice { before: List<Pat>, slice: Option<Pat>, after: List<Pat>, }, } ``` [`hir::PatKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/enum.PatKind.html The executable definition is found in [`hir::PatKind`]. ### Lowering to abstract syntax Lowering a slice pattern to its abstract syntax proceeds by: 1. Lowering each element pattern of the slice pattern, where: 1. `..` is lowered to `_`, recording that it was a subslice pattern, 2. `binding @ ..` is lowered to `binding @ _`, recording that it was a subslice pattern, 3. and all other patterns are lowered as normal, recording that it was not a subslice pattern. 2. Taking all lowered elements until the first subslice pattern. 3. Take all following elements. If there are any, 1. The head is the sub-`slice` pattern. 2. The tail (`after`) must not contain a subslice pattern, or an error occurs. [`LoweringContext::lower_pat_slice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/hir/lowering/struct.LoweringContext.html#method.lower_pat_slice The full executable definition can be found in [`LoweringContext::lower_pat_slice`]. ### Type checking slice patterns #### Default binding modes [non-reference pattern]: https://doc.rust-lang.org/nightly/reference/patterns.html#binding-modes [`is_non_ref_pat`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.is_non_ref_pat [peel_off_references]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.peel_off_references A slice pattern is a [non-reference pattern] as defined in [`is_non_ref_pat`]. This means that when type checking a slice pattern, as many immediate reference types are [peeled off][peel_off_references] from the `expected` type as possible and the default binding mode is adjusted to by-reference before checking the slice pattern. See rust-lang#63118 for an algorithmic description. [RFC 2359]: https://github.com/rust-lang/rfcs/blob/master/text/2359-subslice-pattern-syntax.md [rfc-2359-gle]: https://github.com/rust-lang/rfcs/blob/master/text/2359-subslice-pattern-syntax.md#guide-level-explanation See [RFC 2359]'s [guide-level explanation][rfc-2359-gle] and the tests listed below for examples of what effect this has. #### Checking the pattern Type checking a slice pattern proceeds as follows: 1. Resolve any type variables by a single level. If the result still is a type variable, error. 2. Determine the expected type for any subslice pattern (`slice_ty`) and for elements (`inner_ty`) depending on the expected type. 1. If the expected type is an array (`[E; N]`): 1. Evaluate the length of the array. If the length couldn't be evaluated, error. This may occur when we have e.g., `const N: usize`. Now `N` is known. 2. If there is no sub-`slice` pattern, check `len(before) == N`, and otherwise error. 3. Otherwise, set `S = N - len(before) - len(after)`, and check `N >= 0` and otherwise error. Set `slice_ty = [E; S]`. Set `inner_ty = E`. 2. If the expected type is a slice (`[E]`), set `inner_ty = E` and `slice_ty = [E]`. 3. Otherwise, error. 3. Check each element in `before` and `after` against `inner_ty`. 4. If it exists, check `slice` against `slice_ty`. [`check_pat_slice`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/check/struct.FnCtxt.html#method.check_pat_slice For an executable definition, see [`check_pat_slice`]. ### Typed abstract syntax of slice and array patterns The typed abstract syntax (HAIR level) is defined like so: ```rust enum PatKind { ... // Other unimportant stuff. Wild, Binding { ... // Elided. } Slice { prefix: List<Pat>, slice: Option<Pat>, suffix: List<Pat>, }, Array { prefix: List<Pat>, slice: Option<Pat>, suffix: List<Pat>, }, } ``` [`hair::pattern::PatKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/pattern/enum.PatKind.html The executable definition is found in [`hair::pattern::PatKind`]. ### Lowering to typed abstract syntax Lowering a slice pattern to its typed abstract syntax proceeds by: 1. Lowering each pattern in `before` into `prefix`. 2. Lowering the `slice`, if it exists, into `slice`. 1. A `Wild` pattern in abstract syntax is lowered to `Wild`. 2. A `Binding` pattern in abstract syntax is lowered to `Binding { .. }`. 3. Lowering each pattern in `after` into `after`. 4. If the type is `[E; N]`, construct `PatKind::Array { prefix, slice, after }`, otherwise `PatKind::Slice { prefix, slice, after }`. [`PatCtxt::slice_or_array_pattern`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/hair/pattern/struct.PatCtxt.html#method.slice_or_array_pattern The executable definition is found in [`PatCtxt::slice_or_array_pattern`]. ### Exhaustiveness checking Let `E` be the element type of a slice or array. - For array types, `[E; N]` with a known length `N`, the full set of constructors required for an exahustive match is the sequence `ctors(E)^N` where `ctors` denotes the constructors required for an exhaustive match of `E`. - Otherwise, for slice types `[E]`, or for an array type with an unknown length `[E; ?L]`, the full set of constructors is the infinite sequence `⋃_i=0^∞ ctors(E)^i`. This entails that an exhaustive match without a cover-all pattern (e.g. `_` or `binding`) or a subslice pattern (e.g., `[..]` or `[_, _, ..]`) is impossible. - `PatKind::{Slice, Array}(prefix, None, suffix @ [])` cover a sequence of of `len(prefix)` covered by `patterns`. Note that `suffix.len() > 0` with `slice == None` is unrepresentable. - `PatKind::{Slice, Array}(prefix, Some(s), suffix)` cover a `sequence` with `prefix` as the start and `suffix` as the end and where `len(prefix) + len(suffix) <= len(sequence)`. The `..` in the middle is interpreted as an unbounded number of `_`s in terms of exhaustiveness checking. ### MIR representation The relevant MIR representation for the lowering into MIR, which is discussed in the next section, includes: ```rust enum Rvalue { // ... /// The length of a `[X]` or `[X; N]` value. Len(Place), } struct Place { base: PlaceBase, projection: List<PlaceElem>, } enum ProjectionElem { // ... ConstantIndex { offset: Nat, min_length: Nat, from_end: bool, }, Subslice { from: Nat, to: Nat, from_end: bool, }, } ``` ### Lowering to MIR * For a slice pattern matching a slice, where the pattern has `N` elements specified, there is a check that the `Rvalue::Len` of the slice is at least `N` to decide if the pattern can match. * There are two kinds of `ProjectionElem` used for slice patterns: 1. `ProjectionElem::ConstantIndex` is an array or slice element with a known index. As a shorthand it's written `base[offset of min_length]` if `from_end` is false and `base[-offset of min_length]` if `from_end` is true. `base[-offset of min_length]` is the `len(base) - offset`th element of `base`. 2. `ProjectionElem::Subslice` is a subslice of an array or slice with known bounds. As a shorthand it's written `base[from..to]` if `from_end` is false and `base[from:-to]` if `from_end` is true. `base[from:-to]` is the subslice `base[from..len(base) - to]`. * Note that `ProjectionElem::Index` is used for indexing expressions, but not for slice patterns. It's written `base[idx]`. * When binding an array pattern, any individual element binding is lowered to an assignment or borrow of `base[offset of len]` where `offset` is the element's index in the array and `len` is the array's length. * When binding a slice pattern, let `N` be the number of elements that have patterns. Elements before the subslice pattern (`prefix`) are lowered to `base[offset of N]` where `offset` is the element's index from the start. Elements after the subslice pattern (`suffix`) are lowered to `base[-offset of N]` where `offset` is the element's index from the end, plus 1. * Subslices of arrays are lowered to `base[from..to]` where `from` is the number of elements before the subslice pattern and `to = len(array) - len(suffix)` is the length of the array minus the number of elements after the subslice pattern. * Subslices of slices are lowered to `base[from:-to]` where `from` is the number of elements before the subslice pattern (`len(prefix)`) and `to` is the number of elements after the subslice pattern (`len(suffix)`). ### Safety and const checking * Subslice patterns do not introduce any new unsafe operations. * As subslice patterns for arrays are irrefutable, they are allowed in const contexts. As are `[..]` and `[ref y @ ..]` patterns for slices. However, `ref mut` bindings are only allowed with `feature(const_mut_refs)` for now. * As other subslice patterns for slices require a `match`, `if let`, or `while let`, they are only allowed with `feature(const_if_match, const_fn)` for now. * Subslice patterns may occur in promoted constants. ### Borrow and move checking * A subslice pattern can be moved from if it has an array type `[E; N]` and the parent array can be moved from. * Moving from an array subslice pattern moves from all of the elements of the array within the subslice. * If the subslice contains at least one element, this means that dynamic indexing (`arr[idx]`) is no longer allowed on the array. * The array can be reinitialized and can still be matched with another slice pattern that uses a disjoint set of elements. * A subslice pattern can be mutably borrowed if the parent array/slice can be mutably borrowed. * When determining whether an access conflicts with a borrow and at least one is a slice pattern: * `x[from..to]` always conflicts with `x` and `x[idx]` (where `idx` is a variable). * `x[from..to]` conflicts with `x[idx of len]` if `from <= idx` and `idx < to` (that is, `idx ∈ from..to`). * `x[from..to]` conflicts with `x[from2..to2]` if `from < to2` and `from2 < to` (that is, `(from..to) ∩ (from2..to2) ≠ ∅`). * `x[from:-to]` always conflicts with `x`, `x[idx]`, and `x[from2:-to2]`. * `x[from:-to]` conflicts with `x[idx of len]` if `from <= idx`. * `x[from:-to]` conflicts with `x[-idx of len]` if `to < idx`. * A constant index from the end conflicts with other elements as follows: * `x[-idx of len]` always conflicts with `x` and `x[idx]`. * `x[-idx of len]` conflicts with `x[-idx2 of len2]` if `idx == idx2`. * `x[-idx of len]` conflicts with `x[idx2 of len2]` if `idx + idx2 >= max(len, len2)`. ## Tests The tests can be primarily seen in the PR itself. Here are some of them: ### Parsing (3) * Testing that `..` patterns are syntactically allowed in all pattern contexts (2) * [pattern/rest-pat-syntactic.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/rest-pat-syntactic.rs) * [ignore-all-the-things.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/ignore-allthe-things.rs) * Slice patterns allow a trailing comma, including after `..` (1) * [trailing-comma.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/trailing-comma.rs) ### Lowering (2) * `@ ..` isn't allowed outside of slice patterns and only allowed once in each pattern (1) * [pattern/rest-pat-semantic-disallowed.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/rest-pat-semantic-disallowed.rs) * Mulitple `..` patterns are not allowed (1) * [parser/match-vec-invalid.rs](https://github.com/rust-lang/rust/blob/53712f8637dbe326df569a90814aae1cc5429710/src/test/ui/parser/match-vec-invalid.rs) ### Type checking (5) * Default binding modes apply to slice patterns (2) * [rfc-2005-default-binding-mode/slice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/rfc-2005-default-binding-mode/slice.rs) * [rfcs/rfc-2005-default-binding-mode/slice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/rfcs/rfc-2005-default-binding-mode/slice.rs) * Array patterns cannot have more elements in the pattern than in the array (2) * [match/match-vec-mismatch.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/match/match-vec-mismatch.rs) * [error-codes/E0528.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/error-codes/E0528.rs) * Array subslice patterns have array types (1) * [array-slice-vec/subslice-patterns-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-pass.rs) ### Exhaustiveness and usefulness checking (20) * Large subslice matches don't stack-overflow the exhaustiveness checker (1) * [pattern/issue-53820-slice-pattern-large-array.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/issue-53820-slice-pattern-large-array.rs) * Array patterns with subslices are irrefutable (1) * [issues/issue-7784.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-7784.rs) * `[xs @ ..]` slice patterns are irrefutable (1) * [binding/irrefutable-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/irrefutable-slice-patterns.rs) * Subslice patterns can match zero-length slices (2) * [issues/issue-15080.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-15080.rs) * [issues/issue-15104.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-15104.rs) * General tests (13) * [issues/issue-12369.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-12369.rs) * [issues/issue-37598.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-37598.rs) * [pattern/usefulness/match-vec-unreachable.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/match-vec-unreachable.rs) * [pattern/usefulness/non-exhaustive-match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/non-exhaustive-match.rs) * [pattern/usefulness/non-exhaustive-match-nested.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/non-exhaustive-match-nested.rs) * [pattern/usefulness/non-exhaustive-pattern-witness.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/non-exhaustive-pattern-witness.rs) * [pattern/usefulness/65413-constants-and-slices-exhaustiveness.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/65413-constants-and-slices-exhaustiveness.rs) * [pattern/usefulness/match-byte-array-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/match-byte-array-patterns.rs) * [pattern/usefulness/match-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/match-slice-patterns.rs) * [pattern/usefulness/slice-patterns-exhaustiveness.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/slice-patterns-exhaustiveness.rs) * [pattern/usefulness/slice-patterns-irrefutable.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/slice-patterns-irrefutable.rs) * [pattern/usefulness/slice-patterns-reachability.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/usefulness/slice-patterns-reachability.rs) * [uninhabited/uninhabited-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/uninhabited/uninhabited-patterns.rs) * Interactions with or-patterns (2) * [or-patterns/exhaustiveness-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/or-patterns/exhaustiveness-pass.rs) * [or-patterns/exhaustiveness-unreachable-pattern.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/or-patterns/exhaustiveness-unreachable-pattern.rs) ### Borrow checking (28) * Slice patterns can only move from owned, fixed-length arrays (4) * [borrowck/borrowck-move-out-of-vec-tail.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-of-vec-tail.rs) * [moves/move-out-of-slice-2.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/moves/move-out-of-slice-2.rs) * [moves/move-out-of-array-ref.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/moves/move-out-of-array-ref.rs) * [issues/issue-12567.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-12567.rs) * Moves from arrays are tracked by element (2) * [borrowck/borrowck-move-out-from-array-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array-no-overlap.rs) * [borrowck/borrowck-move-out-from-array-use-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array-use-no-overlap.rs) * Slice patterns cannot be used on moved-from slices/arrays (2) * [borrowck/borrowck-move-out-from-array.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array.rs) * [borrowck/borrowck-move-out-from-array-use.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-move-out-from-array-use.rs) * Slice patterns cannot be used with conflicting borrows (3) * [borrowck/borrowck-describe-lvalue.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-describe-lvalue.rs) * [borrowck/borrowck-slice-pattern-element-loan-array.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-array.rs) * [borrowck/borrowck-slice-pattern-element-loan-slice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-slice.rs) * Borrows from slice patterns are tracked and only conflict when there is possible overlap (6) * [borrowck/borrowck-slice-pattern-element-loan-array-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-array-no-overlap.rs) * [borrowck/borrowck-slice-pattern-element-loan-slice-no-overlap.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-slice-no-overlap.rs) * [borrowck/borrowck-slice-pattern-element-loan-rpass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-rpass.rs) * [borrowck/borrowck-vec-pattern-element-loan.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-element-loan.rs) * [borrowck/borrowck-vec-pattern-loan-from-mut.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-loan-from-mut.rs) * [borrowck/borrowck-vec-pattern-tail-element-loan.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-tail-element-loan.rs) * Slice patterns affect indexing expressions (1) * [borrowck/borrowck-vec-pattern-move-tail.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-move-tail.rs) * Borrow and move interactions with `box` patterns (1) * [borrowck/borrowck-vec-pattern-move-tail.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-vec-pattern-move-tail.rs) * Slice patterns correctly affect inference of closure captures (2) * [borrowck/borrowck-closures-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-closures-slice-patterns.rs) * [borrowck/borrowck-closures-slice-patterns-ok.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-closures-slice-patterns-ok.rs) * Interactions with `#![feature(bindings_after_at)]` (7) * [pattern/bindings-after-at/borrowck-move-and-move.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-move-and-move.rs) * [pattern/bindings-after-at/borrowck-pat-at-and-box-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-at-and-box-pass.rs) * [pattern/bindings-after-at/borrowck-pat-at-and-box.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-at-and-box.rs) * [pattern/bindings-after-at/borrowck-pat-by-copy-bindings-in-at.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-by-copy-bindings-in-at.rs) * [pattern/bindings-after-at/borrowck-pat-ref-both-sides.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-ref-both-sides.rs) * [pattern/bindings-after-at/borrowck-pat-ref-mut-and-ref.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-ref-mut-and-ref.rs) * [pattern/bindings-after-at/borrowck-pat-ref-mut-twice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/pattern/bindings-after-at/borrowck-pat-ref-mut-twice.rs) * Misc (1) * [issues/issue-26619.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-26619.rs) ### MIR lowering (1) * [uniform_array_move_out.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/mir-opt/uniform_array_move_out.rs) ### Evaluation (19) * Slice patterns don't cause leaks or double drops (2) * [drop/dynamic-drop.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/drop/dynamic-drop.rs) * [drop/dynamic-drop-async.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/drop/dynamic-drop-async.rs) * General run-pass tests (10) * [array-slice-vec/subslice-patterns-pass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-pass.rs) * [array-slice-vec/vec-matching-fixed.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching-fixed.rs) * [array-slice-vec/vec-matching-fold.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching-fold.rs) * [array-slice-vec/vec-matching-legal-tail-element-borrow.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching-legal-tail-element-borrow.rs) * [array-slice-vec/vec-matching.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-matching.rs) * [array-slice-vec/vec-tail-matching.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/vec-tail-matching.rs) * [binding/irrefutable-slice-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/irrefutable-slice-patterns.rs) * [binding/match-byte-array-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/match-byte-array-patterns.rs) * [binding/match-vec-alternatives.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/match-vec-alternatives.rs) * [borrowck/borrowck-slice-pattern-element-loan-rpass.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/borrowck/borrowck-slice-pattern-element-loan-rpass.rs) * Matching a large by-value array (1) * [issues/issue-17877.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/issues/issue-17877.rs) * Uninhabited elements (1) * [binding/empty-types-in-patterns.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/empty-types-in-patterns.rs) * Zero-sized elements (3) * [binding/zero_sized_subslice_match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/binding/zero_sized_subslice_match.rs) * [array-slice-vec/subslice-patterns-const-eval.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval.rs) * [array-slice-vec/subslice-patterns-const-eval-match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval-match.rs) * Evaluation in const contexts (2) * [array-slice-vec/subslice-patterns-const-eval.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval.rs) * [array-slice-vec/subslice-patterns-const-eval-match.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/array-slice-vec/subslice-patterns-const-eval-match.rs) ## Misc (1) * Exercising a case where const-prop cased an ICE (1) * [consts/const_prop_slice_pat_ice.rs](https://github.com/rust-lang/rust/blob/acb6690e1d58fc5f262ada5b5030fe73e601f1e8/src/test/ui/consts/const_prop_slice_pat_ice.rs) ## History - 2012-12-08, commit rust-lang@1968cb3 Author: Jakub Wieczorek Reviewers: @graydon This is where slice patterns were first implemented. It is particularly instructive to read the `vec-tail-matching.rs` test. - 2013-08-20, issue rust-lang#8636 Author: @huonw Fixed by @mikhail-m1 in rust-lang#51894 The issue describes a problem wherein the borrow-checker would not consider disjointness when checking mutable references in slice patterns. - 2014-09-03, RFC rust-lang/rfcs#164 Author: @brson Reviewers: The Core Team The RFC decided to feature gate slice patterns due to concerns over lack of oversight and the exhaustiveness checking logic not having seen much love. Since then, the exhaustivenss checking algorithm, in particular for slice patterns, has been substantially refactored and tests have been added. - 2014-09-03, RFC rust-lang/rfcs#202 Author: @krdln Reviewers: The Core Team > Change syntax of subslices matching from `..xs` to `xs..` to be more consistent with the rest of the language and allow future backwards compatible improvements. In 2019, rust-lang/rfcs#2359 changed the syntax again in favor of `..` and `xs @ ..`. - 2014-09-08, PR rust-lang#17052 Author: @pcwalton Reviewers: @alexcrichton and @sfackler This implemented the feature gating as specified in rust-lang/rfcs#164. - 2015-03-06, RFC rust-lang/rfcs#495 Author: @P1start Reviewers: The Core Team The RFC changed array and slice patterns like so: - Made them only match on arrays (`[T; N]`) and slice types (`[T]`), not references to slice types (`& mut? [T]`). - Made subslice matching yield a value of type `[T; N]` or `[T]`, not `& mut? [T]`. - Allowed multiple mutable references to be made to different parts of the same array or slice in array patterns. These changes were made to fit with the introduction of DSTs like `[T]` as well as with e.g. `box [a, b, c]` (`Box<[T]>`) in the future. All points remain true today, in particular with the advent of default binding modes. - 2015-03-22, PR rust-lang#23361 Author: @petrochenkov Reviewers: Unknown The PR adjusted codegen ("trans") such that `let ref a = *"abcdef"` would no longer ICE, paving the way for rust-lang/rfcs#495. - 2015-05-28, PR rust-lang#23794 Author: @brson Reviewers: @nrc The PR feature gated slice patterns in more contexts. - 2016-06-09, PR rust-lang#32202 Author: @arielb1 Reviewers: @eddyb and @nikomatsakis This implemented RFC rust-lang/rfcs#495 via a MIR based implementation fixing some bugs. - 2016-09-16, PR rust-lang#36353 Author: @arielb1 Reviewers: @nagisa, @pnkfelix, and @nikomatsakis The PR made move-checker improvements prohibiting moves out of slices. - 2018-02-17, PR rust-lang#47926 Author: @mikhail-m1 Reviewers: @nikomatsakis This added the `UniformArrayMoveOut` which converted move-out-from-array by `Subslice` and `ConstIndex {.., from_end: true }` to `ConstIndex` move out(s) from the beginning of the array. This fixed some problems with the MIR borrow-checker and drop-elaboration of arrays. Unfortunately, the transformation ultimately proved insufficient for soundness and was removed and replaced in rust-lang#66650. - 2018-02-19, PR rust-lang#48355 Author: @mikhail-m1 Reviewers: @nikomatsakis After rust-lang#47926, this restored some MIR optimizations after drop-elaboration and borrow-checking. - 2018-03-20, PR rust-lang#48516 Author: @petrochenkov Reviewers: @nikomatsakis This stabilized fixed length slice patterns `[a, b, c]` without variable length subslices and moved subslice patterns into `#![feature(slice_patterns)`. See rust-lang#48836 wherein the language team accepted the proposal to stabilize. - 2018-07-06, PR rust-lang#51894 Author: @mikhail-m1 Reviewers: @nikomatsakis rust-lang#8636 was fixed such that the borrow-checker would consider disjointness with respect to mutable references in slice patterns. - 2019-06-30, RFC rust-lang/rfcs#2359 Author: @petrochenkov Reviewers: The Language Team The RFC switched the syntax of subslice patterns to `{$binding @}? ..` as opposed to `.. $pat?` (which was what the RFC originally proposed). This RFC reignited the work towards finishing the implementation and the testing of slice patterns which eventually lead to this stabilization proposal. - 2019-06-30, RFC rust-lang/rfcs#2707 Author: @petrochenkov Reviewers: The Language Team This RFC built upon rust-lang/rfcs#2359 turning `..` into a full-fledged pattern (`Pat |= Rest:".." ;`), as opposed to a special part of slice and tuple patterns, moving previously syntactic restrictions into semantic ones. - 2019-07-03, PR rust-lang#62255 Author: @Centril Reviewers: @varkor This closed the old tracking issue (rust-lang#23121) in favor of the new one (rust-lang#62254) due to the new RFCs having been accepted. - 2019-07-28, PR rust-lang#62550 Author: @Centril Reviewers: @petrochenkov and @eddyb Implemented RFCs rust-lang/rfcs#2707 and rust-lang/rfcs#2359 by introducing the `..` syntactic rest pattern form as well as changing the lowering to subslice and subtuple patterns and the necessary semantic restrictions as per the RFCs. Moreover, the parser was cleaned up to use a more generic framework for parsing sequences of things. This framework was employed in parsing slice patterns. Finally, the PR introduced parser recovery for half-open ranges (e.g., `..X`, `..=X`, and `X..`), demonstrating in practice that the RFCs proposed syntax will enable half-open ranges if we want to add those (which is done in rust-lang#67258). - 2019-07-30, PR rust-lang#63111 Author: @Centril Reviewers: @estebank Added a test which comprehensively exercised the parsing of `..` rest patterns. That is, the PR exercised the specification in rust-lang/rfcs#2707. Moreover, a test was added for the semantic restrictions noted in the RFC. - 2019-07-31, PR rust-lang#63129 Author: @Centril Reviewers: @oli-obk Hardened the test-suite for subslice and subarray patterns with a run-pass tests. This test exercises both type checking and dynamic semantics. - 2019-09-15, PR rust-lang/rust-analyzer#1848 Author: @ecstatic-morse Reviewers: @matklad This implemented the syntactic change (rest patterns, `..`) in rust-analyzer. - 2019-11-05, PR rust-lang#65874 Author: @Nadrieril Reviewers: @varkor, @arielb1, and @Centril Usefulness / exhaustiveness checking saw a major refactoring clarifying the analysis by emphasizing that each row of the matrix can be seen as a sort of stack from which we pop constructors. - 2019-11-12, PR rust-lang#66129 Author: @Nadrieril Reviewers: @varkor, @Centril, and @estebank Usefulness / exhaustiveness checking of slice patterns were refactored in favor of clearer code. Before the PR, variable-length slice patterns were eagerly expanded into a union of fixed-length slices. They now have their own special constructor, which allows expanding them more lazily. As a side-effect, this improved diagnostics. Moreover, the test suite for exhaustiveness checking of slice patterns was hardened. - 2019-11-20, PR rust-lang#66497 Author: @Nadrieril Reviewers: @varkor and @Centril Building on the previous PR, this one fixed a bug rust-lang#53820 wherein sufficiently large subarray patterns (`match [0u8; 16*1024] { [..] => {}}`) would result in crashing the compiler with a stack-overflow. The PR did this by treating array patterns in a more first-class way (using a variable-length mechanism also used for slices) rather than like large tuples. This also had the effect of improving diagnostics for non-exhaustive matches. - 2019-11-28, PR rust-lang#66603 Author: @Nadrieril Reviewers: @varkor Fixed a bug rust-lang#65413 wherein constants, slice patterns, and exhaustiveness checking interacted in a suboptimal way conspiring to suggest that a reachable arm was in fact unreachable. - 2019-12-12, PR rust-lang#66650 Author: @matthewjasper Reviewers: @pnkfelix and @Centril Removed the `UniformArrayMoveOut` MIR transformation pass in favor of baking the necessary logic into the borrow-checker, drop elaboration and MIR building itself. This fixed a number of bugs, including a soundness hole rust-lang#66502. Moreover, the PR added a slew of tests for borrow- and move-checking of slice patterns as well as a test for the dynamic semantics of dropping subslice patterns. - 2019-12-16, PR rust-lang#67318 Author: @Centril Reviewers: @matthewjasper Improved documentation for AST->HIR lowering + type checking of slice as well as minor code simplification. - 2019-12-21, PR rust-lang#67467 Author: @matthewjasper Reviewers: @oli-obk, @RalfJung, and @Centril Fixed bugs in the const evaluation of slice patterns and added tests for const evaluation as well as borrow- and move-checking. - 2019-12-22, PR rust-lang#67439 Author: @Centril Reviewers: @matthewjasper Cleaned up HAIR lowering of slice patterns, removing special cased dead code for the unrepresentable `[a, b] @ ..`. The PR also refactored type checking for slice patterns. - 2019-12-23, PR rust-lang#67546 Author: @oli-obk Reviewers: @varkor and @RalfJung Fixed an ICE in the MIR interpretation of slice patterns. - 2019-12-24, PR rust-lang#66296 Author: @Centril Reviewers: @pnkfelix and @matthewjasper This implemented `#![feature(bindings_after_at)]` which allows writing e.g. `a @ Some([_, b @ ..])`. This is not directly linked to slice patterns other than with patterns in general. However, the combination of the feature and `slice_patterns` received some testing in the PR. - 2020-01-09, PR rust-lang#67990 Author: @Centril Reviewers: @matthewjasper This hardened move-checker tests for `match` expressions in relation to rust-lang#53114. - This PR stabilizes `slice_patterns`. ## Related / possible future work There is on-going work to improve pattern matching in other ways (the relevance of some of these are indirect, and only by composition): - OR-patterns, `pat_0 | .. | pat_n` is almost implemented. Tracking issue: rust-lang#54883 - Bindings after `@`, e.g., `x @ Some(y)` is implemented. Tracking issue: rust-lang#65490 - Half-open range patterns, e.g., `X..`, `..X`, and `..=X` as well as exclusive range patterns, e.g., `X..Y`. Tracking issue: rust-lang#67264 and rust-lang#37854 The relevance here is that this work demonstrates, in practice, that there are no syntactic conflicts introduced by the stabilization of subslice patterns. As for more direct improvements to slice patterns, some avenues could be: - Box patterns, e.g., `box [a, b, .., c]` to match on `Box<[T]>`. Tracking issue: rust-lang#29641 This issue currently has no path to stabilization. Note that it is currently possible to match on `Box<[T]>` or `Vec<T>` by first dereferencing them to slices. - `DerefPure`, which would allow e.g., using slice patterns to match on `Vec<T>` (e.g., moving out of it). Another idea which was raised by [RFC 2707](https://github.com/rust-lang/rfcs/blob/master/text/2707-dotdot-patterns.md#future-possibilities) and [RFC 2359](https://github.com/rust-lang/rfcs/blob/master/text/2359-subslice-pattern-syntax.md#pat-vs-pat) was to allow binding a subtuple pattern. That is, we could allow `(a, xs @ .., b)`. However, while we could allow by-value bindings to `..` as in `xs @ ..` at zero cost, the same cannot be said of by-reference bindings, e.g. `(a, ref xs @ .., b)`. The issue here becomes that for a reference to be legal, we have to represent `xs` contiguously in memory. In effect, we are forced into a [`HList`](https://docs.rs/frunk/0.3.1/frunk/hlist/struct.HCons.html) based representation for tuples.
Is this waiting on anything to be stabilized? I would have liked to use it in a complicated match. |
Last comments from #68859 (Dogfood
So it seems this might be waiting on dogfooding still? Can't find any uses of this feature in the compiler. |
In that case, could we stabilize |
I'm going to go ahead and nominate for lang to look at in triage. I am less uncertain about 0.. (compared to ..5), I think because the latter feels less obvious what it starts at. 0.. may end at i32::MAX or u32::MAX, for example, but both of those are more-or-less the same from a "what it is" perspective (unlike "0" or i32::MIN, which is quite different). Could you point at an example of where you wanted to use this more precisely, and maybe a diff between the two? Personally I feel like explicitly adding u/iN::MAX/MIN is probably not too much more writing in practice... |
I guess I had assumed |
This was the exact use case: // on stable
match delta {
(days, ..) if days > 5 => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
(days @ 2..=5, ..) => format!("{} days ago", days),
(1, ..) => "one day ago".to_string(),
(0, hours, ..) if hours > 1 => format!("{} hours ago", hours),
(0, 1, ..) => "an hour ago".to_string(),
(0, 0, minutes, _) if minutes > 1 => format!("{} minutes ago", minutes),
(0, 0, 1, _) => "one minute ago".to_string(),
(0, 0, 0, seconds) if seconds > 0 => format!("{} seconds ago", seconds),
_ => "just now".to_string(),
};
// on nightly
match delta {
(6.., ..) => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
(days @ 2..=5, ..) => format!("{} days ago", days),
(1, ..) => "one day ago".to_string(),
(0, hours @ 2.., ..) => format!("{} hours ago", hours),
(0, 1, ..) => "an hour ago".to_string(),
(0, 0, minutes @ 2.., _) => format!("{} minutes ago", minutes),
(0, 0, 1, _) => "one minute ago".to_string(),
(0, 0, 0, seconds @ 1..) => format!("{} seconds ago", seconds),
_ => "just now".to_string(),
}
I guess the main difference is that requires you to know what type
right - I realized when trying to make this an exhaustive match that this was actually a signed integer when I thought it was unsigned. Actually I think we don't handle the negative case in docs.rs ... |
I do think we have clearer semantics to allow stabilizing I also think we already have some unusual semantics for half-open ranges. For instance, We've already defined the semantics of On the other hand, for loops over a range do end up using different integer types sometimes. As long as you're not using the iteration variable in an indexing operation, the type constraint may not be For that reason, I'm hesitant to support pattern matching using I don't have any fundamental objections to stabilizing pattern matching using |
@jyn514 For that specific match, if you switched to unsigned types, you could write this, which I think would be clearer: match delta {
(0, 0, 0, 0) => "just now".to_string(),
(0, 0, 0, seconds) => format!("{} seconds ago", seconds),
(0, 0, 1, ..) => "one minute ago".to_string(),
(0, 0, minutes, ..) => format!("{} minutes ago", minutes),
(0, 1, ..) => "an hour ago".to_string(),
(0, hours, ..) => format!("{} hours ago", hours),
(1, ..) => "one day ago".to_string(),
(days @ 2..=5, ..) => format!("{} days ago", days),
_ => format!("{}", tm.strftime("%b %d, %Y").unwrap()),
} And that should work on stable. It wouldn't work for signed values, but I don't think the original handles the negative case anyway. |
I wanted to use this today to validate a libc struct while assuming as little as possible about the field types: match timeout {
timeval { tv_sec: sec @ 0.., tv_usec: usec @ 0..1_000_000, .. } => Ok((sec, usec)),
timeval { tv_sec: ..0, .. } => Err("is negative"),
timeval { tv_usec: 1_000_000.., .. } | timeval { tv_usec: ..0, .. } => Err("has invalid microsecond part"),
} Half-open ranges here have the benefit of not needing to know the signedness or size. ( |
@rfcbot resolve rust-reference |
@rfcbot concern rust-reference |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
oops, looks like that is still a problem? |
Does this stabilize using range patterns in slice pattern subpatterns at toplevel? Currently, a slice pattern of Relatedly, I'm currently working on the documentation PR for this. |
edit: whoops wrong specific issue, and I realized |
@AaronKutch How is that in any way related to this feature? |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Just to elaborate on Havvy's comment about slice patterns since I was a little confused: The I believe the slice pattern restriction stems from this comment to future-proof a hypothetical syntax to make it easier to match on slices (and a summary in this comment). This is exhibited in the The question is which option should be taken for the slice restriction:
|
…tterns, r=cjgillot Stabilize `half_open_range_patterns` This PR stabilize `feature(half_open_range_patterns)`: ``` Allows using `..=X` as a pattern. ``` And adds a new `feature(half_open_range_patterns_in_slices)` for the slice part, rust-lang#102275 (comment). The FCP was completed in rust-lang#67264.
…tterns, r=cjgillot Stabilize `half_open_range_patterns` This PR stabilize `feature(half_open_range_patterns)`: ``` Allows using `..=X` as a pattern. ``` And adds a new `feature(half_open_range_patterns_in_slices)` for the slice part, rust-lang#102275 (comment). The FCP was completed in rust-lang#67264.
…=cjgillot Stabilize `half_open_range_patterns` This PR stabilize `feature(half_open_range_patterns)`: ``` Allows using `..=X` as a pattern. ``` And adds a new `feature(half_open_range_patterns_in_slices)` for the slice part, rust-lang/rust#102275 (comment). The FCP was completed in rust-lang/rust#67264.
This was stabilized in #102275, I think this issue can be closed. |
This issue is open because |
同步社区最新master分支代码 Created-by: lizheng 30020856 Author-id: 11958 MR-id: 457385 Commit-by: bors;Michael Krasnitski;Mara Bos;KaDiWa;Alex Macleod;Manish Goregaokar;Tyler Weaver;Niki4tap;koka;Sylvain Desodt;ksaleem;Philipp Krones;Collin Styles;xFrednet;Martin Fischer;Evan Typanski;Vincenzo Palazzo;Samuel Moelius;chansuke;Michael Woerister;Kyle Matsuda;Maria José Solano;Michael Goulet;Yuki Okushi;Jason Newcomb;Joshua Nelson;Oli Scherer;Robert Bastian;navh;asquared31415;Andre Bogus;Albert Larsan;dswij;Raiki Tamura;Caio;blyxyas;Robin Schroer;Kyle Huey;Eric Wu;Nilstrieb;Andy Russell;Max Baumann;Ardis Lu;Trevor Gross;Ray Redondo;Matthias Krüger;Esteban Küber;Lukas Lueg;alexey semenyuk;dboso;Samuel Tardieu;feniljain;Gary Guo;Nicholas Nethercote;Fridtjof Stoldt;naosense;alex-semenyuk;Taiki Endo;Hannah Town;Jakob Degen;Lukas Wirth;Vadim Petrochenkov;mdgaziur;Eric Huss;Yuri Astrakhan;kraktus;Ralf Jung;Santiago Pastorino;Camille GILLOT;hkalbasi;Arpad Borsos;Maybe Waffle;ozkanonur;Sosthène Guédon;Deadbeef;Kartavya Vashishtha;Aphek;Nadir Fejzic;Lukas Markeffsky;hrxi;clubby789;yukang;Ryan Scheidter;Grachev Mikhail;Elliot Bobrow;Dylan DPC;Steven Casper;bebecue;Trevor Arjeski;Onur Özkan;Cameron Steffen;Guillaume Gomez;Matthew Ingwersen;Alex ✨ Cosmic Princess ✨;dswijj;mejrs;Rageking8;Alex;est31;oxalica;JT;Doru-Florin Blanzeanu;Andreu Botella;royrustdev;flip1995;lcnr;Kevin Per;Josh Stone;TennyZhuang;Marijn Schouten;Steven Nguyen;Cody;Urgau;ouz-a;Nahua Kang;Felix Kohlgrüber Merged-by: wangqilin 00349210 E2E-issues: Description: add syntax-tree-patterns RFC, Remove if_chain from equatable_if_let, Lint suggests matches macro if PartialEq trait is not implemented, Run cargo dev bless to update fixes & stderr, Merge commit 'ac0e10aa68325235069a842f47499852b2dee79e' into clippyup, Remove `mir::CastKind::Misc`, Merge commit '8f1ebdd18bdecc621f16baaf779898cc08cc2766' into clippyup, Introduce TypeErrCtxt TypeErrCtxt optionally has a TypeckResults so that InferCtxt doesn't need to., Change InferCtxtBuilder from enter to build, make const_err a hard error, Auto merge of #102091 - RalfJung:const_err, r=oli-obk make const_err a hard error This lint has been deny-by-default with future incompat wording since [Rust 1.51](rust-lang/rust#80394) and the stable release of this week starts showing it in cargo's future compat reports. I can't wait to finally get rid of at least some of the mess in our const-err-reporting-code. ;) r? `@oli-obk` Fixes rust-lang/rust#71800 Fixes rust-lang/rust#100114, Auto merge of rust-lang#2583 - RalfJung:rustup, r=oli-obk initial josh subtree sync This demonstrates what a josh-based rustup would look like with my patched josh. To create it I did ``` git fetch http://localhost:8000/rust-lang/rust.git:start=75dd959a3a40eb5b4574f8d2e23aa6efbeb33573[:prefix=src/tools/miri]:/src/tools/miri.git master git merge FETCH_HEAD ./rustup-toolchain HEAD && ./miri fmt git commit -am rustup ``` Unlike the [previous attempt](rust-lang/miri#2554), this does not add a new root commit to the repo. Once we merge this, we committed to using josh for subtree syncing, and in particular a version of josh that includes josh-project/josh#961 (or something compatible)., Stabilize half_open_range_patterns, Rollup merge of #102675 - ouz-a:mir-technical-debt, r=oli-obk Remove `mir::CastKind::Misc` As discussed in #97649 `mir::CastKind::Misc` is not clear, this PR addresses that by creating a new enum variant for every valid cast. r? ````@oli-obk````, [`unnecessary_cast`] Do not lint negative hexadecimal literals when cast as float Floats cannot be expressed as hexadecimal literals, ImplItemKind::TyAlias => ImplItemKind::Type, merge rustc history, Fix clippy tests that trigger `for_loop_over_fallibles` lint, fixup lint name, deprecate `clippy::for_loops_over_fallibles`, Rollup merge of #102829 - compiler-errors:rename-impl-item-kind, r=TaKO8Ki rename `ImplItemKind::TyAlias` to `ImplItemKind::Type` The naming of this variant seems inconsistent given that this is not really a "type alias", and the associated type variant for `TraitItemKind` is just called `Type`., Rollup merge of #102275 - Urgau:stabilize-half_open_range_patterns, r=cjgillot Stabilize `half_open_range_patterns` This PR stabilize `feature(half_open_range_patterns)`: ``` Allows using `..=X` as a pattern. ``` And adds a new `feature(half_open_range_patterns_in_slices)` for the slice part, rust-lang/rust#102275 (comment). The FCP was completed in rust-lang/rust#67264., Rename AssocItemKind::TyAlias to AssocItemKind::Type, Rollup merge of #99696 - WaffleLapkin:uplift, r=fee1-dead Uplift `clippy::for_loops_over_fallibles` lint into rustc This PR, as the title suggests, uplifts [`clippy::for_loops_over_fallibles`] lint into rustc. This lint warns for code like this: ```rust for _ in Some(1) {} for _ in Ok::<_, ()>(1) {} ``` i.e. directly iterating over `Option` and `Result` using `for` loop. There are a number of suggestions that this PR adds (on top of what clippy suggested): 1. If the argument (? is there a better name for that expression) of a `for` loop is a `.next()` call, then we can suggest removing it (or rather replacing with `.by_ref()` to allow iterator being used later) ```rust for _ in iter.next() {} // turns into for _ in iter.by_ref() {} ``` 2. (otherwise) We can suggest using `while let`, this is useful for non-iterator, iterator-like things like [async] channels ```rust for _ in rx.recv() {} // turns into while let Some(_) = rx.recv() {} ``` 3. If the argument type is `Result<impl IntoIterator, _>` and the body has a `Result<_, _>` type, we can suggest using `?` ```rust for _ in f() {} // turns into for _ in f()? {} ``` 4. To preserve the original behavior and clear intent, we can suggest using `if let` ```rust for _ in f() {} // turns into if let Some(_) = f() {} ``` (P.S. `Some` and `Ok` are interchangeable depending on the type) I still feel that the lint wording/look is somewhat off, so I'll be happy to hear suggestions (on how to improve suggestions :D)! Resolves #99272 [`clippy::for_loops_over_fallibles`]: https://rust-lang.github.io/rust-clippy/master/index.html#for_loops_over_fallibles, Rollup merge of #102868 - compiler-errors:rename-assoc-tyalias-to-ty, r=TaKO8Ki Rename `AssocItemKind::TyAlias` to `AssocItemKind::Type` Thanks `@camsteffen` for catching this in ast too, cc rust-lang/rust#102829 (comment), merge rustc history, Fix unclosed HTML tag in clippy doc, fix `box-default` ignoring trait objects' types, Fix allow_attributes_without_reason applying to external crate macros Previously the `clippy::allow_attributes_without_reason` lint would apply to external crate macros. Many macros in the Rust ecosystem include these `allow` attributes without adding a reason, making this lint pretty much unusable in any sizable Rust project. This commit fixes that by adding a check to the lint if the attribute is from an external crate macro and returning early., Fix bug in `referent_used_exactly_once`, merge rustc history, `default_numeric_fallback` do not lint on constants, refactor `default_numeric_fallback` We only need to store if the literal binding has an explicit type bound or not, Book: Small grammar + link a11y change, Remove CastCheckResult since it's unused, add missing comma, Auto merge of rust-lang#9644 - hkBst:patch-1, r=flip1995 add missing comma changelog: none, Auto merge of rust-lang#9643 - icecream17:patch-1, r=flip1995 Book: Small grammar + link a11y change *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: none --- Very minor For the link accessibility change, `here` and related don't provide context for screen readers who are reading a list of links. (Random supporting google links) https://www.w3.org/QA/Tips/noClickHere https://usability.yale.edu/web-accessibility/articles/links, Don't lint `ptr_arg` when used as an incompatible trait object, Auto merge of rust-lang#9645 - Jarcho:ptr_arg_9542, r=llogiq Don't lint `ptr_arg` when used as an incompatible trait object fixes rust-lang#9542 changelog: [`ptr_arg`](https://rust-lang.github.io/rust-clippy/master/#ptr_arg): Don't lint when used as an incompatible trait object, Add a suggestion and a note about orphan rules for `from_over_into`, Auto merge of rust-lang#9649 - Alexendoo:from-over-into-suggestion, r=llogiq Add a suggestion and a note about orphan rules for `from_over_into` Adds a machine applicable suggestion to convert the `Into` impl into a `From` one to `from_over_into` Also adds a note explaining that `impl From<Local> for Foreign` is fine if the `Into` type is foreign Closes rust-lang#7444 Addresses half of rust-lang#9638 changelog: [`from_over_into`] Add a suggestion and a note about orphan rules, Separate internal lints by pass, Move some things around, Expand `unnecessary_def_path` lint, Fix adjacent code, Format affected files, `explicit_ty_bound` code golf, [`zero_prefixed_literal`] Do not advise to use octal form if not possible, Enable test no_std_main_recursion, fix `box-default` linting `no_std` non-boxes, Auto merge of rust-lang#9655 - llogiq:unbox-default, r=dswij fix `box-default` linting `no_std` non-boxes This fixes rust-lang#9653 by doing the check against the `Box` type correctly even if `Box` isn't there, as in `no_std` code. Thanks to `@lukas-code` for opening the issue and supplying a reproducer! --- changelog: none, Auto merge of rust-lang#9636 - kraktus:numeric-fallback, r=dswij [`default_numeric_fallback`] do not lint on constants fix rust-lang#9632 changelog:[`default_numeric_fallback`] do not lint on constants, Auto merge of rust-lang#9566 - smoelius:diagnostic-item-path, r=dswij Expand internal lint `unnecessary_def_path` This PR does essentially two things: * Separates the internal lints into modules by pass. (`internal_lints.rs` was over 1400 lines, which is a little unruly IMHO.) * ~Adds a new~ Expands the `unnecessary_def_path` internal lint to flag hardcoded paths to diagnostic and language items. My understanding is that the latter is currently done by reviewers. Automating this process should make things easier for both reviewers and contributors. I could make the first bullet a separate PR, or remove it entirely, if desired. changelog: Add internal lint `diagnostic_item_path`, Add new lint `partial_pub_fields` Signed-off-by: TennyZhuang <zty0826@gmail.com>, fix dogfood Signed-off-by: TennyZhuang <zty0826@gmail.com>, add many tests Signed-off-by: TennyZhuang <zty0826@gmail.com>, fix a doctest Signed-off-by: TennyZhuang <zty0826@gmail.com>, Auto merge of rust-lang#9658 - TennyZhuang:partial-pub-fields, r=llogiq Add new lint `partial_pub_fields` Signed-off-by: TennyZhuang <zty0826@gmail.com> *Please write a short comment explaining your change (or "none" for internal only changes)* changelog: `partial_pub_fields`: new lint to disallow partial fields of a struct be pub Resolve rust-lang#9604, Auto merge of rust-lang#9652 - kraktus:octo_89, r=xFrednet [`zero_prefixed_literal`] Do not advise to use octal form if not possible fix rust-lang#9651 changelog: [`zero_prefixed_literal`] Do not advise to use octal form if not possible, Auto merge of rust-lang#9609 - kraktus:hexa_f32, r=giraffate [`unnecessary_cast`] Do not lint negative he See merge request innersource/rust/toolset/rust-clippy!8
…ize_matching, r=davidtwco Remove the `precise_pointer_size_matching` feature gate `usize` and `isize` are special for pattern matching because their range might depend on the platform. To make code portable across platforms, the following is never considered exhaustive: ```rust let x: usize = ...; match x { 0..=18446744073709551615 => {} } ``` Because of how rust handles constants, this also unfortunately counts `0..=usize::MAX` as non-exhaustive. The [`precise_pointer_size_matching`](rust-lang#56354) feature gate was introduced both for this convenience and for the possibility that the lang team could decide to allow the above. Since then, [half-open range patterns](rust-lang#67264) have been implemented, and since rust-lang#116692 they correctly support `usize`/`isize`: ```rust match 0usize { // exhaustive! 0..5 => {} 5.. => {} } ``` I believe this subsumes all the use cases of the feature gate. Moreover no attempt has been made to stabilize it in the 5 years of its existence. I therefore propose we retire this feature gate. Closes rust-lang#56354
Rollup merge of rust-lang#118598 - Nadrieril:remove_precise_pointer_size_matching, r=davidtwco Remove the `precise_pointer_size_matching` feature gate `usize` and `isize` are special for pattern matching because their range might depend on the platform. To make code portable across platforms, the following is never considered exhaustive: ```rust let x: usize = ...; match x { 0..=18446744073709551615 => {} } ``` Because of how rust handles constants, this also unfortunately counts `0..=usize::MAX` as non-exhaustive. The [`precise_pointer_size_matching`](rust-lang#56354) feature gate was introduced both for this convenience and for the possibility that the lang team could decide to allow the above. Since then, [half-open range patterns](rust-lang#67264) have been implemented, and since rust-lang#116692 they correctly support `usize`/`isize`: ```rust match 0usize { // exhaustive! 0..5 => {} 5.. => {} } ``` I believe this subsumes all the use cases of the feature gate. Moreover no attempt has been made to stabilize it in the 5 years of its existence. I therefore propose we retire this feature gate. Closes rust-lang#56354
X..
was stabilized in #83918..=X
was stabilized in #102275...X
was removed in #68120..X
is tracked in #37854X..
patterns in slices are currently gated viahalf_open_range_patterns_in_slices
This is a tracking issue for the feature gate
#![feature(half_open_range_patterns)]
. This feature provides half-open range patternsX..
,..X
,..=X
, and...X
(last one is also deprecated likeX...Y
is, for spec & implementation simplicity). These correspond to theRangeFrom
,RangeTo
,RangeToInclusive
, andRangeToInclusive
expression forms, with the same syntaxes, respectively. The correspondence is both syntactic and semantic (in the sense that e.g. aX..
pattern matching on a scrutinees
holds exactly when(X..).contains(&s)
holds). For implementations details, see #67258.The implementation for the feature was introduced in #67258 and is also strongly related to
#![feature(exclusive_range_pattern)]
(X..Y
) which is also required forX..
and..X
(as theRangeEnd::Exclusive
syntax is used).Steps:
half_open_range_patterns
have had some time to bake on nightly, write up an RFC specifying bothexclusive_range_pattern
andhalf_open_range
and proposing their stabilization.Unresolved questions:
..X
for signed types being from -i32::MAX -- is that OK? Too confusing? EDIT: Lang team considers this acceptable, leaving open the possibility of future lints to help catch mistakes.The text was updated successfully, but these errors were encountered: