Removed return type inference from Image API

[oisyn]

By referring to concrete 'sibling' vector types from same vector library based on input.

@eddyb this currently causes an ICE in tests/ui/image/gather_err.rs

[eddyb]

Ref in Rust tends to pretty specifically tied to references, maybe this could be named MakeVectorType or even HasVectorType? Especially given that it's implemented by the "library" type.

[eddyb]

Whenever you have a bidirectional mapping like this, it's time to write a macro that takes in the information exactly once, e.g.:

macro_rules! glam_vector_impls {
    ($($scalar:ident {
        $($($n:literal : $ty:ident)),+ $(,)?
    }),+ $(,)?) => {
        $($(
            #[cfg(feature = "glam")]
            unsafe impl Vector<$scalar, $n> for glam::Vec4 {
                type VectorTypeLib = GlamVectorTypeLib;
            }
            #[cfg(feature = "glam")]
            impl VectorTypeRef<$scalar, $n> for GlamVectorTypeLib {
                type Vector = glam::$ty;
            }
        )+)+
    }
}
glam_vector_impls! {
    f32 => { 2:  Vec2, 3:  Vec3, 4:  Vec4 },
    f64 => { 2: DVec2, 3: DVec3, 4: DVec4 },
    i32 => { 2: IVec2, 3: IVec3, 4: IVec4 },
    u32 => { 2: UVec2, 3: UVec3, 4: UVec4 },
}

(you'd still have to keep the manual Vec3A impl since that's not bidirectional but that's about it)

[eddyb]

Hmmm, so this seems relevant:

• ICE, regression from stable/beta -> nightly: var types encountered in super_relate_consts when trait bound not satisfied rust-lang/rust#106240

Except, if you look at rust-lang/rust#106240 (comment) - we're not on a nightly that far ahead, so why would this happen sooner?

Talking to the relevant people, those linked PRs are actually not the original cause. Will work on reducing a testcase (EDIT: done: rust-lang/rust#106240 (comment)) but either way the fix is the same:

• Handle inference variables in CollectAllMismatches correctly rust-lang/rust#106322

Which hasn't been merged yet... also it sounds like the bug is in a trick I suggested a few weeks back for taking advantage of inference logic for diagnostic suggestion code.

---

However, if the problem is needing const N: usize params, we can probably do better by making the ImageCoordinate helper trait mirror the VectorTypeLib associated type from the Vector trait, reducing the need for the extra Vector bounds.

But also, I have even more bad news, that I only noticed while looking for the ImageCoordinate impls:

rust-gpu/crates/spirv-std/src/image/params.rs

Lines 63 to 70 in a5e05e4

	impl<S: Scalar> ImageCoordinate<S, { Dimensionality::OneD as u32 }, { Arrayed::False as u32 }>
	for S
	{
	}
	impl<S: Scalar> ImageCoordinate<S, { Dimensionality::Buffer as u32 }, { Arrayed::False as u32 }>
	for S
	{
	}

C params (before this PR) could be individual scalars, for 1D images. I don't know at this moment how to make both that and the return type stuff, work.

It may require adding a generic parameter for the "vector type lib" itself and setting things up that for vector Cs, ImageCoordinate constraints it (forcing the image op return type to be inferred) while for scalar Cs, it's unconstrained and can somehow be inferred from the image op return type.

[oisyn]

I'm closing this as we're taking a completely different approach to this.