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

[Nilstrieb]

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.