| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
| |
to the LGPL only.
To do this I ran replace-licenses.zsh $QTDIR/src/script release
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
|
|
|
|
| |
Reviewed-by: Jason McDonald <jason.mcdonald@nokia.com>
|
|
|
|
| |
Reviewed-by: Simon Hausmann
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
| |
No need to look up the global object via the scope chain since we have
a direct pointer to it already.
|
|
|
|
|
|
| |
In WebKit/JSC config.h needs to be included first in .cpp files, to among
other things make sure that min/max are not defined as macros through
windows.h.
|
|
|
|
|
|
|
|
| |
doesn't construct.
Removes code duplication.
This also indirrectly fixes the QMetaObjectWrapperObject where this was missing
|
|
|
|
|
|
|
|
|
|
| |
The original JavaScriptCore doesn't create stack frame or scope for
native function.
JSC has been patched to support that.
This commit revert our patches to JSC, and implement create the stack
frame from QScript
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
|
|
| |
b62ab93d001d2f3238e24faa133720cb877e3023 commit.
Workaround for multiple decorators problem. FunctionWrapper and
NativeConstrWrapper needs access to original result value (from native
function call). Solution was to move part of the NativeConstrWrapper's
functionality (functionExit debugger's event) to
FunctionWrapper::proxyConstruct.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-script (default) and -no-script.
This means we can get rid of the SCRIPT feature from qfeatures,
since it's now handled by the new configure variable.
It also allows us to get rid of all the QT_NO_SCRIPT ifdefs from
the source files, since qmake isn't going to include those files
for compilation when you configure with -no-script.
The QtScriptTools module will be disabled if the QtScript module
is not built. You'll have to build the old QtScript back-end
(will be made available in a separate package), then build the
QtScriptTools module yourself.
Reviewed-by: Simon Hausmann
|
| |
|
|
|
|
|
| |
We can infer it from the JSC environment when the function is
actually called.
|
| |
|
|
|
|
|
|
|
|
|
| |
- Create a scope (activation object) for the native constructor in QScriptClass
- put the isCalledasConstructor in the activation object (so i can
clean up the QScriptContext
- Remove the code duplication in all native functions.
Aknoweldged-by: Kent
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so native function that would call
engine->evaluate("var b = 'foo');
would not change the global object.
The change in qscriptengine.cpp makes sure that the correct scope is
used for the execution of QScriptEngine::evaluate.
The changes in qscriptfunction.cpp push a new scope for native function
calls. We might want to move that into QScriptContext later
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
|
|
|
| |
Install custom ClientData on JSGlobalData instance instead.
Also some cleanups to avoid globalObject et al being accessed
directly.
Killed the proxying scheme employed in setGlobalObject() since it
didn't work; if you stored the original Global Object and replaced
it with another object, then added properties to the new object,
they would show up in the old object, too (because the old object
would always proxy to whatever the current Global Object was).
|
|
|
|
|
| |
With commit 6985212c8909c89183b232ca28b96a2c8a2f1385,
context->thisObject() now returns the right thing.
|
|
|
|
| |
Do it The right way(TM), by lazily wrapping JSC::ExecState objects.
|
|
|
|
|
| |
Not everything passes but at least nothing asserts anymore, so
the test runs to completion.
|
|
|
|
| |
call(), construct() etc.
|
|
|