The version directive really does only some error checking, and
only GL_EXT_multiview and GL_GOOGLE_include_directive are supported for
extensions, but enable/disable work (but not yet warn for multiview).
Using set_line_file sort of worked with its stack, but line directives
embedded in the source (which glsl's initialization code uses) messed up
the start path for quoted include searches.
There's no direct support for namespaces in Ruamoko yet, nor even in
qfcc, but glsl's blocks bring in a bit of foundation for them, even the
concept of "using" (for blocks with no instance name).
The members don't get locations allocated to them yet, but
fstrianglest.vert compiles and links correctly otherwise.
Also, there's no error checking yet.
The unification of qc and c function symbol handling made it important
that the new symbol was a proper duplicate (minus being in a table) of
the old symbol. This fixes redeclared prototypes (especially for
qc-style functions, not encountered for c-style). Complete with unit
test :)
Other than contructors (and problems with the `out` block) qfcc can
compile fstrianglest.vert to what looks like working ruamoko code.
There's still a lot of work to do, though.
Using a struct with function pointers instead of switching on an enum
makes it much easier to add languages and, more importantly,
sub-languages like glsl's shader stage variants.
Simply referencing the original metafunc resulted in only the first
variant getting a def. Now my little test generates defs for all called
variants of a generic function.
However, I'm still not sure this is quite the direction I want to go
with making calls to generic functions, but I still need to figure out
defining them. I think making progress with the glsl front-end will
help.
Checking only the last function to be added results in false negatives
and thus duplicates when defining a generic function. eg:
genFType radians (genFType degrees);
genDType radians (genDType degrees);
genFType radians (genFType degrees) = #0;
genDType radians (genDType degrees) = #0;
Detecting generic functions needs to be done before finalizing the
function type for non-generic functions, otherwise the resulting
function type winds up being incorrect due to bogus resolution of the
return type (and probably a few other factors).
This takes care of handling the return type in function definitions as
well as declarations as
I don't know why I didn't apply the same ideas as in methoddef, maybe I
just forgot. I'm pretty sure I did methodproto first, or maybe cleaned
up methoddef much later then didn't think of methodproto. Still, the
grammar is much nicer to read now.
Arrays of functions or functions that return arrays or functions aren't
valid. While working on how to get generics in properly, I finally
understood what's going on with function types in the specifier, and I
think I'll be able to sort out function pointers vs prototypes, too.
Generic qc-style prototypes don't work but both c and qc style
definitions get as far as trying to build the builtin function. It
starting to look like I need to rework function handling, which isn't
all that surprising as it hasn't changed much over 22 years.
I never did like overloaded_function_t as a name, and with the
introduction of generic functions (or templates, I guess?) meta-function
makes more sense to me.
Most of them were noise from the type const correctness pass, but the
qc field function handling was always dubious (though in practice safe
due to how the type was built, but...). The remaining casts outside of
type.c need some thought.
I was investigating how qcc dealt with field fields and got segfaults
from qfprogs due to the lack of type encodings. While the resulting
output is not guaranteed to be correct (especially if trying to dump
progs compiled by some other extended compiler), at least it's better
than segfaulting or any other UB.
There's still the problem of defining implementations, but this gets a
lot of things working so long as the return type is one of the parameter
types rather than computed.
While much is broken, especially textures, e4m8.map successfully imports
into blender 4.2-ish, and even the entity relation lines seem to work
(which surprised me as those were the first sign of trouble).
And document type expressions to a certain extent. A lot of work needs
to be done as there's a lot of bitrot in the information in the doc (eg,
integer is now int, array declarations, etc).
A working call isn't produced yet, but the generic function does seem to
be selected correctly preferring a minimum of type promotions, though I
suspect I'll need to do more work on the selection process.
Mainly to prevent promotion between different vector and matrix sizes,
but also to be consistent in that double doesn't promote to itself (same
as other scalar types). Also fix up type_rows and type_cols for matrices
and make type_assignable, type_promotes, and type_compatible null-safe
(always false if either src or dst is null).
With this, genFType and genDType functions are now treated separately
and expanding to all components (single row or column matrices are not
supported (at this stage, anyway) for generic parameters).
That is, `@generic(...) { ... };`, which is handy for bulk declarations
(such as for glsl). This proved to be a lot harder than expected, I
suspect handling of specifiers needs a lot of work.
