Emit llvm dereferenceable in more cases on newer LLVM versions

[WaffleLapkin]

On llvm >= 23 emit dereferenceable even without nofree, since llvm/llvm-project#204795 makes dereferenceable act "at a point" / not imply nofree.

r? nikic

I thought this will be a bit harder change, but since your refactoring in #156281 it's actually trivial ^^'

Draft because I don't think this can be tested prior to LLVM update. I'm also not sure if the version check I did is the appropriate one...

cc @RalfJung

[nikic]

Yeah, we should wait until the LLVM 23 upgrade so we can properly test this.

View changes since this review

[RalfJung]

With LLVM 23 we can also put dereferenceable on &Cell arguments, on &mut !Unpin arguments, and on &T/&mut T return types for all T. Does this PR do all that?

[WaffleLapkin]

@RalfJung yes. What currently stops dereferenceable from being applied to &!Freeze and &mut !Unpin arguments, and references in return types, is that in all these cases we don't set NoFree:

rust/compiler/rustc_ty_utils/src/abi.rs

Lines 406 to 424 in f10db29

	// NoFree is not valid on return values. If it were, it would mean something like
	// "will not be freed until the end of the program", which is generally not valid for
	// references.
	let no_free = !is_return
	&& match kind {
	// Non-frozen shared references are not necessarily dereferenceable for the
	// entire duration of the function
	// (see <https://github.com/rust-lang/rust/pull/98017>).
	PointerKind::SharedRef { frozen } => frozen,
	// Mutable references to potentially self-referential types are not necessarily
	// dereferenceable for the entire duration of the function
	// (see <https://github.com/rust-lang/unsafe-code-guidelines/issues/381>).
	PointerKind::MutableRef { unpin } => unpin,
	// Box may be deallocated during execution of the function.
	PointerKind::Box { .. } => false,
	};
	if no_free {
	attrs.set(ArgAttribute::NoFree);
	}

With NoFree no longer being required, they will all become dereferenceable.

I suppose another way to put this is that rustc already uses dereferenceable-at-a-point semantics since #156281, and applies dereferenceable-at-a-point everywhere it's valid. The only check that prevents llvm dereferenceable from being applied in cases you mentioned, is the one that I'm changing in this PR.

[RalfJung]

Nice, that's what I was hoping for. :)

This will be much easier to review once we actually have LLVM 23 and can look at the codegen test diff.