| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 147df10403ba280b3f04c1e3d6c4b1cf386abe5d did not quite
fix the issue; other places need the same checks.
When the JIT is enabled, frames for built-in JS host calls
(such as Array.prototype.forEach) are not fully initialized.
In particular, the CodeBlock register of such frames is not
set (see comment in JITCall.cpp).
We need to check if the codeBlock is actually valid before we
start using it.
This fixes the crash(es) but not the problem of actually getting
the arguments for such frames through the API. There's also a
related problem when a QtScript function (newFunction()) is called
as a callback of a built-in JS host function (QTBUG-17287).
These problems will go away once JavaScriptCore is updated to a
more recent version (4.8 at the earliest), since the
native-vs-script frame handling has been unified.
Task-number: QTBUG-17137
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
|
|
|
| |
When the JIT is enabled, NativeFunctionWrapper (used for
built-in functions such as Array.prototype.forEach) inherits
JSFunction, so we must check whether the function is
actually a JS (script) function before we start accessing
script-specific properties.
Task-number: QTBUG-17137
Reviewed-by: Olivier Goffart
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the engine is destroyed before the program, the program
must be invalidated; otherwise the program destructor will
access a stale engine pointer, which can cause a crash
(it crashes on Symbian, but "only" gives a Valgrind warning
on Linux for our autotests).
We need to keep track of all associated programs, just like
we already do for values and strings. This fix follows the
exact same pattern, but uses a QSet to keep the patch minimal.
No new tests, but the evaluateProgram() test runs successfully
on Symbian now, and there are no more Valgrind warnings.
Task-number: QTBUG-16987
Reviewed-by: Olivier Goffart
|
|
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Yet another missing API shim.
When converting the QScriptValue to JSC, a JSCell may be allocated,
which can cause the GC to trigger.
If an identifier (JSC::Identifier) is then garbage collected, the
destructor will try to remove itself from the currentIdentifierTable().
Because the API shim was missing, the identifier table was 0.
It's difficult to create a bulletproof test for this case, but the
attached test is a best effort (it crashes on my machine without the
fix).
Task-number: QTBUG-15144
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an exception occurs, we should ignore the result of
JSC::construct() and return the exception value, even if
the exception is not an object.
This makes the behavior match the documentation: "Calling
construct() can cause an exception to occur in the script
engine; in that case, construct() returns the value that
was thrown".
Task-number: QTBUG-14801
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
| |
This patch reduce time in which QScriptEngine would abort an script
executing multiple long-running native functions.
Task-number: QTBUG-9433
Reviewed-by: Olivier Goffart
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
The class has been there since 4.6 (http://labs.trolltech.com/blogs/2009/11/23/qtscript-in-46/),
but we don't see a reason to hide it any longer.
Task-number: QTBUG-13229
Reviewed-by: Olivier Goffart
|
|/
|
|
|
| |
Tasks: QTBUG-13271, QTBUG-13212, QTBUG-12321
Reviewer: David Boddie
|
|
|
|
|
|
|
|
|
| |
QScriptEngine::installTranslatorFunctions() now installs
wrapper functions for qsTrId and QT_TRID_NOOP (similar to
the existing ones for tr() and translate()).
Task-number: QTBUG-8454
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
| |
Reviewer: David Boddie
Task number: QTBUG-11938
|
|
|
|
|
|
| |
They are useless and cause warnings in the code.
Reviewed-by: Kent Hansen
|
|
|
|
| |
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recompile all the function is necessary to ger the debug opcode that
notifies us when the position changes.
The change in CollectorHeapIterator.h is nessesary to get it work as
Debugger::recompileAllJSFunctions uses LiveObjectIterator,
LiveObjectIterator initialied m_cell to -1 and to ++(*this) in its
constructor. But as m_cell is of type size_t (unsigned) then the
< comparison will always fail as it is an unsigned comparison.
This was already fixed upstream in r54672
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
| |
JSC::JSValue::asCell asserts if it is not a cell
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
| |
exceptionThrow
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
| |
There were still a couple of functions that didn't have them. This
could cause said functions to crash if multiple script engines were
being used.
Reviewed-by: Jedrzej Nowacki
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Some functions were marked with Q_DECL_IMPORT where they should just be
Q_CORE_EXPORT. The reason is that this macro is expanded to nothing in
case of static builds whereas Q_DECL_IMPORT isn't (it is a dllimport).
That leads the linker to try to import it and it shouldn't.
Task-number: QTBUG-10791
Reviewed-by: gabi
|
|
|
|
|
|
|
|
|
|
|
| |
native context
One shouldn't have to call activationObject() or scopeChain() before
calling popScope(); the scope chain should always have 2 items (activation
and global object) before we start popping anything from the internal chain.
Task-number: QTBUG-11020
Reviewed-by: Olivier Goffart
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when possible
JSC::NativeFunctionWrapper is a typedef to either JSC::PrototypeFunction or
JSC::JSFunction depending if we are running JIT or not.
When using JIT, JSC::JSFunction is faster, as it allow JIT to do the native
call dirrectly. The difference is that in that case, the JS stack is not
fully set up so we have to be carefull.
Unfortunately, it is not possible to make FunctionWrapper inherit from
JSC::NativeFunctionWrapper, because JSFunction is slightly bigger, and we
cannot fit in a Cell
Reviewed-by: Kent Hansen
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4.7-integration
* '4.7' of scm.dev.nokia.troll.no:qt/oslo-staging-1: (71 commits)
Autotest: increase wait time to 3s on Windows to bypass 2s-granularity limitation
Autotest: update to the new values for the locale
do not expand variables in read()'s file name
remove ability to use break() a block outside any loop
don't add -unix to the qmake command line
Increase the timeout for the QNAM getter test to 30 seconds
Remove unstable hosts from the list
qdoc: Output TOC for more class ref pages.
Other fixes to the remote network stresstester
Fix SSL connection problem.
Make sure we don't try URLs that aren't HTTP or HTTPS
Fix menu bar visibility.
Add SSL remote host tests
Split the remote and the local tests in two, in preparation for SSL tests
Add tests for remote hosts
Change the way we calculate the average transfer rates.
Finish renaming
Move these tests to tests/manual.
Add a QNetworkAccessManager stresstest
Add a non-blocking native function too
...
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/3rdparty/webkit/VERSION
src/3rdparty/webkit/WebCore/ChangeLog
src/3rdparty/webkit/WebCore/page/FrameView.cpp
src/3rdparty/webkit/WebCore/rendering/RenderWidget.cpp
src/3rdparty/webkit/WebKit/qt/symbian/eabi/QtWebKitu.def
src/s60installs/bwins/QtCoreu.def
src/s60installs/bwins/QtGuiu.def
src/s60installs/bwins/QtNetworku.def
src/s60installs/eabi/QtGuiu.def
tests/auto/qscriptextqobject/tst_qscriptextqobject.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
RVCT 4 is far more strict with regards to symbol visiblity that RVCT
2.2, and will hide symbols unless all references have default visibility
in the object files. Update the various places in Qt code where the
symbol visibility was set incorrectly for DLL-based platforms (those that
use __declspec(dllimport) and (dllexport).
Note: QtWebkit and other Qt modules are fixed in different commits.
Task-number: QTBUG-9903
Reviewed-by: Jason Barron
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the JIT is enabled, as well as JIT_OPTIMIZE_NATIVE_CALL defined,
NativeFunctionWrapper is a typedef for JSFunction. This has the
consequence that the native call frame will not be fully initialized
by JIT-generated code (because it shouldn't have to); in particular,
ExecState::codeBlock() is not set up.
qsTr() relies on codeBlock() to return a sensible value, though, so
it breaks this contract.
By making qsTr a PrototypeFunction, the JIT will detect that the
function call needs more elaborate setup, i.e. initialize codeBlock()
as well.
Reviewed-by: Olivier Goffart
|
| |
| |
| |
| | |
And fix two silly typos in the error messages.
|
|\ \
| |/
| |
| |
| | |
Conflicts:
src/script/api/qscriptengine.cpp
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Search up the call stack to find the first non-empty source URL.
Also and add an autotest for the QtScript translator functions
since there was none (their presence was checked, but not their
behavior...).
Task-number: QTBUG-9775
Reviewed-by: Olivier Goffart
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In 4.5, changing the prototype of the (custom) global object used
to "Just Work"(tm).
In the JSC-based back-end, the built-in global object acts as a
proxy if a custom global object is set, because JSC doesn't (yet,
anyway) provide a way to replace the global object.
To complicate this further, we also have a proxy to the original
global object (that bypasses the custom global object proxying (!)).
This is so that properties of the original global object can
still be accessed with the QtScript C++ API when a custom global
object has been set.
Unfortunately, JSObject::prototype()/setPrototype() are not virtual,
meaning that a change of prototype in the source object is not
reflected in the proxy or vice versa.
Work around this for now by syncing the prototype at the appropriate
places (QScriptEngine::setGlobalObject(), QScriptValue::setPrototype()).
This fixes all except the case when a prototype is set from JS,
since such a write doesn't go through our public C++ API. But this
case can be detected and handled by the global object's
JSObject::put() reimplementation. Created a separate report for that
issue: QTBUG-9737.
Task-number: QTBUG-7066
Reviewed-by: Jedrzej Nowacki
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
APIShim needs to be named, otherwise it is just a temporary and
the destructor is called too early
|
| |
| |
| |
| |
| |
| |
| | |
Added by both 7a11acd536d84ad22ef98a0fdbdb4322a55efafb and
3e5745ea75d73869918889cb374c3d651bed0991 in different branches.
in ~QScriptValueIterator and ~QScriptValueIteratorPrivate
Only one is required.
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
src/gui/text/qstatictext.cpp
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- for QScriptEngine and QScriptContext; we don't control what the
JSC functions are doing, so it's better to have shims than not to
have them (which can cause something to blow up), even if they
might not be strictly necessary as of this writing.
- for QScriptDeclarativeClass; otherwise the identifiers might
be created/destroyed in the wrong engine.
- for QScriptValueIterator destructor; otherwise the identifiers
might be destroyed in the wrong engine.
This is an attempt to fix a crash in Bauhaus, but it might still
be crashing (i.e. still some shims missing, somewhere) ;(
|
| | |
| | |
| | |
| | | |
Use a shim to take care of that.
|
| | |
| | |
| | |
| | | |
Fixes crash in tst_QScriptValueIterator::remove on windows
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QScriptEngines
the currentIdentifierTable table, which is a static thread local variable, could be corrupted.
The main change is to fix the QScriptEngine constructor not to alter the currentIdentifierTable
This showed a lot of cases where APIShim guards where missings.
The problem was seen with creator, related to QTBUG-9426
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes it possible to have a prototype object in place that
handles all slot calls, rather than having the slots be recreated
in each wrapper object.
Task-number: QTBUG-3637
Reviewed-by: Simon Hausmann
|
| |
| |
| |
| |
| |
| | |
Their absence was causing Bauhaus to crash.
Reviewed-by: Simon Hausmann
|