Uplift clippy::invalid_null_ptr_usage lint

[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_ptr_usages

(deny-by-default)

The invalid_null_ptr_usages lint checks for invalid usage of null pointers.

Example

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

Produces:

error: calling this function with a null pointer is undefined behavior, even if the result of the function is unused, consider using a dangling pointer instead
  --> $DIR/invalid_null_ptr_usages.rs:14:23
   |
LL |     let _: &[usize] = std::slice::from_raw_parts(ptr::null(), 0);
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^-----------^^^^
   |                                                  |
   |                                                  help: use a dangling pointer instead: `core::ptr::NonNull::dangling().as_ptr()`

Explanation

Calling methods who's 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 :-)

[jieyouxu]

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.

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

Just a remark: note that there is currently a limitation on the compiler side with attribute handling of "namespaced attributes" and abitrary inner expressions within attributes.

In particular, we don't currently have support for arbitrary inner expressions (we can probably teach the compiler about arbitrary inner expressions but would need to be very careful about the grammar):

• we do currently have support for arbitrary expressions in the form of #[name = expr]
• but not #[name(expr)] AFAIK
• we certainly do not currently have support for #[namespace::name(expr)] where expr is not just a literal or other primitive.

(Purely FYI, not intended to derail this PR, we should continue discussion for these ideas on a dedicated zulip thread.)