warning: non-local impl definition, they should be avoided as they go against expectation

[brmmm3]

Since one of the last Rust updates I'm getting the following warning:

--> pyscandir/src/scandir.rs:32:1
   |
32 | #[pymethods]
   | ^^^^^^^^^^^^
   |
   = help: move this `impl` block outside the of the current function `trampoline` and up 3 bodies
   = note: an `impl` definition is non-local if it is nested inside an item and may impact type checking outside of that item. This can be the case if neither the trait or the self type are at the same nesting level as the `impl`
   = note: one exception to the rule are anon-const (`const _: () = { ... }`) at top-level module and anon-const at the same nesting as the trait or type
   = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <https://github.com/rust-lang/rust/issues/120363>
   = note: the attribute macro `pymethods` may come from an old version of the `pyo3_macros` crate, try updating your dependency with `cargo update -p pyo3_macros`
   = note: this warning originates in the attribute macro `pymethods` (in Nightly builds, run with -Z macro-backtrace for more info)

pyclass and pymethods for the same class are defined in the same file. So I don't understand why this warning is produced.

The corresponding code can be found here:

https://github.com/brmmm3/scandir-rs/blob/2.6.0/pyscandir/src/scandir.rs

Is this my fault or is it a problem of pyo3?

[adamreichold]

This is being hit with nightly Rust in our CI as well but we already merged the relevant suppressions, c.f. #4074, and will most likely release them in a patch release this week, c.f. #4037

[adamreichold]

So I don't understand why this warning is produced.

Give cargo expand a try if you are interested, but basically our macros have to piece together the resulting code from independent building builds to support all the options and flags one can set via the macro attributes and we have to play some tricks some autoref specialization to collect doc strings, etc.

I think in the some place we might be able to avoid the warning at cost of less readable (because more nonlocal) macro implementations, but it isn't obvious whether we should invest that work to avoid the warning in automatically generated code (but I think it also isn't obvious that we should not do it).

[brmmm3]

Thank you for the quick reply. As I've seen here (rust-lang/rust#120363) this warning will be turned in to a hard error in 2027.

[adamreichold]

this warning will be turned in to a hard error in 2027.

Well, this would make it pretty obvious then. ;-)

[birkenfeld]

A deny-by-default lint is fine, but a hard error would be unfortunate, and not only for PyO3, judging from the amount of backlinks to PRs silencing it.

Still it probably cannot hurt for someone from PyO3 (who can explain how much more complicated it would be to rewrite code generation to avoid the lint, so not me 😁 ) to pitch in there...