unnecessary_wraps complains about function wrapped by proc-macro

[alex]

Lint name: unnecessary_wraps

I tried this code:

#[pyo3::prelude::pymodule]
fn _rust(_py: pyo3::Python<'_>, _m: &pyo3::types::PyModule) -> pyo3::PyResult<()> {
    Ok(())
}

I expected to see this happen: No warning, even though it always returns Ok(()), the proc-macro needs it to return a Result

Instead, this happened:

error: this function's return value is unnecessarily wrapped by `Result`
 --> src/lib.rs:6:1
  |
6 | / fn _rust(_py: pyo3::Python<'_>, _m: &pyo3::types::PyModule) -> pyo3::PyResult<()> {
7 | |     Ok(())
8 | | }
  | |_^
  |
  = note: `-D clippy::unnecessary-wraps` implied by `-D warnings`
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_wraps
help: remove `Result` from the return type...
  |
6 | fn _rust(_py: pyo3::Python<'_>, _m: &pyo3::types::PyModule) -> () {
  |                                                                ^^
help: ...and change the returning expressions
  |
7 |     ()
  |

Meta

Rust: 1.50.

[camsteffen]

This seems like an issue with the pyo3 library to me. I'm not sure it makes sense to disable the lint on any function with a proc-macro.

[alex]

Why do you say it's an issue with pyo3?

[camsteffen]

Because it requires you to return a Result.

[alex]

Why is that a bug? Usually implementations will return something besides `Ok(())` this just happens to be a degenerate case.

…

On Thu, Feb 11, 2021 at 10:35 PM Cameron Steffen ***@***.***> wrote: Because it requires you to return a Result. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6721 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBC5FJDSURQPXHQDX73S6SOZVANCNFSM4XPCGIPQ> .

-- All that is necessary for evil to succeed is for good people to do nothing.

[rschoon]

I suspect the proc-macro could probably be changed to handle detect and handle a function returning either pyo3::PyResult<T> or T, but my first inclination on encountering this would be to assume it doesn't support it and the lint needed to be ignored instead (which is almost certainly currently true).