| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
It's faster than calling getObject(), since getObject() will do
type checking of the value.
|
|
|
|
| |
Make allocation faster.
|
|
|
|
|
|
| |
It's better that this works rather than asserts.
Reviewed-by: Olivier Goffart
|
|
|
|
| |
Reviewed-by: Simon Hausmann
|
|
|
|
|
|
|
|
| |
When the script class is set to 0, we need to remove the script
object's delegate entirely, because the delegate requires a non-0
script class in order to be useful.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
| |
strictlyEquals has to continue to work if one of the values has an engine
and the other one doesn't. Use the other value's engine to construct a
JSValue if possible and use JSC::JSValue::strictEqual.
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
| |
Don't create JSC types as the conversion back to a string now
requires an ExecState.
Reviewed-by: Kent Hansen
|
|
|
|
|
|
| |
The functions are identical, but in recent WebKit trunk isObject()
doesn't exist anymore. So this renaming is done to prepare for the
import of a more recent JavaScriptCore.
|
|
|
|
|
|
|
|
| |
Winscw gets very confused when the name of an enum value is the same as
the name of an entire namespace, JSC in this case. Renaming the enum
value to JavaScriptCore fixes this.
Rubber-stamped-by: Kent
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Needed due to commit 3636e666528b72de79f8c7012690bb9e279f0863
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
belonged to a deleted script engine
When the engine is deleted, the JSValue is invalidated, but the
QScriptValue's type will still be QScriptValuePrivate::JSC.
Use a new helper function, isObject(), that checks both that the
value is of type JSC _and_ that it is valid, before calling
JSValue::isObject() (JSValue::isObject() assumes that the value
is valid).
|
|
|
|
|
|
|
| |
Calling QScriptEngine::toStringHandle() is dead slow, so don't call it;
use JSC::Identifier directly.
This is the same issue as was fixed for setProperty() in commit
a8574172dd5e6bc11cf6f69b6fad5a063549e88d.
|
|
|
|
|
| |
Calling QScriptEngine::toStringHandle() is dead slow, so don't call
it; use JSC::Identifier() directly instead.
|
|
|
|
|
| |
Avoid having to create a dummy QScriptValue (which will have its
d_ptr set to 0).
|
|
|
|
| |
Make it faster.
|
| |
|
|
|
|
| |
Just a little cleanup.
|
|
|
|
|
|
|
|
|
| |
Avoid calling malloc() and free() so often. The premise is that
QScriptValue is usually a short-lived type, and only a few QScriptValues
exist at a time, so if we cache privates in the engine, QScriptValues
will be much faster to create and destroy.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
| |
Avoid calling virtual function JSC::JSValue::get{Call,Construct}Data()
twice.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
| |
It's faster.
Reviewed-by: Olivier Goffart
|
|
|
|
| |
It is uneeded and add useless overhead
|
|
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
It's faster.
|
|
|
|
| |
Get rid of the hash.
|
|
|
|
|
| |
It's the d-pointer that we most frequently want to access, so store it
to avoid having to use QScriptEnginePrivate::get() all over the place.
|
| |
|
|
|
|
|
|
|
| |
QScriptValue id were made persistent. It depands
on JSC:JSValue JSCell pointer not on QScriptValuePrivate attr.
Reviewed-by: Kent Hansen
|
|
|
|
|
|
| |
There is no point in setting class member in destructor
Reviewed-by: Kent Hansen
|
|
|
|
|
|
| |
Static method QScriptValue::initFromJSCValue was removed.
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
|
| |
Internal API of QScriptValue were cleaned. toPublic() was
removed and replaced by standard static Private::get().
All initFromXXX() methods were replaced by overload call
of initFrom().
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
| |
Get rid of conversion functions QScript::qtStringFromJSCUString and
QScript::qtStringToJSCUString. Code was moved to cast operators.
Reviewed-by: Kent Hansen
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
We can store flags on the ReturnValueRegister entry in the stackframe
header (as native function don't use that)
Then when requesting an activation object we can lookup the flags to
know if we should create it.
This reduce a lot the cost of a native call.
Reviewed-by: Kent Hansen
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
JSObject::getPropertyAttributes() does not follow the prototype
chain, so we have to do it.
|
|
|
|
|
| |
Look in the __qt_scope__ property that is set by
QScriptValue::setScope().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
|
|
|
|
|
| |
Those functions are internal and we don't want to support them
in the JSC back-end, because they expose too much implementation
detail of the old back-end.
|
| |
|
|
|
|
|
|
|
| |
QScriptValue::toObject() call QScriptEngine::toObject() so the code is
not duplicated.
Reviewed-by: Kent Hansen
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
JSC doesn't provide a way of un-defining a getter/setter. If
deleting e.g. only the setter, we remember the getter, delete
the property, then re-establish the getter.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JSC requires that the global object is actually a
JSGlobalObject instance, whereas QScriptEngine::setGlobalObject()
allows any object to be set as the global object. The way we
solve this is by proxying from an internal global object to the
custom (user-set) object.
We need to take care that the internal global object is never
actually exposed through our API; a brilliantly named helper
function, toUsableValue(), makes that happen.
Evaluating "var a = 10" with a custom global object doesn't work
yet; the variable always ends up in the internal Global Object.
For variable assignments, JSC appears to bypass the normal
JSObject::put() and instead use
JSGlobalObject::copyGlobals{From,To}(), which means I can't
intercept and proxy the assignments.
This commit enough to get the Context2D example working. There's
another bug with iteration of the built-in Global Object's
properties (non-enumerable properties are always skipped by the
JSC C++ API, whereas with QScriptValueIterator they should not
be), but that's a totally separate issue.
|