fix: capturing deep composites

[molikto]

try fixing https://github.com/EmbarkStudios/rust-gpu/issues/873 . context is this https://github.com/EmbarkStudios/rust-gpu/pull/690#pullrequestreview-719958024 .

The tests I added still errors, but a different one compared to what I am trying to fix.

But the wired thing is, if I compile the tests using my own setup in my own repo, it compiles successfully, but in the tests it fails with a different error. Also this change fixes my original problem (in my own repo).

[molikto]

LGTM modulo comments, but I am a bit confused: is it actually possible for us to end up with OpCompositeInserts with multiple indices? Do we have a pass that generates those? (I'm asking because AFAIK, rustc_codegen_ssa sure doesn't have the ability to emit anything similar, at most it does single-level and usually only for ScalarPair anyway)

I suspect it's if a closure captures an storage buffer (&[u32]) and then another acceleration structure, the closure capturing generate a top level composite, then the array is another composite (len and pointer)

[eddyb]

I suspect it's if a closure captures an storage buffer (&[u32]) and then another acceleration structure, the closure capturing generate a top level composite, then the array is another composite (len and pointer)

That's true at the type level, but is there something that generates the equivalent of .field.subfield extracts/inserts in a single SPIR-V instruction? (as opposed to what rustc_codegen_ssa might generate for such independent operations, of one instruction for .field and one for .subfield - tho it usually only does pointer offsets, not even by-value extract/insert)

[molikto]

I suspect it's if a closure captures an storage buffer (&[u32]) and then another acceleration structure, the closure capturing generate a top level composite, then the array is another composite (len and pointer)

That's true at the type level, but is there something that generates the equivalent of .field.subfield extracts/inserts in a single SPIR-V instruction? (as opposed to what rustc_codegen_ssa might generate for such independent operations, of one instruction for .field and one for .subfield - tho it usually only does pointer offsets, not even by-value extract/insert)

it seems when I simplify my reproduction the error is gone, but my original shader does have multi index CompositeInsert. So the testcase isn't correct. Will try to get a new testcase if possible