invalid_null_ptr_usage lacks explanation

[jgarvin]

Summary

Why is this bad?
This causes undefined behavior.

I'm still left with no idea why. The entire point of using pointers instead of references is to be able to use things like null and not worry about lifetimes so why is there so much ceremony to express a null slice pointer?

[PatchMixolydic]

Specifically, invalid_null_ptr_usage seems to lint against cases where a null pointer is dereferenced (which includes turning it into a reference, such as with slice::from_raw_parts):

rust-clippy/clippy_lints/src/ptr.rs

Lines 246 to 263 in dbcd828

	const INVALID_NULL_PTR_USAGE_TABLE: [(&[&str], &[usize]); 16] = [
	(&paths::SLICE_FROM_RAW_PARTS, &[0]),
	(&paths::SLICE_FROM_RAW_PARTS_MUT, &[0]),
	(&paths::PTR_COPY, &[0, 1]),
	(&paths::PTR_COPY_NONOVERLAPPING, &[0, 1]),
	(&paths::PTR_READ, &[0]),
	(&paths::PTR_READ_UNALIGNED, &[0]),
	(&paths::PTR_READ_VOLATILE, &[0]),
	(&paths::PTR_REPLACE, &[0]),
	(&paths::PTR_SLICE_FROM_RAW_PARTS, &[0]),
	(&paths::PTR_SLICE_FROM_RAW_PARTS_MUT, &[0]),
	(&paths::PTR_SWAP, &[0, 1]),
	(&paths::PTR_SWAP_NONOVERLAPPING, &[0, 1]),
	(&paths::PTR_WRITE, &[0]),
	(&paths::PTR_WRITE_UNALIGNED, &[0]),
	(&paths::PTR_WRITE_VOLATILE, &[0]),
	(&paths::PTR_WRITE_BYTES, &[0]),
	];

The "Why is this bad?" section can probably be fixed simply by explaining what, exactly, would cause Undefined Behaviour when using a null pointer:

## Why is this bad?
It is undefined behaviour to dereference or create a reference using a null pointer.
Functions such as `ptr::copy` and `slice::from_raw_parts` perform these operations internally,
so their safety preconditions require the use of valid pointers.

[jgarvin]

Huh, I would have expected from_raw_parts to require passing NonNull instead of a plain raw pointer. To the docs credit its safety precondition of not being null is documented, it just seemed preposterous that it could matter with length 0, but apparently does because of niches.