With the intoduction of the statement type enum came a prefix clash. As
"st" makes sense for "statement type", I decided that "storage class"
should be "sc". Although there haven't been any problems as of yet, I
decided it would be a good idea to clean up the clash now. It also helps
avoid confusion (I was a bit surprised after working with st_assign etc to
be reminded of st_extern etc).
This required throwing out the primary rules that snax did up to help me
with conflicts many years ago, but they were now getting in the way. Now
the productions from primary are merged in with unary_expr.
Since gnu bison and flex are required anyway, no harm in using their api
prefix options. Now, qfcc can compile both QC/Ruamoko and Pascal files
(Pascal is (currently?) NOT supported in progs.src mode), selecting the
language based on the extension: .r, .qc and .c select QC/Ruamoko, .pas and
.p select Pascal, while anything else is treated as an object file (as
before).
Assignment of nil to a field function is permitted, but trying to use one
as a builtin or as a normal function is treated as an error.
.void (float y) func; OK
.void (float y) bi = #0; error
.void (float y) ni = nil; OK
.void (float y) co = { }; error
The parser wants to treat .float () foo; as a function returning a float
field, but qcc treats it as a field holding a function variable.
Fortuantely, field types are always "simple" (ie, at worst, just more
field type wrappers around the non-field type), so all that's needed to
obtain qcc grammar is to reach into the field type layers and do the
function type calculation based on the non-field type found there.
Due to ambiguities in the grammar, qc-style function params and c-style
function params had to be completely separated. This means that qc-style
functions can not use pointers and must use qc-style function declarations
for parameters, and c-style functions must use c-style param declarations.
While this rule is tedious for converting the Ruamoko library, it does
actually make for a more consistent language.