partially fix return in try; optimizer replaces JMP->ENDTRY with only ENDTRY

[Hecate2]

Fixed return in multiple layers of nested try context. Still a dangerous case is not solved. Commented in tests.

def internal_():
  try:
    try:
      return a
    finally:
      throw
  finally:
    ...

def external_():
  b = 1
  try:
    a = internal_()
    # internal_ generates a return value in evaluation stack,
    # but never stored into local variables here
  catch:
    return b

throw is executed and nothing should be returned in this case, but the value of a is remained in the evaluation stack, without being handled by the external context.

Also the assembly is not the most optimal. There is a JMP to an ENDTRY. The JMP is unnecessary.

[Hecate2]

Should this be solved in Neo VM? Evaluation stack should be cleared when invocation stack is popped with exception

[Hecate2]

I think the VM should be responsible for clearing the evaluation stack when exception is thrown.

http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2010Q2/ExceptionHandling.pdf

1.4 Some rules about stack-emptiness

• endfinally empties the evaluation stack as a side-effect
• The evaluation stack shall be empty after the return value is popped by a ret instruction.
• Exception handlers can access the local variables and the local memory pool of the routine that catches the exception, but any intermediate results on the evaluation stack at the time the exception was thrown are lost.
• An exception object describing the exception is automatically created by the CLI and pushed onto the evaluation stack as the first item upon entry of a filter or catch clause.

[nan01ab]

I think the VM should be responsible for clearing the evaluation stack when exception is thrown.

http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2010Q2/ExceptionHandling.pdf

1.4 Some rules about stack-emptiness

• endfinally empties the evaluation stack as a side-effect
• The evaluation stack shall be empty after the return value is popped by a ret instruction.
• Exception handlers can access the local variables and the local memory pool of the routine that catches the exception, but any intermediate results on the evaluation stack at the time the exception was thrown are lost.
• An exception object describing the exception is automatically created by the CLI and pushed onto the evaluation stack as the first item upon entry of a filter or catch clause.

Great proposal.

[newera-001]

tightly strong leader！