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
Update from_raw_with_void_ptr to support types other than Box
This PR updates the `from_raw_with_void_ptr` lint, which covered
`Box::from_raw`, to also cover the `from_raw` static method of the
`Rc`, `Arc`, `alloc::rc::Weak` and `alloc::sync::Weak` types.
It also improves the description and error messages of this lint.
---
changelog: [`from_raw_with_void_ptr`]: Now works with the `Rc`, `Arc`, `alloc::rc::Weak` and `alloc::sync::Weak` types.
/// meaning that if you pass a *mut c_void you will get a Box<c_void>.
21
-
/// Per the safety requirements in the documentation, for this to be safe,
22
-
/// c_void would need to have the same memory layout as the original type, which is often not the case.
17
+
/// When dealing with `c_void` raw pointers in FFI, it is easy to run into the pitfall of calling `from_raw` with the `c_void` pointer.
18
+
/// The type signature of `Box::from_raw` is `fn from_raw(raw: *mut T) -> Box<T>`, so if you pass a `*mut c_void` you will get a `Box<c_void>` (and similarly for `Rc`, `Arc` and `Weak`).
19
+
/// For this to be safe, `c_void` would need to have the same memory layout as the original type, which is often not the case.
&& let arg_kind = cx.typeck_results().expr_ty(arg).kind()
52
48
&& letRawPtr(TypeAndMut{ ty, .. }) = arg_kind
53
49
&& is_c_void(cx,*ty){
54
-
span_lint_and_help(cx,FROM_RAW_WITH_VOID_PTR, expr.span,"creating a `Box` from a raw void pointer",Some(arg.span),"cast this to a pointer of the actual type");
50
+
let msg = format!("creating a `{type_str}` from a void raw pointer");
51
+
span_lint_and_help(cx,FROM_RAW_WITH_VOID_PTR, expr.span,&msg,Some(arg.span),"cast this to a pointer of the appropriate type");
52
+
}
53
+
}
54
+
}
55
+
56
+
/// Checks whether a `DefId` matches `Box`, `Rc`, `Arc`, or one of the `Weak` types.
57
+
/// Returns a static string slice with the name of the type, if one was found.
Copy file name to clipboardExpand all lines: src/docs/from_raw_with_void_ptr.txt
+4-9Lines changed: 4 additions & 9 deletions
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,10 @@
1
1
### What it does
2
-
Checks if we're passing a `c_void` raw pointer to `Box::from_raw(_)`
2
+
Checks if we're passing a `c_void` raw pointer to `{Box,Rc,Arc,Weak}::from_raw(_)`
3
3
4
4
### Why is this bad?
5
-
However, it is easy to run into the pitfall of calling from_raw with the c_void pointer.
6
-
Note that the definition of, say, Box::from_raw is:
7
-
8
-
`pub unsafe fn from_raw(raw: *mut T) -> Box<T>`
9
-
10
-
meaning that if you pass a *mut c_void you will get a Box<c_void>.
11
-
Per the safety requirements in the documentation, for this to be safe,
12
-
c_void would need to have the same memory layout as the original type, which is often not the case.
5
+
When dealing with `c_void` raw pointers in FFI, it is easy to run into the pitfall of calling `from_raw` with the `c_void` pointer.
6
+
The type signature of `Box::from_raw` is `fn from_raw(raw: *mut T) -> Box<T>`, so if you pass a `*mut c_void` you will get a `Box<c_void>` (and similarly for `Rc`, `Arc` and `Weak`).
7
+
For this to be safe, `c_void` would need to have the same memory layout as the original type, which is often not the case.
0 commit comments