Also move the ALLOC/FREE macros from qfcc.h to QF/alloc.h (needed to for
set.c).
Both modules are more generally useful than just for qfcc (eg, set
builtins for ruamoko).
Also remove the extern for current_storage as it belongs in shared.h.
I'm not satisfied with the documentation for initialize_def, but it will do
for now. I probably have to rewrite the thing as it's a bit of a beast.
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).
The structvar2 = structvar1 is implemented as a move expresion, which
address_expr didn't like. Return the address of the source. For indirect
move expressions, this is just the source expression itself.
It seems the dag creation algorithm doesn't like "a = a op a", so use
"b = a op a" instead. Since I plan on fixing temp leaks anyway, this won't
be a problem (also, few people even use qfcc's v6 float modulo :P).
All internal structs now have "proper" names, and fit the naming convention
(eg, obj_module (like objective-c's types, but obj instead of objc). Some
redundant types got removed (holdovers from before proper struct tag
handling).
Also, it has proven to be unnecessary to build internal classes, so
make_class and make_class_struct are gone, too.
As id and Class do not point to real objects as such, trying to get the
class from their types doesn't work, so instead send the message to a
"null" class that skips the method checks.
Type names are cleaned up, as is the creation. Also, the class pointer in
the type encoding now gets emitted. However, Still need to actually create
_OBJ_CLASS_Class and fix the type encoding reloc handling in the linker.
The common cause seems to be casting a cast (very common, and I'm not sure
just realiasing the expression would be right). It does't cause any harm
(particularly, it doesn't trigger alias def chains), so I won't worry about
it.
The special token __INFINITY__, like __FILE__ and friends, will expand to
a floating-point expression containing a value the C compiler considers
infinite. Obviously, this assumes that the system has relatively modern
float hardware -- but if it doesn't, having Ruamoko be able to represent
float infinity is the least of your problems. :)
Look in the entity field symbol table for the field before looking in the
normal symbol table. This allows entity fields to be accessed even when
the current scope has symbol of the same name. However, checking the
normal symbol table where there is no such field allows for field
variables when I get around to implementing them.
