MSL: Shader input overrides are not applied for block, array, and struct types

[spnda]

I found this during investigation of Vulkan CTS failures related KhronosGroup/MoltenVK#2116. For the following fragment inputs shader input overrides are not applied at all. Setting breakpoints on all usages of inputs_by_location shows that none of those codepaths are taken.

struct _14
{
    vec4 _m0;
    ivec3 _m1;
};

layout(location = 0) in _2
{
    flat _14 _m0[3];
} _19;

This generates the following MSL, regardless whether --msl-shader-input 1 any32 4 (which should widen the first int3 to int4) was specified. Also, the flat specifier is not being propagated properly.

struct main0_in
{
    float4 m_19_m0_0_m0 [[user(locn0)]];
    int3 m_19_m0_0_m1 [[user(locn1)]];
    float4 m_19_m0_1_m0 [[user(locn2)]];
    int3 m_19_m0_1_m1 [[user(locn3)]];
    float4 m_19_m0_2_m0 [[user(locn4)]];
    int3 m_19_m0_2_m1 [[user(locn5)]];
};

Note that this is a more complicated example, as this uses a struct within an array within a block, but as soon as any fragment inputs are within a block the shader inputs are ignored and not applied. Same happens with structs and arrays.

in _2
{
    layout(location = 0) vec2 _m0;
    layout(location = 1) flat uvec2 _m1;
} _15;

Shader outputs for the vertex shader using the same setup but for stage outputs are generated correctly.

I've attached a sample fragment shader that uses the above input setup:
17782185548125675323.spv.zip
This is the simplest example using just a block as shown above which also fails:
215374844162041042.spv.zip
And the tessellation shader with the same setup, where the shader outputs work correctly, if useful for debugging:
15478294089967604931.spv.zip

[HansKristian-Work]

Got a fix for the Flat propagation.

For the composites with override, there are many bugs. One of them is that OpLoad is too naive and only looks at the raw OpVariable.

		auto &expr_type = expression_type(ptr);

		// If the expression has more vector components than the result type, insert
		// a swizzle. This shouldn't happen normally on valid SPIR-V, but it might
		// happen with e.g. the MSL backend replacing the type of an input variable.
		if (expr_type.vecsize > type.vecsize)
			expr = enclose_expression(expr + vector_swizzle(type.vecsize, 0));

Need to rewrite all this junk ...