Christoffer Lerno
Christoffer Lerno
It's in the implicit casts in the LiteralAnalyser when mixing uXX with iXX values.
Another issue reading the code is that it's unclear (when I read the code) what information is encoded in the AST during different analyzer passes. Reading the code it looks...
Can we some document outlining all passes on the AST and what's resolved / not resolved after each pass? Maybe introduce an explicit state so that we can assert early....
I have some code where the state of the file analysis class is very clearly set with assertions to show what code can be called when. It's in a branch...
For the sizeof problem, we should actually kick that over a standard "typeOf" expression, that will resolve the ambiguity: sizeof(typeof(a*)) sizeof(Handle*) Here again it might be better to use a...
Another way would be to use `sizeof(type i32*)` again that resolves the ambiguity in the grammar.
I opened #69 to decide whether this should be trivially solved by the naming rules. It depends on whether you want to backpedal on naming rules later on, but even...
Also, I think that sizeof might want to return the size of any expression. So: i32 x = sizeof(a = 12); i32 y = sizeof(a.call().foo()); Should all be fine and...
Apparently the above works fine in C, so I'll implement it that way.
Ok, found another ambiguity, which is very bad: sizeof(Foo.a) Here it is not clear if we mean the size of the field a in foo, or if we refer to...