rust/tests/ui/issues/issue-15104.rs

// 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)
    }
}
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 07:18:55 -05: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 20:34:27 -05: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 12:07:37 -05: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 19:06:52 -05: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 04:54:59 -06: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 12:07:37 -05:00			`[] => 0,`
			`[_] => 1,`
Use new 'p @ ..' syntax in tests. 2019-07-07 18:47:46 -05: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 12:07:37 -05:00			`}`
			`}`