Rename and reimplement nonnull_unchecked_on_box_ptr - #17485
Rename and reimplement nonnull_unchecked_on_box_ptr#17485ArhanChaudhary wants to merge 10 commits into
nonnull_unchecked_on_box_ptr#17485Conversation
|
Thanks for the pull request. A reviewer will take a look after it receives 2 community reviews. In the meantime, we would highly appreciate if you could try to review any of PRs waiting on community reviews. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
| /// Checks for unsafe usage of `NonNull::new_unchecked(Box::into_raw(x))` or dangerous usage of `NonNull::from_mut(Box::leak(x))` and suggests calling `Box::into_non_null(x)` instead. | ||
| /// | ||
| /// ### Why is this bad? | ||
| /// First, `NonNull::new_unchecked` is an unsafe function, which we don't need to call at all. Second, at the time of writing, whether or not you are allowed to reconstruct the `Box` from the mutable reference returned by `Box::leak` is an [open question](https://doc.rust-lang.org/std/boxed/struct.Box.html#method.leak). Thus, this lint helps prevent future dangerous calls to `Box::from_non_null`. |
There was a problem hiding this comment.
The hyperlink will eventually point to the updated documentation in this PR: rust-lang/rust#160323
|
Also, I'm not sure what category this lint falls into anymore, since the |
|
Lintcheck changes for 3d65490
This comment will be updated if you push new changes |
This comment has been minimized.
This comment has been minimized.
dabffc8 to
4f084a7
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ed8acfe to
fd1eedc
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
Nothing about |
|
There was recently discussion where the compiler people agreed that this is, in general dangerous, specifically with custom allocators. rust-lang/rust#160251 (comment) See the PR description for more |
|
I read the thread. The issue there is unleaking the pointer created, not creating the pointer in general. |
|
The idea is to prevent future unleaking of the pointer, despite creating the pointer is safe. |
|
Or, apologies I mischaracterized what you were responding to. Did you bring that up to answer which lint category this should be in, or do you disagree with the rewrite? |
|
That neither justifies the rename nor claiming that it's a correctness issue. I have no issue linting on it. |
There was a problem hiding this comment.
This feels like it should be two different lints. Linting NonNull::from(Box::leak()) is only done due to unresolved provenance questions if that pointer is later unleaked. That definitely doesn't fit a complexity lint, but it could be either suspicious or pedantic depending on what the lint catches in practice.
| && expr2 | ||
| .ty_rel_def_if_named(cx, sym::leak) | ||
| .opt_parent(cx) | ||
| .opt_impl_ty(cx) | ||
| .is_lang_item(cx, LangItem::OwnedBox) |
There was a problem hiding this comment.
This needs to check specifically for Box<T, Global>. You can suggest into_non_null_with_allocator for any other allocator.
|
|
||
| declare_clippy_lint! { | ||
| /// ### What it does | ||
| /// Checks for unsafe usage of `NonNull::new_unchecked(Box::into_raw(x))` or dangerous usage of `NonNull::from_mut(Box::leak(x))` and suggests calling `Box::into_non_null(x)` instead. |
There was a problem hiding this comment.
This can't be called a dangerous use since we didn't (and can't reasonably) check if it was unleaked.
|
Reminder, once the PR becomes ready for a review, use |
|
☔ The latest upstream changes (possibly #17538) made this pull request unmergeable. Please resolve the merge conflicts. |
changelog: rename and reimplement
nonnull_unchecked_on_box_ptrlint.Address the discussion in rust-lang/rust#160251 with @RalfJung's recommendation of a re-implementation of the
nonnull_unchecked_on_box_ptrlint. Now that rust-lang/rust#130364 was very recently stabilized, we can ship this lint with 1.98.A question: because the old lint had not yet been released, do I need to follow
cargo dev rename_lint? If so, do I need to specify#[clippy::version = "1.99.0"](which doesn't make sense because 1.98 hasn't been released yet) or leave it as#[clippy::version = ""]? Currently, I have rancargo dev rename_lintand specified#[clippy::version = ""].