It returns the number of elements in a type (so something like `countof`
(hopefully that's what the up-coming C feature will be called) can be
implemented), but it applies to structs, vectors, etc (eg, 9 for mat3).
Explicitly typed compound initializers are what C uses and allows them
to initialized `auto` vars and even pass through `...`. Not tested yet
other than ensuring existing tests didn't break.
While storing the scope in a block was the right idea, the
implementation wasn't quite right as it resulted in the current scope
getting set at the wrong times resulting in incorrect symbol access when
shadowing was in effect.
I guess that was a mental FIXME for later, but later came sooner. The
declaration doesn't seem to be working properly, but I'll worry about
that later when I can get some automated tests going.
I'm not sure whether I'll stick with the current encoding, but it turns
out it's necessary to separate function types on parameter qualifiers (I
was half expecting that, though).
Because spir-v's bools are abstract and have no specific size, bool and
lbool need to both have the same spir-v id, as do the vector
counterparts, so when one gets emitted, the id is copied to the mirror
type.
Since spir-v needs actual bools for its conditional instructions, the
time to do bool properly finally came. As expected, the changes caused
quite a mess, but Ruamoko now does bool/true/false.
The tags might have other uses thus the generic term, but this allows
spir-v variables to be declared with the correct pointer storage
classes. Now spirv-val is complaining about my interfaces, so progress :)
Non-const params use references and so need somewhere to store the
arguments. Local variables could be passed directly (parameters normally
require function storage class, which local variables are), but that's a
potential optimization for later.
This required adding a `var` symbol type. For now, it holds just the
storage class, but it might be good for the initializer, too.
Also, clean up some pointer/reference inconsistencies.
As I suspected, the dereference was premature, although it can act as an
optimization when multiple fields of an object are accessed, though it
won't work for writes to lvalues (which means my fixes for spir-v
code-gen currently don't work for lvalue writes). Still, progress. Need
to get field member ids set.
It turns out my field access processing works well enough for vectors.
I'm not sure about pointer access as I may have done the pointer
dereference prematurely.
This gets parameter qualifiers to the parameters and thus `const`
parameters work as expected (even passes validation). However,
in/out/inout do not work yet due to incorrect setup of the function
call: spir-v wants them to be passed by reference (pointers) rather than
by value.
The function parameter and argument types are a mess with respect to
references (and thus calls don't pass validation) but the generated code
seems to be otherwise correct.
It wasn't quite as nasty as I thought, but splitting it up helps add a
little self documentation and, possibly more importantly, simplify
navigation through the type checks and argument setup.
I've long felt build_function_call was getting a bit big, and expr.c
especially so. This should make it easier to rewrite build_function_call
for dealing with target-specific code. As a bonus, the int through ...
warning is already cleaned up.
spir-v uses SSA, so temps cannot be assigned to directly, so instead use
the temp expression as a reference for the result id of the rhs of the
assignment. This would get function calls working if the they actually
emitted any code (right now, just a place-holder id so spirv-dis doesn't
fall over).
Also, fix some missing docs. Unfortunately, there are still some
problems (incorrect resolution for multiple files/functions with the
same name, and a bug with doxygen's verbatim/code blocks).
Ruamoko and v6(p) have their own copies despite being (currently) the
same, and spir-v's is currently empty, but now targeting spir-v doesn't
try to emit ruamoko code.
