rust/tests/ui/pattern/slice-pattern-recursion-15104.rs

//! Regression test for https://github.com/rust-lang/rust/issues/15104

//@ run-pass

fn main() {
    assert_eq!(count_members(&[1, 2, 3, 4]), 4);
}

fn count_members(v: &[usize]) -> usize {
    match *v {
        []         => 0,
        [_]        => 1,
        [_, ref xs @ ..] => 1 + count_members(xs)
    }
}
comments 2025-07-24 19:07:20 +05:00			`//! Regression test for https://github.com/rust-lang/rust/issues/15104`

Add `// run-pass` annotations to all the tests under `ui/run-pass/`. (I may have accidentally added it to some auxilliary crates as well; my emacs-macro-based methodology was pretty crude.) 2018-08-30 14:18:55 +02:00			`//@ run-pass`
Feature gate all slice patterns. #23121 Until some backwards-compatibility hazards are fixed in #23121, these need to be unstable. [breaking-change] 2015-03-26 18:34:27 -07:00
Change exhaustiveness analysis to permit multiple constructors per pattern Slice patterns are different from the rest in that a single slice pattern does not have a distinct constructor if it contains a variable-length subslice pattern. For example, the pattern [a, b, ..tail] can match a slice of length 2, 3, 4 and so on. As a result, the decision tree for exhaustiveness and redundancy analysis should explore each of those constructors separately to determine if the pattern could be useful when specialized for any of them. 2014-06-25 19:07:37 +02:00			`fn main() {`
			`assert_eq!(count_members(&[1, 2, 3, 4]), 4);`
			`}`

Mass rename uint/int to usize/isize Now that support has been removed, all lingering use cases are renamed. 2015-03-25 17:06:52 -07:00			`fn count_members(v: &[usize]) -> usize {`
implement RFC495 semantics for slice patterns non-MIR translation is still not supported for these and will happily ICE. This is a [breaking-change] for many uses of slice_patterns. 2016-03-11 12:54:59 +02:00			`match *v {`
Change exhaustiveness analysis to permit multiple constructors per pattern Slice patterns are different from the rest in that a single slice pattern does not have a distinct constructor if it contains a variable-length subslice pattern. For example, the pattern [a, b, ..tail] can match a slice of length 2, 3, 4 and so on. As a result, the decision tree for exhaustiveness and redundancy analysis should explore each of those constructors separately to determine if the pattern could be useful when specialized for any of them. 2014-06-25 19:07:37 +02:00			`[] => 0,`
			`[_] => 1,`
Use new 'p @ ..' syntax in tests. 2019-07-08 01:47:46 +02:00			`[_, ref xs @ ..] => 1 + count_members(xs)`
Change exhaustiveness analysis to permit multiple constructors per pattern Slice patterns are different from the rest in that a single slice pattern does not have a distinct constructor if it contains a variable-length subslice pattern. For example, the pattern [a, b, ..tail] can match a slice of length 2, 3, 4 and so on. As a result, the decision tree for exhaustiveness and redundancy analysis should explore each of those constructors separately to determine if the pattern could be useful when specialized for any of them. 2014-06-25 19:07:37 +02:00			`}`
			`}`