Compiler: fix bug related to if branch truthiness #7792
Conversation
asterite
added
kind:bug
| case node | ||
| when .and? | ||
| @last_is_truthy = cond_is_truthy && then_is_truthy | ||
| @last_is_falsey = cond_is_falsey || then_is_falsey | ||
| when .or? | ||
| @last_is_truthy = (cond_is_truthy && then_is_truthy) || (cond_is_falsey && else_is_truthy) | ||
| @last_is_truthy = cond_is_truthy || else_is_truthy |
There was a problem hiding this comment.
The bug was this line, which computes whether an or expression like a || b is always truthy or falsey.
As documented, something like:
a || bis turned into:
if temp = a # cond
temp # then
else
b # else
endSo seeing the above we can say that a || b is truthy when either a or b are truthy. But since the || is turned into the if above, it's when the cond part is truthy or when the else part is truthy (for the cond part the compiler will see through an assignment to check whether the assignment value is truthy).
Also note the symmetry of the resulting code with and.
The bug was that the old condition was nonsense: I didn't fully understand it at that time and just experimented with some combinations... shame on me. Or actually, I thought the version in this PR was correct but it didn't work for some reason. And the reason was that the variables @last_is_truthy and @last_is_falsey weren't reset before reaching this line, so their value was wrong.
So this PR fixes those things.
There was a problem hiding this comment.
Oh, and all of this is computed in order to know whether we can ignore some parts of an if: if the condition is truthy then there's no need to codegen the else part, we can always codegen the then part. Same but reversed when the condition is falsey.
|
@bcardiff @straight-shoota I left an explanation of what this PR fixes, let me know if you have questions :-) |
Fixes #7222