-
Notifications
You must be signed in to change notification settings - Fork 137
Open
Description
After updating to Rust 1.84, the linting process (make lint) now produces non-local-definitions warnings due to OCaml derive macros generating impl blocks in nested contexts within the decl_traces! macro.
Error Output
error: non-local `impl` definition, `impl` blocks should be written at the same level as their item
--> internal-tracing/src/lib.rs:113:33
|
113 | #[derive(Debug, ocaml::IntoValue, ocaml::FromValue, ocaml_gen::Struct)]
| ^---------------
| |
| `IntoValue` is not local
| move the `impl` block outside of this constant `_DERIVE_ocaml_IntoValue_FOR_CamlTraces`
114 | pub struct CamlTraces(String);
| ---------- `CamlTraces` is not local
|
= note: the derive macro `ocaml::IntoValue` defines the non-local `impl`, and may need to be changed
= note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the
self type are at the same nesting level as the `impl`
= note: `-D non-local-definitions` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(non_local_definitions)]`
Root cause
We generate code that includes derive macros (ocaml::IntoValue, ocaml::FromValue) within nested contexts. Rust 1.84 introduced the non-local-definitions lint to catch potentially problematic impl blocks, but this triggers false positives with procedural macros that generate implementations in nested scopes.
Impact
- CI fails on the lint job when using Rust 1.84
- Blocks development workflow on the latest Rust version
- This is a common issue with derive macros in nested contexts, not an actual code problem
Related
- Rust 1.84 release notes: https://blog.rust-lang.org/2024/12/19/Rust-1.84.0.html#new-non-local-definitions-lint
- Similar issues in the Rust ecosystem with derive macros in proc macros
Environment
-
Rust version: 1.84
-
OCaml interop crates: ocaml, ocaml_gen
Priority
Medium - blocks CI on Rust 1.84 but workaround exists (downgrade to 1.82/1.83 temporarily)
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
Todo