Aphoh opened a new pull request, #496: URL: https://github.com/apache/tvm-ffi/pull/496
## Summary Fix 3 deny-level clippy lints in the Rust bindings that block `cargo clippy` from passing cleanly. ## Changes ### 1. `data_as_slice_mut(&self)` → `data_as_slice_mut(&mut self)` **Lint:** `clippy::mut_from_ref` The original signature returned `&mut [T]` from `&self`. This allows creating aliased mutable references through multiple shared borrows — which is unsound. Changing to `&mut self` lets the borrow checker enforce exclusivity. Per the book's ["Creating a Safe Abstraction over Unsafe Code"](https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html) section: a function that wraps unsafe code does not need to be marked `unsafe fn` if it validates its own preconditions. Here the signature (`&mut self`) enforces the key invariant, and the body validates dtype, device, and contiguity before calling `from_raw_parts_mut`. ### 2. `with_stream` → `unsafe fn with_stream` **Lint:** `clippy::not_unsafe_ptr_arg_deref` Takes a `TVMFFIStreamHandle` (`*mut c_void`) and passes it to the C function `TVMFFIEnvSetStream`. The book says: "just because a function contains unsafe code doesn't mean we need to mark the entire function as unsafe." But that only applies when the function can validate its own preconditions. Here it cannot — there is no way to verify the stream handle is valid (CUDA stream handles are opaque with no validation API). The caller must uphold that invariant, so the function must be `unsafe fn`. ### 3. `from_extern_c` → `unsafe fn from_extern_c` **Lint:** `clippy::not_unsafe_ptr_arg_deref` Takes a `*mut c_void` handle, a C function pointer (`safe_call`), and an optional `deleter`, all forwarded to `TVMFFIFunctionCreate`. The function cannot verify that the handle is valid, that `safe_call` is compatible with it, or that `deleter` will correctly free it. These are invariants the caller must uphold — same reasoning as `with_stream`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
