When an IF sits in the condition of another IF, BranchPruner only
looked at the immediately enclosing IF to decide which branch the
condition tokens depend on. If that enclosing IF was itself still in
its condition, nothing was recorded, so the link to an outer IF whose
branch is being pruned was lost. Those tokens were then evaluated and
left on the stack while the rest of the branch was pruned, and the
calculation ended with "internal error".
Walk up the stack of enclosing IFs to the closest one whose then or
else branch contains the nested IF instead.
Fixes#3790Fixes#3755
While we might never be able to have 100% of our code strict, we can at
the very least do it for all of our tests. This ensures that our tests
are using our API with the types as intended by the test author, and not
silently be cast to what our API requires.
Calculation engine was resolving every function by first resolving its arguments
including IFs, this was causing significant over evaluation when IFs were used
as it meant for every case to be evaluated.
Introduce elements to identify ifs and enable better branch resolution
(pruning). We tag parsed tokens to associate a branch identifier to them.
Closes#844
HawkForge
oleibman
Adrien Crivelli
Fräntz Miccoli