rust/tests/ui/binding/expr-match-panic.rs

//@ run-pass


fn test_simple() {
    let r = match true { true => { true } false => { panic!() } };
    assert_eq!(r, true);
}

fn test_box() {
    let r = match true { true => { vec![10] } false => { panic!() } };
    assert_eq!(r[0], 10);
}

pub fn main() { test_simple(); test_box(); }
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`
test: Make manual changes to deal with the fallout from removal of `~[T]` in test, libgetopts, compiletest, librustdoc, and libnum. 2014-03-05 15:28:08 -08:00
rustdoc: Replace no-pretty-expanded with pretty-expanded Now that features must be declared expanded source often does not compile. This adds 'pretty-expanded' to a bunch of test cases that still work. 2015-03-22 13:13:15 -07:00
rustc: Allow alt expressions to fail 2011-05-13 14:42:23 -04:00			`fn test_simple() {`
Rename fail! to panic! https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . \| xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change] 2014-10-09 15:17:22 -04:00			`let r = match true { true => { true } false => { panic!() } };`
Use assert_eq! rather than assert! where possible 2013-05-18 22:02:45 -04:00			`assert_eq!(r, true);`
rustc: Allow alt expressions to fail 2011-05-13 14:42:23 -04:00			`}`

			`fn test_box() {`
Changed most vec! invocations to use square braces Most of the Rust community agrees that the vec! macro is clearer when called using square brackets [] instead of regular brackets (). Most of these ocurrences are from before macros allowed using different types of brackets. There is one left unchanged in a pretty-print test, as the pretty printer still wants it to have regular brackets. 2016-10-29 22:54:04 +01:00			`let r = match true { true => { vec![10] } false => { panic!() } };`
Remove all `i` suffixes 2015-01-25 22:05:03 +01:00			`assert_eq!(r[0], 10);`
rustc: Allow alt expressions to fail 2011-05-13 14:42:23 -04:00			`}`

check-fast fallout from removing export, r=burningtree 2013-02-01 19:43:17 -08:00			`pub fn main() { test_simple(); test_box(); }`