also store "toString" and "valueOf" as identifiers
in the engine and fix two places where we compared
strings the wrong way.
Change-Id: I70612221e72d43ed0e3c496e4209681bf254cded
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Change Exception.value() and a few other places.
Change-Id: I53ce17e5656e260138b1ac7f6d467e4636c0a0b9
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Also rename Value::toQString() to Value::toQStringNoThrow(),
and add a throwing toQString() method for JS use.
Change-Id: I821b33fc61abb7d08839df965fd337685f61a545
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Rather use the correct internalClass directly when constructing
the objects.
Change-Id: I8e916f1ce8f83d291c08ca6332fe85b1f57b90b5
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
The prototype is actually the same for most objects. By
moving it into the internal class, we can save 8 bytes
per object, as well as allowing for some future
optimizations.
Also fix a bug in the implementation of the Error
prototype objects.
Change-Id: I4d4b641055f644a9b088f27be34bfdb0446279b7
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This allows faster pass through of the data if we have
nested calls.
Also make sure we always reserve at least
QV4::Global::ReservedArgumentCount Values on the
stack to avoid stack corruption.
Change-Id: I42976460f1ef11a333d4adda70fba8daac66acf3
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
In the case of imported JavaScript files, it may happen that we parse the JS once
and then re-use it across different places where it is imported. That means we
parse and compile the JS once, keep the QV4::Script around and call it as a function
closure with different qml global objects (contexts), depending on where it is
imported from.
In this situation it is possible that the QV4::Script's run() is called once, a
new function object is created, we call it to return the JS library to "eval"
itself into the qml scope and afterwards it may happen that the function object
is garbage collected. It is at this point possible that the compilation unit's
refcount therefore also drops to zero, and thus subsequent calls to
QV4::Script::run() that create new QQmlBinding objects will access a dangling
compilationUnit pointer.
This patch fixes that by making QV4::Script - which is holding a QV4::Function
pointer - also have a persistent, which maintainers a refcount on the
compilation unit. If the script dies, the persistent will get collected and
the last deref will delete the unit. A script can however outlive the engine,
but PersistentValue has the mechanism built in to free itself on engine
destruction, which will also deref the unit accordingly.
Change-Id: I0a7f4e64497bde423ffa55c705af55cdb7d29cf2
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
QQmlError provides the same functionality, so let's rather
use that where required. Remove the dependency of
codegen onto the ExecutionContext that was only
required for error handling.
Change-Id: Ib0b61c0e138f89ff989c32996c93c339e4b62223
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
This adds breakpoint support to the Debugger, a helper function in the engine
for enabling debugging (which will switch from JIT to the interpreter) and a
DebuggingAgent interface, for use by v4 clients.
Change-Id: I78e17a6cbe7196b0dfe4ee157fc028532131caa3
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
This is in preparation for some platform specific code regarding throwing
exceptions, as well as a general cleanup :)
Change-Id: I23fb4f12fd09423a1f2cb225145780925002677b
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
* Replace QUrl with QString in V4 for the source location (we don't need URL parsing)
* Replace line number and file in QV4::Exception with the information we retrieve from
the stack trace of the exception.
Fixes about five tst_qqmlecmascript tests that relied on correct file/line number information
Change-Id: I2a3daa72be6c5587fd965211ea8f6fb77142e7ee
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Add support for debug annotations on statement boundaries to the
IR, to get accurate line/column information
* Use binary search to retrieve the function and line number for a given
program counter
* Save the stack trace in the exception class and print it in v4
* Fix initial line number in QV4::Script to start a 1, just like the initial column
in QQmlJS::Lexer also starts at 1
The native stack frame tracing is currently only implemented on Linux and Mac OS X.
The implementation for Windows using StackWalk64 is still missing.
Change-Id: I771fe44816397e29c69952772a772bf0d985236f
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fix a regression in Script::run, and compilation for
v4 and an auto test.
Change-Id: I4026eebec0e02f4af03ca49ba714916ad90b34e7
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Better naming for the methods, deinline some code, add a generic
path for setters and prepare for moving parts of it into the
Managed's vtable.
Change-Id: Ide8d32181fdabdf34c910db20b28fb8f87167570
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
In a way that it the compiler doesn't complain anymore.
Change-Id: I877b1a051b2ffcbd63a04cf219733b2b21cb9128
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Instead the JS exception value is now part of the C++ Exception object.
This also allows getting rid of some run-time functions.
Change-Id: I43ff773cacd5e925ba96601f3633ccf3b62273be
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
This will allow for re-use from the v8 wrapper API.
Change-Id: I2330432dad43d7fd7af6147e96a0cbbb340cd917
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Instead of doing the ExecutionContext unwinding at the time of throw, do it
at the time of catch, conveniently through an accept() method of the Exception
object. That allows us to get rid of the separate handler registration stack.
The only tricky part are that some execution contexts are allocated on the stack.
When exceptions are thrown through that, we have to catch, unwinding up until that
point (or rather the parent of the stack allocated context that's going to be
deleted) and then simply rethrow.
This patch also gets rid of the __builtin_delete_exception_handler. The next patch
will rename the remainder to what it really does now.
Change-Id: I00bb113b3a2fe24f7054c03fdfb8fed5cc1258b1
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Instead of registering catch handlers with setjmp and throwing JS exceptions
with longjmp, they are now thrown and caught as C++ exceptions. This allows for
tight interoperability between C++ and JS in the future and allows for clear
semantics with regards to cleaning up memory in the engine when throwing
exceptions. (destructors are guaranteed to be called, unlike with
setjmp/longjmp).
The recent unwind table additions allow for the exceptions to be thrown through
JIT generated code.
Catching the exception is done by re-using the existing IR semantics where the
beginning of a try block is marked by registering an exception handler.
Execution after the registration continues conditionally, based on the return
value of builtin_create_exception_handler. A return value of is 0 the try
block(s) are executed. If an exception is thrown during that time, execution
resumes at the point where builtin_create_exception_handler returns, but with a
return value of 1. If an exception is thrown within the catch handler, the
execution resumes again at the same point, but the inCatch IR variable will
guide execution straight to the finally block(s), which calls
delete_exception_handler.
In the JIT as well as the interpreter this is implemented by entering a C++
code section that contains a C++ try {} catch {} block, in which the calling
function is called again and continues right at the next instruction (or the
interpreter loop is recursively entered). An exception will throw us out of
that scope and back into the try {} catch {} wrapper, which can call again
into the calling function.
The IR guarantees that delete_exception_handler is always called, regardless of
how the try or catch blocks are terminated. That is where in the JIT and
interpreter we return from the nested function call and return back into the
original stack frame, effectively unregistering the catch handler.
Further cleanups with regards to the naming and the exception handler stack
will come in subsequent patches, this is merely the minimal patch set to
change to the new mechanism.
This patch set breaks ARM until ARM exception handler tables are implemented.
The interpreter changes are based on a patchset from Erik
from https://codereview.qt-project.org/#change,45750
Change-Id: I543f2bd37b2186f7e48ffcab177d57b5ce932a0c
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Fast lookups still require a function call, and will only work
for properties defined on the object itself. Properties of the
prototype will still be slow.
Change-Id: I07c601998d312b1bd8e9977708d3375bf72df3e3
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Don't use the export macro on internal debug classes.
Change-Id: Id2f8069cc8b6703a3fafd3058524d46252eb57f8
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Move the v4 tool into basedir/tools/v4
Small fix to sync.profile
Install v4 into QT_INSTALL_BINS
adjust test262.py to simply call 'v4' by default
Change-Id: If78f40632c226bc26f64b0eea06fe93d7770af3e
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Lars Knoll
Simon Hausmann
Erik Verbruggen
Erik Verbruggen