Issue with brace syntax about commandhelper HOT 3 CLOSED

Comment by PseudoKnight

I've run into similar bugs in the compiler optimizer. In fact, there's some super strange ones. If you embed an if(a) inside of an if(b){} then it'll convert it to if(a && b){} ... sometimes. This is almost always undesirable so I have to work around it. What's weird is that it depends on what I'm checking in the if(). Some functions will cause it while others won't.

Unfortunately I think we'll have to wait for the compiler rewrite for a fix, unless this is deemed critical enough. I could be wrong.

from commandhelper.

Comment by LadyCailin

I don't think this is an issue anymore. I fixed some of the biggest issues in the current compiler, this being one of them. I did confirm with the optimizer test that it's compiling correctly, which it appears to be (comments mine): http://paste.thezomg.com/10612/61030971/ As you can clearly see (lol) the cancelled message is being sent as the third argument to the ifelse, so I'm going to close this as fixed.

Also, PseudoKnight, FYI, both of these are ALWAYS equivalent:

if(@a){
    if(@b){
        msg('hi')
    }
}

and

if(@a && @b){
    msg('hi')
}

But if and only if there are no other statements other than the if (including an inner else/else if) in the outer if, and as it turns out, doing the one if with an and is faster than two ifs. This is of course a micro-optimization, but that's what compilers are for :)

from commandhelper.

Comment by PseudoKnight

Yes, there were other statements in the outer if() in code where I was encountering that bug. It was a headache to figure out what exactly was causing the logic problem in my code. It was optimizing when it shouldn't have. I have no idea if it's fixed as it was hard to reliably recreate, as I mentioned. I'll start using brace syntax in these situations again and let you know if I encounter it again.

from commandhelper.