Re: [PATCH v4 2/7] rust: types: introduce ForLt base trait for CovariantForLt

[Danilo Krummrich]

On Sat Jun 27, 2026 at 2:26 PM CEST, Miguel Ojeda wrote:
> If this goes in at the same time as the move (as I assume), then am I
> understanding it right that if someone else was using `ForLt`
> (trait/macro) things would either break at compile-time (which is OK)
> or, in the covariant type case with no `cast_ref()`, it would build,
> but someone could in principle have relied on `ForLt` providing the
> covariance guarantee in unsafe code?

If someone would have unsafely asserted covariance for ForLt it would break at
compile-time like this:

	error[E0199]: implementing the trait `types::for_lt::ForLt` is not unsafe
	   --> rust/kernel/pci/io.rs:158:1
	    |
	158 | unsafe impl<const SIZE: usize> ForLt for Bar<'static, SIZE> {
	    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	    |
	help: remove `unsafe` from this trait implementation
	    |
	158 - unsafe impl<const SIZE: usize> ForLt for Bar<'static, SIZE> {
	158 + impl<const SIZE: usize> ForLt for Bar<'static, SIZE> {
	    |
	
	error: aborting due to 1 previous error

The only way this could silently break would be to use ForLt!(), but then don't
use the explicitly provided safe cast_ref() method, and instead open-code it
with an unsafe transmute() assuming covariance from ForLt!().

Even though very unlikely, I do however have an eye on whether another user of
this API appears.

(The whole series also goes into a topic branch based on -rc1 anyway, so I can
also always provide a signed tag with just patch 1 and 2 based on -rc1 should
the need arise.)

> Acked-by: Miguel Ojeda <ojeda@xxxxxxxxxx>

Thanks!

> We could take the chance to add some missing intra-doc links, but I
> can add a good first issue.

I can add them on apply, or we leave them as good first issue, as you prefer.

Thanks,
Danilo