Bugfix: Block is incorrectly being reset when an else condition precedes an if condition.

There is a logic mistake where the "else" is not being considered when determining when to reset the block.
This results in the block states being reset when the previous operation is an "else" condition.
This results in the second else condition potentially running even if the prior condition already ran.

This was discovered when investigating Github actions test failures that pass locally.
The Github actions tests use a special test argument that I had not tested locally with.

diff --git a/level_3/fake/c/private-make-operate_block.c b/level_3/fake/c/private-make-operate_block.c
index 37fc960414de77a8397acb9b16133794265a848c..38b7da251204889f893b6f96b3285c56057a71b1 100644 (file)
--- a/level_3/fake/c/private-make-operate_block.c
+++ b/level_3/fake/c/private-make-operate_block.c
@@ -13,8 +13,8 @@ extern "C" {
 
         if (state_process->operation == fake_make_operation_type_if_e) {
 
-          // When another if condition follows a non-if, non-and, and non-or, then this is the start of a new condition block.
-          if (state_process->operation_previous != fake_make_operation_type_if_e && state_process->operation_previous != fake_make_operation_type_and_e && state_process->operation_previous != fake_make_operation_type_or_e) {
+          // When another if condition follows a non-if, non-and, non-or, and non-else, then this is the start of a new condition block.
+          if (state_process->operation_previous != fake_make_operation_type_if_e && state_process->operation_previous != fake_make_operation_type_and_e && state_process->operation_previous != fake_make_operation_type_or_e && state_process->operation_previous != fake_make_operation_type_else_e) {
             state_process->block = fake_state_process_block_operate_e;
             state_process->block_result = 0;
           }