You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I will leave FIXME places in the code where the #[allow(non_local_definitions)] lint is firing. Broadly I think this lint falls into two camps:
We use const _: () = { use ::pyo3 as _pyo3; /* macro expanded code */ } to allow use-ing PyO3 at a consistent name across the PyO3 codebase. This was convenient to support the #[pyo3(crate = "...")] option. I think we could refactor the macros to not need this anonymous const, and that might solve the problem.
Inside create_exception! and its inner macros we have implementations of traits for &MyCustomException, which the lint seems to not like. We may be able to remove these cases alongside the GIL Ref API.
The text was updated successfully, but these errors were encountered:
Follow up to #3901
I will leave FIXME places in the code where the
#[allow(non_local_definitions)]
lint is firing. Broadly I think this lint falls into two camps:const _: () = { use ::pyo3 as _pyo3; /* macro expanded code */ }
to allow use-ing PyO3 at a consistent name across the PyO3 codebase. This was convenient to support the#[pyo3(crate = "...")]
option. I think we could refactor the macros to not need this anonymous const, and that might solve the problem.create_exception!
and its inner macros we have implementations of traits for&MyCustomException
, which the lint seems to not like. We may be able to remove these cases alongside the GIL Ref API.The text was updated successfully, but these errors were encountered: