-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add invalid null pointer usage lint. #6192
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Manishearth (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
I'm in the middle of a move and may cut back on reviewing for a few weeks. I'm going to reassign my PRs for now, though i'll still try to review smaller things. r? @ebroto |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM modulo nits and a test to add.
I am not entirely sure about the lint name
I think the name is fine, we could maybe be a bit more explicit with invalid_null_ptr_usage
?
I checked another functions that might be candidates for this lint
I agree with both of your points. In addition, I think this lint may be relevant for:
std::slice::from_raw_parts_mut
- Most of the functions in
std::ptr
module? See the safety section.
ping from triage @boxdot. There seem to be some fixes left to be done. Do you have any questions on how to proceed here? |
Thank you for pinging. Will address the comments today evening. |
550c114
to
302d171
Compare
I hope it is ok to rebase on master during the review. |
pub const PTR_EQ: [&str; 3] = ["core", "ptr", "eq"]; | ||
pub const PTR_NULL: [&str; 3] = ["core", "ptr", "null"]; | ||
pub const PTR_NULL_MUT: [&str; 3] = ["core", "ptr", "null_mut"]; | ||
pub const PTR_READ: [&str; 3] = ["core", "ptr", "read"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this is a perfect lint for #5393. Should we try to add diagnostics to the functions instead of hardcoding them here? I would need some hints how to do this though. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are right. I'm not familiar with the process of adding diagnostic items, but looking at this commit it seems that just adding the attribute should be enough?
This should be done in the rust-lang/rust repo, and we can sync that change afterwards and finish the lint here. As a heads-up we may try to pin to a nightly soon in this repo, so the aforementioned sync process could change. I apologize in advance if that creates any problem, we still have to discover what the new way of working with the pinned nightly will look like :)
EDIT: GitHub inlined this comment in the review, but not the whole conversation. Take a look at the additional comment there. TL;DR this is not needed for merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, there are other lints being currently implemented that will add paths (e.g. #6394)
Even though the right thing to do would be probably to turn those into diagnostic items, I will not make a blocker out of this, so it's fine if you leave the paths here. I understand it would make merging this way longer, and it's not a problem introduced in your PR.
Ideally, you can address #5393 after this one if you want :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You were right about first merging this and then adding diagnostic items to the compiler. I got stuck in the latter step.
f28c1fe
to
791227c
Compare
☔ The latest upstream changes (presumably #6339) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
791227c
to
4c56ef0
Compare
std::ptr::copy::<usize>(std::ptr::null(), std::ptr::NonNull::dangling().as_ptr(), 0); | ||
std::ptr::copy::<usize>(std::ptr::NonNull::dangling().as_ptr(), std::ptr::null_mut(), 0); | ||
|
||
std::ptr::copy_nonoverlapping::<usize>(std::ptr::null(), std::ptr::NonNull::dangling().as_ptr(), 0); | ||
std::ptr::copy_nonoverlapping::<usize>(std::ptr::NonNull::dangling().as_ptr(), std::ptr::null_mut(), 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These cases do not seem to be detected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved in #7023
@@ -0,0 +1,6 @@ | |||
// run-rustfix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this file can be removed now
pub const PTR_EQ: [&str; 3] = ["core", "ptr", "eq"]; | ||
pub const PTR_NULL: [&str; 3] = ["core", "ptr", "null"]; | ||
pub const PTR_NULL_MUT: [&str; 3] = ["core", "ptr", "null_mut"]; | ||
pub const PTR_READ: [&str; 3] = ["core", "ptr", "read"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are right. I'm not familiar with the process of adding diagnostic items, but looking at this commit it seems that just adding the attribute should be enough?
This should be done in the rust-lang/rust repo, and we can sync that change afterwards and finish the lint here. As a heads-up we may try to pin to a nightly soon in this repo, so the aforementioned sync process could change. I apologize in advance if that creates any problem, we still have to discover what the new way of working with the pinned nightly will look like :)
EDIT: GitHub inlined this comment in the review, but not the whole conversation. Take a look at the additional comment there. TL;DR this is not needed for merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making this move forward!
☔ The latest upstream changes (presumably #6394) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
ping from triage @boxdot. Could you have any update on this? |
According to the triage procedure, I should close this PR as there has been no activity and two weeks have passed since the last ping. @boxdot do not hesitate to reopen this in case you plan to finish it. |
NonNull::new_unchecked
anddrop_in_place
. It might make sense to add the lint to the former case, however the suggestion is then slightly convoluted:NonNull::new_unchecked(NonNull::dangling().as_ptr())
. I guess I could replace it by justNonNull::dangling()
. Thedrop_in_place
case seem to be not really applicable, since I can't imagine a situation where somebody drops a constant nullptr. Throughts?fixes #1703
changelog: none