rust/tests/ui/panics/test-should-fail-bad-message.rs

//@ run-fail
//@ check-stdout
//@ compile-flags: --test
//@ needs-unwind

#[test]
#[should_panic(expected = "foobar")]
fn test_foo() {
    panic!("blah")
}
Move tests from `test/run-fail` to UI 2020-04-16 06:50:32 +00:00			`//@ run-fail`
Allow message specification for should_fail The test harness will make sure that the panic message contains the specified string. This is useful to help make `#[should_fail]` tests a bit less brittle by decreasing the chance that the test isn't "accidentally" passing due to a panic occurring earlier than expected. The behavior is in some ways similar to JUnit's `expected` feature: `@Test(expected=NullPointerException.class)`. Without the message assertion, this test would pass even though it's not actually reaching the intended part of the code: ```rust #[test] #[should_fail(message = "out of bounds")] fn test_oob_array_access() { let idx: uint = from_str("13o").unwrap(); // oops, this will panic [1i32, 2, 3][idx]; } ``` 2014-12-05 07:02:36 +00:00			`//@ check-stdout`
			`//@ compile-flags: --test`
Update test directives for `wasm32-wasip1` * The WASI targets deal with the `main` symbol a bit differently than native so some `codegen` and `assembly` tests have been ignored. * All `ignore-emscripten` directives have been updated to `ignore-wasm32` to be more clear that all wasm targets are ignored and it's not just Emscripten. * Most `ignore-wasm32-bare` directives are now gone. * Some ignore directives for wasm were switched to `needs-unwind` instead. * Many `ignore-wasm32*` directives are removed as the tests work with WASI as opposed to `wasm32-unknown-unknown`. 2024-03-06 20:44:54 +00:00			`//@ needs-unwind`
Allow message specification for should_fail The test harness will make sure that the panic message contains the specified string. This is useful to help make `#[should_fail]` tests a bit less brittle by decreasing the chance that the test isn't "accidentally" passing due to a panic occurring earlier than expected. The behavior is in some ways similar to JUnit's `expected` feature: `@Test(expected=NullPointerException.class)`. Without the message assertion, this test would pass even though it's not actually reaching the intended part of the code: ```rust #[test] #[should_fail(message = "out of bounds")] fn test_oob_array_access() { let idx: uint = from_str("13o").unwrap(); // oops, this will panic [1i32, 2, 3][idx]; } ``` 2014-12-05 07:02:36 +00:00
			`#[test]`
Rename #[should_fail] to #[should_panic] 2015-01-31 23:08:25 +00:00			`#[should_panic(expected = "foobar")]`
Allow message specification for should_fail The test harness will make sure that the panic message contains the specified string. This is useful to help make `#[should_fail]` tests a bit less brittle by decreasing the chance that the test isn't "accidentally" passing due to a panic occurring earlier than expected. The behavior is in some ways similar to JUnit's `expected` feature: `@Test(expected=NullPointerException.class)`. Without the message assertion, this test would pass even though it's not actually reaching the intended part of the code: ```rust #[test] #[should_fail(message = "out of bounds")] fn test_oob_array_access() { let idx: uint = from_str("13o").unwrap(); // oops, this will panic [1i32, 2, 3][idx]; } ``` 2014-12-05 07:02:36 +00:00			`fn test_foo() {`
			`panic!("blah")`
			`}`