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

fn main() {
    let a = Some(Box::new(1));
    match a {
        Ok(a) => //~ ERROR: mismatched types
            println!("{}",a),
        None => panic!()
    }
}
test: Add a test for fixed issue #11844 Closes #11844 2014-05-20 21:25:49 -07:00			`fn main() {`
Remove even more box syntax uses from src/test Prior work, notably 6550021124451628b1efc60c59284465b109e3aa from #88316 has removed box syntax from most of the testsuite. However, some tests were left out. This commit removes box_syntax uses from more locations in src/test. Some tests that are very box syntax specific are not being migrated. 2022-07-07 04:36:10 +02:00			`let a = Some(Box::new(1));`
test: Add a test for fixed issue #11844 Closes #11844 2014-05-20 21:25:49 -07:00			`match a {`
			`Ok(a) => //~ ERROR: mismatched types`
Introduce VecPerParamSpace and use it to represent sets of types and parameters This involves numerous substeps: 1. Treat Self same as any other parameter. 2. No longer compute offsets for method parameters. 3. Store all generic types (both trait/impl and method) with a method, eliminating odd discrepancies. 4. Stop doing unspeakable things to static methods and instead just use the natural types, now that we can easily add the type parameters from trait into the method's polytype. 5. No doubt some more. It was hard to separate these into distinct commits. Fixes #13564 2014-05-31 18:53:13 -04:00			`println!("{}",a),`
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			`None => panic!()`
test: Add a test for fixed issue #11844 Closes #11844 2014-05-20 21:25:49 -07:00			`}`
			`}`