Inliner heuristic for "illegal pointer argument" is incomplete.

[eddyb]

This is technically not a new issue, and most of it was fixed in:

• Calling methods on entrypoint argument struct members produces "Pointer operand must be a memory operand declaration" validation error #554
• Inline calls that look like f(&s.x) #777

But if we take the test for that (tests/ui/lang/core/ref/member_ref_arg.rs) and add another function g:

struct S {
    x: u32,
    y: u32,
}

fn f(x: &u32) {}

fn g(xy: (&u32, &u32)) {}

#[spirv(fragment)]
pub fn main() {
    let s = S { x: 2, y: 2 };
    f(&s.x);
    g((&s.x, &s.y));
}

Then only the (existing) f call is inlined, but the g call still produces:

error: error:0:0 - Pointer operand '22[%22]' must be a memory object declaration

This is because #777 banned specifically OpAccessChain function arguments (i.e. &s.x), but in the case of g, the pair is created and then (because it has ScalarPair ABI) the two pointer fields are extracted to call g.

Based on my reading of the SPIR-V standard, the only way to be fully correct here is to only allow OpVariables and OpFunctionParameters (instead of banning one thing or another).

cc @Shfty (who ran into this while doing some type/trait metaprogramming which I guess involved ref-pairs)

[eddyb]

The relevant validation rules are:

Any pointer operand to an OpFunctionCall must be

• a memory object declaration, or
• a pointer to an element in an array that is a memory object declaration, where the element type is OpTypeSampler or OpTypeImage.

(note that the existing check introduced by #777 already rules out the second case, because that would involve OpAccessChain, so we can treat it like "memory object declaration" is the only allowed case)

---

The Shader validation rules are even stricter than that though:

All declared types are restricted to those types that are, or are contained within, valid types for an OpVariable Result Type or an OpTypeFunction Return Type.

So the inliner checks can probably partition types into "pointer to OpVariable's contents" (valid for function parameters, too, for a subset of storage classes) and "pointer-free type" (valid for function return types).