Closes #311

[alexnask]

@nddrylliog, can you take a look at the code? Seems to me it is fine, although I'm using the little trick to discard the expression after finding the variable decl type you had commented on a while back...
I'll test this some more tomorrow and merge if you think it is fine

[nddrylliog]

Commented code? Why do we need it?

[alexnask]

Oops >_>

[nddrylliog]

@Shamanas I added a few comments on the commits themselves, but most importantly: can you provide samples of generated code before/after the patch, in a clean manner like @duckinator did on #311?

Thanks!

[alexnask]

Ok here is our example file:

vararg: func(args: ...) -> Bool {
    false
}
f: func -> String {
    "f was called" println()
    "yay"
}
g: func -> Func -> Bool {
    "g was called" println()
    h
}
h: func -> Bool { false }
one: func {
    false ?  vararg(f()) : true
}
two: func {
    false ? g()() : true
}
one()
two()

Compiled before this commit, the program outputs:

f was called
g was called

And the C code rock outputs is:

void test__one() {
    struct { 
        lang_types__Pointer __f1;
        lang_String__String* __f2;
    } ____va_args5 = { 
        lang_String__String_class(), 
        test__f()
    };
    lang_VarArgs__VarArgs ____va6 = (lang_VarArgs__VarArgs) { 
        (void*) &(____va_args5), 
        NULL, 
        1
    };
    false ? test__vararg(____va6) : true;
}
void test__two() {
    lang_types__Closure test____comboRoot1 = test__g();
    false ? ((lang_types__Bool (*)(void*)) test____comboRoot1.thunk)(test____comboRoot1.context) : true;
}

After this commit, the compiled program outputs nothing and the C code generated by rock is:

void test__one() {
    struct { 
        lang_types__Pointer __f1;
        lang_String__String* __f2;
    } ____va_args5;
    lang_VarArgs__VarArgs ____va6 = (lang_VarArgs__VarArgs) { 
        (void*) &(____va_args5), 
        NULL, 
        1
    };
    false ? test__vararg((____va_args5.__f1 = lang_String__String_class(), ____va_args5.__f2 = test__f(), ____va6)) : true;
}
void test__two() {
    lang_types__Closure test____comboRoot1;
    false ? (test____comboRoot1 = test__g(), ((lang_types__Bool (*)(void*)) test____comboRoot1.thunk)(test____comboRoot1.context)) : true;
}

[nddrylliog]

Looks fantastic :)

[alexnask]

Ok then, merging

[nddrylliog]

@Shamanas this was merged, but ooc-lang/nagaqueen#14 wasn't? What's up with that?

[alexnask]

Hey I'm back (sorry for the absence again, have a couple of projects for uni >_>), I'll look at why this is.

[nddrylliog]

@Shamanas no problem, man. Welcome back :)

[alexnask]

(and by being back I really mean on weekends btw :P)

[nddrylliog]

@Shamanas So uh I notice ooc-lang/nagaqueen#14 is still open, yet that has been indeed merged a long time ago...

As far as I can see, rock redeclares its own nagaqueen prototypes so it.. kinda works? But nagaqueen.c declares onFunctionCallCombo as returning void so it really shouldn't work, and probably will crash with any optimization level > O1.

That's pretty bad.