#[should_panic]'s return-type check ignores procedural-macro transformations

[meiomorphism]

When a procedural macro which transforms the return type of a function from ... -> SomeType to -> () is applied, the resulting function can be used with the attribute #[test] as expected. However, adding the attribute #[should_panic] to that test results in a compile-time error.

A (slightly simplified) motivating example:

#[test]
#[should_panic]
#[test_utils::matches_image("tests/data/blue_pixel.png")]
fn fails_on_mismatching_data() -> Box<[u32]> {
    Box::new([0; 1])
}

Result:

error: functions using `#[should_panic]` must return `()`

As a simple workaround, the transformed function can be wrapped with a separate #[test] #[should_panic] function returning () and invoked manually within that.

Tested on rustc 1.48.0 (7eac88abb 2020-11-16) and rustc 1.50.0-nightly (eb4fc71dc 2020-12-17).

[meiomorphism]

(Despite the title of this bug, I suspect the ideal fix would be to have #[test] and libtest differentiate between panics and errors, so that the type-check guard for #[should_panic] is no longer needed. I haven't looked too deeply into what that would involve, though.

Reference to relevant previous issues: #48854, #49909.)

[Aaron1011]

I think this is an expected result of the left-to-right/top-to-bottom order of attribute invocation. #[test] gets invoked with the input:

#[should_panic]
#[test_utils::matches_image("tests/data/blue_pixel.png")]
fn fails_on_mismatching_data() -> Box<[u32]> {
    Box::new([0; 1])
}

so it sees a return type of (). You should be able to fix this by moving #[test] after #[test_utils::matches_image("tests/data/blue_pixel.png")]

[meiomorphism]

Unfortunately, all six orderings of the three attributes yield identical results.