| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Use JavaScriptCore's conversion functions rather than our own
(incomplete) implementation.
Specifically, this means daylight saving time is finally
handled correctly on Windows.
Task-number: QTBUG-9770
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new internal JS object type,
QScriptStaticScopeObject, that enables the JS compiler to make
more aggressive optimizations of scoped property access.
QScriptStaticScopeObject registers all its properties in a
symbol table that the JS compiler has access to. If the compiler
finds the property in the symbol table, it will generate the
fast index-based op_{get,put}_scoped_var bytecodes, rather than
the dynamic (slow) op_resolve and friends.
If the compiler _doesn't_ find the property in the symbol table,
it infers that it's safe to skip the scope object when later
resolving the property, which will also improve performance
(see op_resolve_skip bytecode).
QScriptStaticScopeObject is only safe to use when all relevant
properties are known at JS compile time; that is, when a
function that has the static scope object in its scope chain is
compiled.
It's up to the user of the class (e.g. QtDeclarative) to ensure
that this constraint is not violated.
The API for constructing QScriptStaticScopeObject instances is
not public; it lives in QScriptDeclarativeClass for now, an
internal class exported for the purpose of QML. The instance is
returned as a QScriptValue and can be manipulated like any
other JS object (e.g. by QScriptValue::setProperty()).
The other part of this commit utilizes QScriptStaticScopeObject
in QtDeclarative in the two major places where it's currently
possible:
1) QML disallows adding properties to the Global Object.
Furthermore, it's not possible for QML IDs and properties to
"shadow" global variables. Hence, a QScriptStaticScopeObject
can be used to hold all the standard ECMA properties, and this
scope object can come _before_ the QML component in the scope
chain. This enables binding expressions and scripts to have
optimized (direct) access to e.g. Math.sin.
2) Imported scripts can have their properties (resulting from
variable declarations ("var" statements) and function
declarations) added to a static scope object. This enables
functions in the script to have optimized (direct) access to
the script's own properties, as well as to global properties
such as Math.
With this change, it's no longer possible to delete properties
of the Global Object, nor delete properties of an imported
script. It's a compromise we make in order to make the
optimization safe.
Task-number: QTBUG-8576
Reviewed-by: Aaron Kennedy
Reviewed-by: Olivier Goffart
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For arrays, the conversion would crash if the array was cyclic.
Introduce a set that keeps track of which objects are being
converted, and return an empty list when a cycle is detected.
For other types of objects, the object was previously attempted
to be converted to a primitive, which typically meant you would
get the string representation ("[object Object]"), since most
(practically all) objects can be converted to a string -- not
useful at all.
Change the conversion so it converts the object to a QVariantMap
instead. This was already done for slots that took a QVariantMap
as argument, but only one level deep. Make the conversion recursive,
using the same mechanism as for arrays to detect cycles.
This change also means that you get a meaningful
JS object => QVariant => JS object roundtrip.
It also aligns the behavior with the Qt WebKit bridge.
Update the documentation to describe the new behavior.
The 4.7 changelog will also be updated under "important behavioral
changes".
This change exposed an issue with one of the QML autotests: A JS
object was assigned to a QVariant property, which caused it to be
converted to a string (rather than a QVariantMap) -- just shows
that the previous behavior was unintuitive). Later, this variant
property is compared to another object, the intention being to
compare the _properties_ of the two objects; but because the variant
property contained a string, this would cause the other operand
(object) to be converted to a string as well ("[object Object]"),
causing a meaningless test pass.
Change the test to deserialize both objects using JSON.stringify,
and compare the resulting strings, so that actual
JS object => QVariant(Map) => JS object roundtrip is tested (the
intention).
Task-number: QTBUG-3511
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qsTr() uses QFileInfo::baseName() to determine the translation
context from a URL.
The problem is that creating a QFileInfo object (and thus a
file engine object), as well as processing the URL to determine
the base name part, is very expensive.
By caching the last translation URL and context, qsTr() becomes
5x faster.
Only the most recent URL is cached, because a script's text will
be translated all at once (as the script is evaluated), so for
scripts with multiple translated strings only the first qsTr()
call will cause a cache miss.
The performance could be improved even further by getting rid of
the QFileInfo dependency altogether; created QTBUG-9939 for that
since it's a more risky change.
Task-number: QTBUG-6908
Reviewed-by: Olivier Goffart
|
|
|
|
| |
Use a shim to take care of that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QScriptEngine::reportAdditionalMemoryCost(int).
This function provides the ability to give a hint to the engine
that it should perhaps trigger garbage collection sooner rather
than later.
For example, if you've implemented a JS ByteArray class that
wraps a QByteArray, and a user constructs a few hundred
temporary ByteArray objects of large sizes, failure to report
the additional memory cost may cause the application's memory
consumption to grow and grow (because the script engine thinks
they are "cheap" objects, the GC won't kick in).
Reporting the correct size can be difficult (or impossible) in
some cases. For example, it's difficult to predict the total
amount of system memory & resources consumed by a QImage.
But even reporting a heuristic / approximate cost can be better
than reporting no cost.
Task-number: QTBUG-6238
Reviewed-by: Simon Hausmann
|
|
|
|
|
|
|
|
| |
Make them mirror the defaults of the public API, so that the
QScriptValuePrivate property functions can be used internally in
the same manner as the public API.
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
| |
In preparation of being able to call toStringHandle()
directly on a JSC::Identifier in QScriptValueIterator
implementation.
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Update qscriptvalueiterator test to expect length property when
iterating arrays and strings.
- Use EvalExecutable::create() instead of EvalExecutable constructor.
The constructor is private.
- Reimplement getOwnPropertyDescriptor() in all custom script objects.
- Remove all reimplementations of getPropertyAttributes().
It doesn't exist in trunk anymore (getOwnPropertyDescriptor() is used
instead).
- Remove checkDontDelete argument from deleteProperty() reimplementations.
The purpose of this argument was to support deleting properties
with attribute Undeletable from C++. But it was quite an invasive
patch to JavaScriptCore, and it doesn't seem worth it. If this feature
is really crucial it should be re-done upstream.
One of the tests needed to be updated so it's not sensitive to the
C++ undeletability.
- Adapt getOwnPropertyNames() reimplementations to signature change.
- Add missing QScriptObject structure flags, otherwise we don't get all virtual calls.
- Remove our patch for reporting column numbers in the debugger callbacks.
It was just too intrusive. As with the checkDontDelete issue, this should
be redone upstream if it's really important. In 4.7, QScriptEngineAgent
will always report a column number of 1.
Other compilation fixes:
- InternalFunction::name() takes an ExecState* argument, not GlobalData*
- ScopeChain::globalObject is no longer a function but a member variable
- ScopeChainNode constructor takes a GlobalObject argument
- Heap::collect() is called collectAllGarbage()
- JSValue::strictEqual() takes an ExecState* argument
- Debugger::exception() takes a bool hasHandler argument
- Debugger no longer reports column number (we decided to drop that patch from JSC)
- UString doesn't have operator+=(char*)
- Update the autotests to reflect the columnNumber=1 change.
- Add helper class to avoid crashing inside JSC.
Ever since r52856 in WebKit trunk, this is needed. There are probably a lot of
other public API functions that need this guard as well, but I'll add them as they
are discovered.
- Update mkdist-javascriptcore tag, exclude a few more files.
- Set ENABLE_JSC_MULTIPLE_THREADS=0 define on Mac due to r52355 in trunk.
Reviewed-by: Simon Hausmann
|
|
|
|
|
|
|
|
|
| |
This conversion needs to be as fast as possible since
it's performed every time you access a QObject property
from QtScript. Hence, we should avoid going via QString
and instead do the conversion ourselves.
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
| |
Use JSC::UString internally. Only when the public API demands it
should a JSC::UString be converted to a QString.
Reviewed-by: Jedrzej Nowacki
|
|\
| |
| |
| |
| |
| | |
Conflicts:
qmake/generators/symbian/initprojectdeploy_symbian.cpp
qmake/generators/symbian/symmake_abld.h
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid the engine's list of free script values from growing
without bounds.
When a QScriptValue is initially not bound, its private will
be allocated from the normal heap (and not from the engine's
pool of privates, because there is no engine at this point).
But when a value is later bound (e.g. by setting it as a
property of an object, or by passing it as argument to
QScriptValue::call()) and is subsequently destroyed, its
private will be handed to the engine, which will add it to
its free-list (hence the memory is not freed). This
allocation/deallocation asymmetry causes this list go keep
growing.
The solution is to limit the size of the free-list, and free
the memory of the private immediately when the list has
reached a certain size.
Task-number: QTBUG-8400
Reviewed-by: Olivier Goffart
|
| |
| |
| |
| |
| |
| |
| |
| | |
QScriptValue::isQMetaObject shouldn't crash for a value that internally
is represented as a non JSObjects values.
Additional check was added to QScriptEnginePrivate::isQMetaObject.
Reviewed-by: Kent Hansen
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"e:\pulse\work\91088\src\script\api\qscriptengine.h(360) :
fatal error C1001: An internal error has occurred in the compiler.
(compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x510A0530:0x00000007]', line 243)
To work around this problem, try simplifying or changing the program near the locations listed above."
Apparently the compiler doesn't like that a few functions are inlined.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There's no reason to construct QScriptValues when JSC::JSValues
can be operated on directly. A benchmark showed that ~10% of the
time for reading a QObject property from a script was spent just
creating and destroying QScriptValue temporaries. It's time to
finally get rid of this potential bottleneck, not just in the
QObject integration but everywhere.
This change refactors the code so that all internal operations
are performed on JSC::JSValue (most importantly, conversion
from/to Qt types), and the public API functions are just thin
wrappers around these. E.g. instead of doing
enginePrivate->scriptValueFromJSCValue(jsValue).toQObject()
the implementation now does
QScriptEnginePrivate::toQObject(jsValue)
Other operations are delegated to the engine implementation
in similar style.
Task-number: QTBUG-8304
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| | |
More preparation for operating purely on JSC::JSValue internally.
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| | |
In preparation of operating purely on JSC::JSValue internally.
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| | |
In preparation of doing this conversion in more places.
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| |
| |
| | |
In preparation of getting rid of QScriptValue construction internally;
the implementation should only call the private functions that operate
directly on JSC::JSValues.
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| |
| | |
Also rename ToUint{16,32} to ToUInt{16,32} to follow the Qt
naming (it takes precedence over the ECMA one).
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| |
| | |
These are not dependent on QObject, I don't know how they ended
up inside there.
Reviewed-by: Jedrzej Nowacki
|
|/
|
|
|
|
| |
Because that's where they belong.
Reviewed-by: Jedrzej Nowacki
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
QScriptDeclarativeClass is a private, but exported, class used by the
declarativeui module. It is very similar to QScriptClass, but slightly
faster and provides a couple of "backdoor" extension mechanisms used
by declarative.
Reviewed-by: Warwick Allison
|
|
|
|
|
|
|
|
|
|
|
| |
QScriptProgram encapsulates a Qt Script program (AKA a script).
It retains the compiled representation of the script, so that
repeated evaluation of the same script becomes faster.
An overload of QScriptEngine::evaluate() that takes a QScriptProgram
has been added.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
| |
Makes QScriptValue::toNumber() ~50% faster.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
|
| |
Also avoid looking up the object's own properties twice
(before we called getOwnPropertySlot() and then getPropertySlot()
on the same object).
Makes QScriptValue::property() ~20% faster when calling it on an "empty" object.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
| |
Makes QScriptContext::engine() 80% faster.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
| |
Makes QScriptContext::parentContext() 50% faster.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
| |
Makes QScriptEngine::currentContext() 25% faster.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
| |
The idea is that qsreal can be typedef'ed to float on platforms where it's
appropriate. Since the QScriptValue ctor takes a qsreal, we should not
convert it to a double internally.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
|
|
|
| |
The QScriptEngine::hasUncaughtException() flag should be set to true if
returning from a JS function was caused by an exception. According to
documentation, the flag had to be accessible from the
QScriptEngineAgent::functionExit event.
New autotest was added.
Reviewed-by: Kent Hansen
|
|
|
|
| |
Make allocation faster.
|
|
|
|
|
|
|
|
| |
Introduced a helper function in our custom source provider,
columnNumberFromOffset(), that maps an absolute offset in the source
input to a relative column number.
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
|
|
| |
I was assuming that the default return value register was always set
to 0 for native calls. But this is not the case. So we must ensure this.
Also be consistend in the way the stackframe grow and shrink. This expose
another bug in the way the call frame is created in JSC
Reviewed-by: Kent Hansen
|
|
|
|
| |
Reviewed-by: Simon Hausmann
|
|
|
|
|
|
|
| |
The currentFrame pointer is used e.g. by QScriptValue::toString(). It needs to
be in sync, otherwise we will crash.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
| |
Avoid copy and paste.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Get rid of QPointer.
Use linked list of privates (like was recently done for QScriptValue).
Allocate the private on the stack when we can.
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
| |
Do not convert JSC::Identifier to QString to convert it later to
JSC::Identivier again
Reviewed-by: Kent Hansen
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Make it faster.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Reviewed-by: Trust Me
|