Uplift clippy::invalid_null_ptr_usage lint as invalid_null_arguments

[Urgau]

This PR aims at uplifting the clippy::invalid_null_ptr_usage lint into rustc, this is similar to the clippy::invalid_utf8_in_unchecked uplift a few months ago, in the sense that those two lints lint on invalid parameter(s), here a null pointer where it is unexpected and UB to pass one.

For context: GitHub Search reveals that just for slice::from_raw_parts{_mut} ~20 invalid usages with ptr::null and an additional 4 invalid usages with 0 as *const ...-ish casts.

---

invalid_null_arguments

(deny-by-default)

The invalid_null_arguments lint checks for invalid usage of null pointers.

Example

// Undefined behavior
unsafe { std::slice::from_raw_parts(ptr::null(), 1); }
// Not Undefined behavior
unsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 1); }

Produces:

error: calling this function with a null pointer is Undefined Behavior, even if the result of the function is unused
  --> $DIR/invalid_null_args.rs:21:23
   |
LL |     let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 1);
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: for more information, visit <https://doc.rust-lang.org/std/ptr/index.html>

Explanation

Calling methods whose safety invariants requires non-null pointer with a null pointer is undefined behavior.

---

The lint use a list of functions to know which functions and arguments to checks, this could be improved in the future with a rustc attribute, or maybe even with a #[diagnostic] attribute.

This PR also includes some small refactoring to avoid some ambiguities in naming, those can be done in another PR is desired.

@rustbot label: +I-lang-nominated
r? compiler

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[Noratrieb]

I think @saethlin has also found plenty of code that hits this in the wild, so this seems like a good lint.

[saethlin]

You're probably referring to PyO3/pyo3#2687 and servo/font-kit#197

I don't think either of these would be detected by the lint, but I agree that this is a reasonable lint target.

[apiraino]

I'll flag this as S-waiting-on-team to signal that T-lang nomination

[bors]

☔ The latest upstream changes (presumably #120991) made this pull request unmergeable. Please resolve the merge conflicts.

[scottmcm]

(Just me, with my lang hat on but not talking for the team.)

I wish there was an easier way for these to get added without waiting on us.

Would you be interested in making a proposal of some sort for making maybe a diagnostics::something_or_other that could be used on functions or parameters to let warnings like this be something that functions can opt into themselves.

It'd be great if, rather than lang needing to approve stuff, it'd just be T-libs PR approving a #[diagnostics::ub_if(ptr.is_null())] or something like that. And eventually we could stabilize that to let crates use them too, to get built-in lints on stuff without needing rustc or clippy needing to know that the random crates even need to know exist.

[Centri3]

That feels similar to what flux and verus are doing but at a smaller scale. Unsure about allowing downstream users to access it but it'd be great to make these kinds of checks more prevalent (and not just for null ptr cases)

[Centri3]

I do like refinement types. We should discuss this further, I love the idea of rust expanding its sights of correctness to this, rather than a devtool (what flux does atm)

[Urgau]

I would if there was an easier way to add those kind of lints. Using the diagnostics namespace is also something I alluded in my top comment, and I think that it's something that should probably be pushed forward, the only thing that is a bit weird is that I had the impression that the diagnostics attribute would not by it-self create a diagnostic but is only here to accompany one.

It'd be great if, rather than lang needing to approve stuff, it'd just be T-libs PR approving a #[diagnostics::ub_if(ptr.is_null())] or something like that.

That would be awesome, I would love if it were this "simple".

I can write something akin to an MCP (for t-lang) but I don't have the time for a full RFC :-)

[Urgau]

@traviscross It's been more than a year since I nominated this PR for T-lang, I know it's not high priority/high in the list, and I don't mind waiting, but it's becoming annoying to maintain these kind of PR. This one in particular has nearly all modified files in conflict.

Is this something T-lang would accept? Is there a way to gather consensus outside of a nomination? If not I rather close this PR than continue to waste my time maintaining this PR.

[traviscross]

Thanks @Urgau for the ping on this one. Looking at this now carefully, we should move this one forward. I propose:

@rfcbot fcp merge

And I think this is probably a clear call for us, so let's collect checkboxes in the next meeting if it's still outstanding:

@rustbot labels +I-lang-easy-decision

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• name resolved by Uplift clippy::invalid_null_ptr_usage lint as invalid_null_arguments #119220 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

Anyone have a better suggestion for the lint name than invalid_null_ptr_usages? I think it's the word "usages" that I want rid of somehow.

[Urgau]

The first commit ca2656e has been extracted in it's own PR #138360. No need to review it.

Let's re-roll as @b-naber hasn't been active for over a year now.

r? compiler

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.