The old code didn't work correctly if you had member decorations after
non-member decorations. Since glslang never gave us any of those, it
wasn't properly tested.
This gets tricky in a few places because we have to pass vtn_sampled_image
values through OpAccessChain, but it works ok. At some point, it probably
needs to be cleaned up but it doesn't occur to me exactly how to do that at
the moment. We'll see how this approach goes.
Instead of just stomping on the mode, it now validates asserts that the
previously set mode is correct and only changes it if needed. We need to
do this because, in geometry shaders, there are some builtins that can be
either an input or an output depending on context. We can get that
information from the SPIR-V source but we can't throw it away.
Previously, we were trying to handle them later when loading. However, at
that point, you've already lost information and it's harder to handle
certain corner-cases. In particular, if you have a shader that does
gl_PerVertex.gl_Position.x = foo
we have trouble because we see the .x and we don't know that we're in
gl_Position. If we, instead, handle it in OpAccessChain, we have all the
information we need and we can silently re-direct it to the appropreate
variable. This also lets us delete some code which is a nice side-effect.
When we get to the end of the _vtn_load/store_varaible recursion, we may
have one link left in the deref chain if there is a vector component select
on the end. In this case, we need to truncate the deref chain early so
that, when we make the copy for the load, we don't get the extra deref.
The final deref will be handled by the vector extract/insert that comes
later.
Previously, our location handling was focussed on either no location
(usually implicit 0) or a builting. Unfortunately, if you gave it a
location, it would blow it away and just not care. This worked fine with
crucible and our meta shaders but didn't work with the CTS. The new code
uses the "data.explicit_location" field to denote that it has a "final"
location (usually from a builtin) and, otherwise, the location is
considered to be relative to the base for that shader stage.