| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ \
| | |
| | |
| | |
| | | |
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.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.exe
mkspecs/common/symbian/symbian.conf
src/gui/graphicsview/qgraphicswidget.h
src/gui/kernel/qapplication.cpp
src/gui/text/qtextlayout.cpp
src/openvg/qpixmapdata_vg.cpp
src/s60installs/s60installs.pro
tools/runonphone/main.cpp
tools/runonphone/serenum_unix.cpp
qtextlayout.cpp fixed up together with Eskil.
Kept the configure.exe from 4.7 without recompile.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Regression against the old back-end. Don't set the translator
properties on the original global object but rather on the
active one (except for String.prototype.arg, which should
always be added to the original String constructor to match
4.5 behavior).
Task-number: QTBUG-6437
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| | |
Need shims wherever a JSC::Identifier can be created/destroyed.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
Fixes test tst_QScriptValue::equals(engine->newVariant(QVariant(123)) <=> engine->newArray(10))
Reviewed-by: Jedrzej Nowacki
|
| |
| |
| |
| |
| |
| |
| | |
now that QVariant is known to QMetaType, we can test for the metatype id
instead of doing string comparison
Reviewed-by: Kent Hansen
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| | |
Turn off optimizations in qscriptengine.cpp.
I tried to turn it off/on for a selective few functions,
but without success.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"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 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
|
|/
|
|
|
|
|
|
| |
All the public QScriptEngine::create() function does is call the
private implementation anyway, so call QScriptEnginePrivate::create()
directly.
Reviewed-by: Jedrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
| |
Use the base of the file name as the translation context. (This was
the original behavior before the switch to JSC.)
Reviewed-by: Kent Hansen
|
|
|
|
|
|
|
|
|
|
| |
This reinstates the pre-4.6 behavior: A script-owned C++ object
that's not referenced anymore should be garbage collected, even
if it has connections. In order to achieve this, the "weak"
reference to the C++ object's wrapper must be invalidated.
Task-number: QTBUG-6366
Reviewed-by: Simon Hausmann
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is required due to the switch to the JavaScriptCore-based
back-end.
Instead of segfaulting somewhere inside JSC::initializeThreading(),
call qFatal() when this constraint has been violated.
Reviewed-by: Simon Hausmann
|