Found out that the variableEnv is only required
for two use cases: To expose the exception in the
catch statement, and to create temporary
environments for the with() statment. Both can be
better handled differently and don't require the
overhead of two environments.
Change-Id: I149e1fd7bdfc3267544b141b6f94e46e42cf641b
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This currently mainly intended to be useful in a C++ debugger. The
infrastructure makes it a lot easier to access (parent) contexts, find
function names, etc.
Change-Id: I0493d3a3bd4bf5c3a03379c1a2b545ed76862cd5
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
This change uniques string pointers, so the String::isEqualTo will more
often succeed in the pointer-equality case.
Change-Id: I1d4f1a70147c48bc75359642a56a0446b5fbf199
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
The result variable in the context is not really
required, as we can return results directly in the
return value register.
Change-Id: I12554c228500aa24625ef82e31fd7f72989a71bb
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
A factory is now passed along to do the codegen for eval().
Change-Id: If15b1f28c9c0a8f8b6d18b56d6e7bc5d942927e5
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Make the ExecutionContext standard compliant.
Move most of it's members into a new
DeclarativeEnvironment data structure that
contains locals and arguments.
Change-Id: I094f559168810dbd3717d677fe28750076015976
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Lars Knoll
Erik Verbruggen