Now Eval() and EvalPath() recover from internal panic and
return it as error with call stacks.

This fixes the case where user code calls os.Exit(1), which is
converted to panic() and breaks down the program.

Fix interp.isEmptyInterface to tolerate a nil type.

Fixes traefik#1619

Simplify frame management. Remove node dependency on frame pointer.

Fixes traefik#1618

Ensure that the code generated for `for s, _ = range ...` is the same as `for s = range ...`.

Fixes traefik#1622.

If you `(*interp.Interpreter).Use` a variable, you should be able to assign to it.

Fixes traefik#1623

Fixes traefik#1640.

Follow by the [Spec](https://go.dev/ref/spec#Assignment_statements):

The number of operands on the left hand side must match the number of values. For instance, if f is a function returning two values `x, y = f()` assigns the first value to x and the second to y.

In the second form, the number of operands on the left must equal the number of expressions on the right, each of which must be single-valued, and the nth expression on the right is assigned to the nth operand on the left.

Fixes traefik#1606

…nction

This fixes issue traefik#1634 

includes special case for defer function.

I could remove or significantly reduce the comment description, and just have that here for future reference:

// per traefik#1634, if v is already a func, then don't re-wrap!  critically, the original wrapping
// clones the frame, whereas the one here (below) does _not_ clone the frame, so it doesn't
// generate the proper closure capture effects!
// this path is the same as genValueAsFunctionWrapper which is the path taken above if
// the value has an associated node, which happens when you do f := func() ..

…o 1.22 behavior

This builds on traefik#1644 and adds automatic per-loop variables that are consistent with go 1.22 behavior.  See traefik#1643 for discussion.

This is still a draft because the for7 version ends up capturing the per-loop var values when they are +1 relative to what they should be.  Maybe somehow the incrementing and conditional code is somehow capturing the within loop variables and incrementing them?  not sure how that would work.  anyway, need to investigate further before this is ready to go, but pushing it here in case there are other issues or someone might figure out this bug before I do..

When parsing binary operator expressions, make sure that implicit type conversions for untyped expressions are performed. It involves walking the sub-expression subtree at post-processing of binary expressions.

Fixes traefik#1653.