Skip to content
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

Closed
wants to merge 8 commits into from

Conversation

boxdot
Copy link
Contributor

@boxdot boxdot commented Oct 18, 2020

  1. I am not entirely sure about the lint name. On one hand I would like to use something short, on other hand it should be descriptive enough. Another name proposal is appreciated.
  2. I checked another functions that might be candidates for this lint. There are NonNull::new_unchecked and drop_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 just NonNull::dangling(). The drop_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

@rust-highfive
Copy link

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.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Oct 18, 2020
@Manishearth
Copy link
Member

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

@rust-highfive rust-highfive assigned ebroto and unassigned Manishearth Oct 25, 2020
Copy link
Member

@ebroto ebroto left a 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.

tests/ui/invalid_null_usage.rs Outdated Show resolved Hide resolved
src/lintlist/mod.rs Outdated Show resolved Hide resolved
clippy_lints/src/ptr.rs Outdated Show resolved Hide resolved
@ebroto ebroto added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Oct 26, 2020
@giraffate
Copy link
Contributor

ping from triage @boxdot. There seem to be some fixes left to be done. Do you have any questions on how to proceed here?

@boxdot
Copy link
Contributor Author

boxdot commented Nov 12, 2020

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.

@boxdot boxdot force-pushed the invalid-null-usage branch from 550c114 to 302d171 Compare November 23, 2020 19:23
@boxdot
Copy link
Contributor Author

boxdot commented Nov 23, 2020

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"];
Copy link
Contributor Author

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. :)

Copy link
Member

@ebroto ebroto Nov 28, 2020

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.

Copy link
Member

@ebroto ebroto Nov 29, 2020

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 :)

Copy link
Contributor Author

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.

@boxdot boxdot force-pushed the invalid-null-usage branch from f28c1fe to 791227c Compare November 23, 2020 19:33
@boxdot boxdot requested a review from ebroto November 23, 2020 22:21
@ebroto ebroto added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Nov 23, 2020
@bors
Copy link
Contributor

bors commented Nov 24, 2020

☔ 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:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@boxdot boxdot force-pushed the invalid-null-usage branch from 791227c to 4c56ef0 Compare November 27, 2020 15:05
Comment on lines +10 to +14
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);
Copy link
Member

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

Copy link
Contributor Author

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
Copy link
Member

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"];
Copy link
Member

@ebroto ebroto Nov 28, 2020

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.

Copy link
Member

@ebroto ebroto left a 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!

@ebroto ebroto added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Nov 28, 2020
@bors
Copy link
Contributor

bors commented Dec 4, 2020

☔ 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:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@giraffate
Copy link
Contributor

ping from triage @boxdot. Could you have any update on this?

@ebroto
Copy link
Member

ebroto commented Jan 3, 2021

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.

@ebroto ebroto closed this Jan 3, 2021
@ebroto ebroto added S-inactive-closed Status: Closed due to inactivity and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Jan 3, 2021
@boxdot boxdot mentioned this pull request Apr 3, 2021
bors added a commit that referenced this pull request Apr 8, 2021
Invalid null usage v2

This is continuation of #6192 after inactivity.

I plan to move paths into the compiler as diagnostic items after this is merged.

fixes #1703
changelog: none
@HKalbasi
Copy link
Member

finished in #5831
@rustbot label -S-inactive-closed

@rustbot rustbot removed the S-inactive-closed Status: Closed due to inactivity label Jul 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

lint the use of from_raw_parts with a constant null pointer
8 participants