aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/qml/qqmlcompiler_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Fix broken Maroon game / regression in PropertyChanges {} elementSimon Hausmann2013-12-101-4/+5
| | | | | | | | | | | | | | | | | | | | | | Commit 0aadcf8077840068eb182269e9ed9c31ad12f45e that pre-compiles the expressions in PropertyChanges {} introduced a regression in where the evaluation context was incorrect and thus bindings would not be able to access the correct properties. For example PropertyChanges { target: someObject y: height / 2 } Here height should be looked up in the context of "someObject", not of the PropertyChanges element. This patch introduces an auto-test that verifies that the lookup context is correct and fixes the bug by disabling accelerated compile time property lookups for binding expressions that are requested from a custom parser. Change-Id: I5cb607d07211b453ddfc9928ccbf5f9ecec85575 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Fix dynamic properties in QQmlPropertyMap not always being visible in QMLSimon Hausmann2013-12-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | QQmlPropertyMap is a fully dynamic class that can add properties at any point in time. In order for these properties to be visible inside QML, we must disable the property cache (instead of trying to unsuccessfully re-fresh it). What happened in this particular case is that the QQmlPropertyMap derived type was instantiated and the VME instruction for creating it would also assign the property cache the compiler determined. There's no way for QQmlPropertyMap itself to access this property cache instance (stored in output->types[id].typePropertyCache) or invalidate it, so instead don't use the compiler's property cache when instantiating the type. This patch also disallows the adding properties to QQmlPropertyMap when it is used as base type for a new QML type, as we cannot provide the derived type to the QQmlPropertyMap constructor - this is only possible in C++. Task-number: QTBUG-35233 Change-Id: I7fa9e4a2224ccfdd7ccb3fd9f73919ecd46058a8 Reviewed-by: Alberto Mardegan <mardy@users.sourceforge.net> Reviewed-by: Alan Alpert (Personal) <416365416c@gmail.com> Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Add support pre-compiled bindings for QML custom parsersSimon Hausmann2013-11-291-2/+3
| | | | | | | | | | | | | | | | | | | | | | For example the x property in PropertyChanges { target: foo x: someItem.x - other.width / 2 } was compiled at run-time dynamically, which produces slower code (no type information available) and slows down the type instantiation, because the compilation happens every time at instantiation time (or later). With this change, when the custom parser behind PropertyChanges requests a binding ID for "x", the right hand side will be added to the bindings to compile, then compiled and later at run-time the QQmlBinding constructor that takes a QQmlBinding::Identifier can retrieve the correct compiled function from the QV4::CompiledData::CompilationUnit. Change-Id: I857fb2d39e82714b225bc9394b9904b795c6662b Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Fix warnings: initialize Instruction variables created on the stackThiago Macieira2013-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC 4.7-4.9 are right that the "code" member is used uninitialized. In fact, GCC 4.9 was quite assertive about it: qqmlinstruction_p.h:538:102: error: ‘def.QQmlInstructionData<8>::<anonymous>.QQmlInstruction::instr_common::code’ is used uninitialized in this function [-Werror=uninitialized] static void setData(QQmlInstruction &instr, const DataType &v) { memcpy(&instr.FMT, &v, Size); } \ ^ (It says "is used uninitialized" for this particular case; the "may be used uninitialized" appears in other places) The analysis is as follows: - variable declared on qqmlcompiler.cpp:1467: Instruction::SetDefault def; - type is POD, so no initialization is performed (def contains garbage) - on qqmlcompiler.cpp:1468 we use the variable: output->addInstruction(def); - QQmlCompiledData::addInstruction is inlined and does: QQmlInstructionMeta<Instr>::setData(genericInstr, data); - which is the call above, doing a memcpy with a source (&v) equal to the uninitialized "def" variable - result: memcpy is copying uninitialized bytes Valgrind doesn't report this because it doesn't care about copying uninitialized data. It will only complain if a decision is made based on it, which we don't since the first thing we do after the memcpy is initialize the member. The solution is simple to not copy the common part of the instructions. This way, we save 8 bytes of unnecessary copying and we still keep the warning if a member of an extended instruction isn't set. Change-Id: I940b40ea9aa61c7386e5cced4a7865be7bfddb5d Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Fix memory corruption in QML expression compilationSimon Hausmann2013-11-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We store QQmlPropertyData pointers in our IR for Qt meta-object property resolution at compile time. As it turns out however, it is possible that these pointers change after retrieval from the QQmlPropertyCache, as the cache may change later in the compilation process. Therefore we must do what also QQmlCompiler does by storing a copy of the QQmlPropertyData. For the JS IR we can do that conveniently through the IR memory pool. A side-effect of this bug was that QQmlPropertyData pointers were re-used and so the identity check in the isel later such as _function->contextObjectDependencies.contains(m->property) for dependency tracking failed. In the example given in the bug report it was determined that the window.contentWidth property wouldn't need a property capture, and therefore the binding was not re-evaluated as window.contentWidth later in the binding evaluation phase received its correct value. This patch also fixes the incorrect debug output names assigned to JS binding expressions, where the index used to look up the name is per compiled object, not per QML component. Task-number: QTBUG-35063 Change-Id: I3e5bbfaac11e5c122a2ed15a3e486a93988e1b6e Reviewed-by: J-P Nurmi <jpnurmi@digia.com> Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Initial support for resolving meta-property access for the scope and context ↵Simon Hausmann2013-10-311-3/+8
| | | | | | | | | | | | | | | | | objects at QML compile time This avoids having to do a string lookup for ids and in the import cache at run-time, before we can do a string hash lookup in the property cache. Instead we resolve final properties in the context and scope object at compile time and look them up at run-time using their index instead. The dependencies to these properties are also tracked separately and recorded in the compiled data. This is merely the initial patch. There's a lot left to do, such as having specialized getter and setters for specific property types. Setters are missing altogether right now and will fall back to name lookup. Change-Id: If3cb4e7c9454ef4850a615f0935b311c9395b165 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Qml JavaScript code generation cleanupsSimon Hausmann2013-10-201-15/+11
| | | | | | | | | | | | | | | * Run the binding expressions, functions and signal handlers through the V4 codegen _per_ component, and run the isel at the end for the entire file. We need to do per-component codegen because we want to set up the correct id and object scopes, which are different for the root component and anonymous components. * Changed V4IR::Module to allow for the concept of "qml modules" where there is no root function defined. This is a logical consequence of running v4 codegen multiple times with different input but the same V4IR::Module. Change-Id: Ib3a719f83507cbab7c2e4e145ccad5b663c795cf Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Compile signal handler expressions in the loader threadSimon Hausmann2013-10-111-0/+6
| | | | | | | | | Handle them similar to function declarations, except that we need to synthesize the expression into a function declaration that includes the signal parameter names. This is done quite similar to the code path in the new compiler. Change-Id: I751081f7f1052692da6e2ed60c7f5c017372d829 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Compile JS functions as part of the QQmlCompiler run in the loader threadSimon Hausmann2013-10-111-0/+7
| | | | | | | | ...instead of extracting the function body as a string and compiling it in the GUI thread. Change-Id: I3c3108f6e35464b5581a2d8b5799e7285858ce4d Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Compile binding expressions in the QQmlCompilerSimon Hausmann2013-10-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | This is done by re-using the JS code generator from the new compiler. A few bugs were fixed on the way: * The index into the compiledData->runtimeFunctions array is not the same as the function index when they are collected (from the AST), as for example binding expressions may create extra V4IR::Function objects that break the 1:1 mapping. Therefore the JS code gen will return a mapping from incoming function index to V4IR::Module::Function (and thus runtimeFunction) * Binding expressions in the old backend get usually unpacked from their ExpressionStatement node. The reference to that node is lost, and instead of trying to preserve it, we simply synthesize it again. This won't be necessary anymore with the new compiler in the future. * Commit 1c29d63d6045cf9d58cbc0f850de8fa50bf75d09 ensured to always look up locals by name, and so we have to do the same when initializing the closures of nested functions inside binding expressions (in qv4codegen.cpp) * Had to change the Qml debugger service auto-test, which does toString() on a function that is now compiled. Even if we implemented FunctionPrototype::toString() to do what v8 does by extracting the string from the file, it wouldn't help in this test, because it feeds the input from a string instead of a file. * In tst_parserstress we now end up compiling all JS code, which previously was only parsed. This triggers some bugs in the SSA handling. Those tests are skipped and tracked in QTBUG-34047 Change-Id: I44df51085510da0fd3d99eb5f1c7d4d17bcffdcf Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Fix error messages when assigning to non-existent properties in new compilerSimon Hausmann2013-09-301-1/+7
| | | | | | | | | Introduce a simple valdator pass early on to catch those assignments. Also fix storing the correct line/col for default property object bindings and remember the minor/major version of an import in the final type reference. Change-Id: Ib2a93dfe1a30fcd9c09b5443fb8199ad11b19769 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Fix composite type registration in the new compilerSimon Hausmann2013-09-301-0/+1
| | | | | | | | | | | | | | | When setting a property of a composite type like this property MyType foo: MyType {} and MyType.qml defines the new type, we test for assignability of MyType to the property foo. This test happens before MyType is instantiated and it relies on the meta-type in the CompiledData being set. Therefore this patch makes sure that the meta-type and the list meta-type are set accordingly at type compilation time, not instantiation time, similar to how it's done in the VME. Change-Id: Id7231e0a0113fa63ba6508bfbb1565dd554c5e56 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Initial support for componentsSimon Hausmann2013-09-201-2/+5
| | | | | | | | | We use a dedicated pass through the objects in QV4::CompiledData::QmlUnit to determine which objects are QQmlComponents. We remember their object indices as well as to which component other objects belong to (if any). Change-Id: I97929c57e2ccb2fd380d612002d128359c4bc253 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Add support for id propertiesSimon Hausmann2013-09-201-0/+2
| | | | | Change-Id: Idb4a0ad06f6cbe5d040da075a8f43d067a27ebc4 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Implement proper type resolutionSimon Hausmann2013-09-131-0/+5
| | | | | | | | | Collect all references to unknown types after parsing, re-use the existing code in QQmlTypeLoader to resolve them and finally use the resolved references map in the QQmlObjectCreator instead of the type name cache directly. Change-Id: I8b83af4f8852e79c33985457081c024358bb9622 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Beginning of a new qml parserSimon Hausmann2013-09-081-0/+12
| | | | | | | | | | | | | | The goal is to parse QML and JavaScript binding expressions/functions in one go and generate data structures that allow for the parsing to happen in a thread and the instantiation of the object tree in another thread, just reading from the generated data structures. This will replace qqmlcompiler and the VME. This new way of loading QML is currently hidden behind the QML_NEW_COMPILER=1 environment variable. There's lots of work left to fill in the gaps in object construction, Component support, Component.onComplete, error messages, etc. etc. Change-Id: I5e40643cff169f469f0b6ce151584ffee5ca5e90 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Get rid of the signal expression rewriterSimon Hausmann2013-07-031-1/+0
| | | | | | | | | | | | | This replaces the entire rewriter with more or less: expressionToEval = "(function(<named params here>) { " + expr + " } )" This also fixes crashes at run-time when the signal rewriter was executed from the loader thread and tried to use a v4 identifier hash with the same engine that's also in the main thread. Change-Id: Ib1e4927d330706a593411fbff64ed3da1e23d0e0 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Replace us of v4 identifiers for object id mapping in qml compilerSimon Hausmann2013-07-021-1/+1
| | | | | | | | | | | | The compiler is executed in a separate thread, at which point it doesn't work very well to access the identifiers data structures of the engine on the main thread, allocate new strings and potentially also trigger GC. This patch moves the data into an intermediate QVector and constructs the identifier hash on the receiving end in QQmlContextData::setIdPropertyData. Change-Id: I676cf633cf1c55ee2e8f818e6963368ad55913cd Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Convert IdentifierHash to be template basedLars Knoll2013-06-281-1/+1
| | | | | | | | | Make it a template based class, so we can store more then just integers here and replace more StringHash'es with it. Change-Id: I21442d13c6260f184bc7b63a8a58e826699f0c83 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Get rid of QQmlIntegerCacheLars Knoll2013-06-281-2/+2
| | | | | | | Replace by the new IdentifierIntHash. Change-Id: Ib210cd898a30ad3e2f9349387e1a74d92ed5f831 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Remove last traces of v8 API and v8 compatibility layerSimon Hausmann2013-06-121-1/+0
| | | | | | | | The debugger and profiler service remain as bigger parts that need to be ported properly to v4. Change-Id: I68e72d6db66fe497eb58ed60df417ffe4662d115 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Remove the remaining dependencies onto the binding rewriterLars Knoll2013-05-241-6/+4
| | | | | | | | Remove the remaining places that were rewriting bindings. Remove the binding rewriter class. Change-Id: Ib1e9121dc10f4526ddb7cf0ae32fecd8ce2d4993 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Remove QV8Bindings classLars Knoll2013-05-241-6/+2
| | | | | | | | | This class tries to optimise binding compilation with v8. With the approach in v4 where we don't rewrite binding expressions anymore, this is not required anymore. Change-Id: I616aeeba85bc17a950d4c7341b3042ed8aa42bff Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Remove all references to the old v4 codeLars Knoll2013-05-231-1/+1
| | | | | | | | The old v4 files have already been removed, so cleanup all the #ifdef'ed code that still references them. Change-Id: Ifc5c59add5af36a61586a43b13291d7836cccd78 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Convert some v8::Persistent to v4Lars Knoll2013-05-061-1/+1
| | | | | Change-Id: Ic6613b020dbbb1ee75e2096707d8fb1aa228083d Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Update copyright year in Digia's license headersSergio Ahumada2013-01-101-1/+1
| | | | | | Change-Id: I6c3bd7bebe3d62d1cfd0fa6334544c9db8398c76 Reviewed-by: Akseli Salovaara <akseli.salovaara@digia.com> Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
* Change copyrights from Nokia to DigiaIikka Eklund2012-09-231-24/+24
| | | | | | | Change copyrights and license headers from Nokia to Digia Change-Id: Ie7f5d49ed8235d7a7845ab68f99ad1c220e64d5c Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Evaluate bindings more intelligently during constructionAaron Kennedy2012-08-291-1/+2
| | | | | | | | | | | | | | | | | Instead of just evaluating bindings in a fixed order, and possibly having to evaluate a single binding multiple times, prior to reading a property, we check if there are any bindings "pending" on it and evaluate them then. A pending binding is one that has been assigned to the property, but not yet evaluated. To minimize side effects we only do this for "safe" bindings. A safe binding is one that has no side effects, which we currently define as not calling functions or otherwise assigning values during its evaluation. This isn't an entirely foolproof way to ensure that the evaluation has no side effects, but it should be good enough. Change-Id: I98aa76a95719e5d182e8941738d64f8d409f404a Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
* Reduce memory consumption of source coordinatesMatthew Vogt2012-08-161-1/+1
| | | | | | | | | | Reduce memory consumption by storing source location coordinates as 16-bit variables (in run-time structures). Also modify qmlmin to restrict line lengths so that the column bound is not normally exceeded. Change-Id: I08605626ffbdf081b6da2aea1116bdfe24998572 Reviewed-by: Yann Bodson <yann.bodson@nokia.com>
* Use V4 binding for non-final properties where possibleMatthew Vogt2012-07-091-1/+2
| | | | | | | | | When a property referenced in a binding is not marked as final, do not automatically abort optimization. Instead generate both V4 and V8 binidngs, and only fall back to the V8 binding if necessary at run time. Change-Id: I1bcc7e2b495935c5d519a9a223f640c1972cdb4e Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
* Handle enum values of -1 correctly.Michael Brasser2012-06-221-1/+1
| | | | | | | | | | This was already handled correctly most places; now the remaining cases (using an enum in ListModel, and assigning an enum to an integer property) should also work correctly. Task-number: QTBUG-21679 Change-Id: Ibff13f0b94da94b18e2e3bae4aa6ba44e0fa944b Reviewed-by: Chris Adams <christopher.adams@nokia.com>
* Disallow parent changes for QML created objectsAaron Kennedy2012-06-061-1/+1
| | | | | | | | | Currently this is protected with a QML_PARENT_TEST environment variable to allow the rest of QtQuick to be updated before it is enforced. Change-Id: I4dd3644cbbce91d67f24c9556637f97eafb00638 Reviewed-by: Kent Hansen <kent.hansen@nokia.com> Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
* Avoid copy-and-paste of property cache resolution codeKent Hansen2012-06-011-0/+1
| | | | | Change-Id: I0f3d8c1641c7c277ef62af7d4f81437e44ac0bad Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
* Initialize data members in QML engineMartin Jones2012-05-291-1/+1
| | | | | | | | Found by static analysis. None look suspicious, but worthwhile cleaning up. Change-Id: Icb5046eb9e57493a9c68b3509ca0c7f546480b73 Reviewed-by: Chris Adams <christopher.adams@nokia.com>
* Lazily create QMetaObjectsAaron Kennedy2012-05-241-13/+7
| | | | | | | | | | For internal QML built types, creating a metaobject each time is just wasteful. Additionally, as the property caches were always created from the intermediate QMetaObject, it was difficult to pass information directly from the compiler to the property cache. Change-Id: I769526b0edaaf16a86883f3065b75618b94e4077 Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
* Optimize QML enum resolutionMartin Jones2012-05-241-1/+1
| | | | | Change-Id: Ibc9ffe882045adf1c1149601c3499e31b9393eeb Reviewed-by: Michael Brasser <michael.brasser@nokia.com>
* Minor optimizations and cleanupAaron Kennedy2012-05-041-2/+1
| | | | | Change-Id: Iecbd5c46af00f649b1f1d78cdf5f2b40a2844897 Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
* Initial bundle supportAaron Kennedy2012-05-041-1/+1
| | | | | Change-Id: I095249f64ecf4ef1e3fbfb164e3d50edffab61e8 Reviewed-by: Roberto Raggi <roberto.raggi@nokia.com>
* Merge master <-> api_changesMatthew Vogt2012-03-051-0/+1
| | | | Change-Id: Iad2f07b989b25349fd2d4fff010e24dcd5a1688f
* Rename QDeclarative symbols to QQuick and QQmlMatthew Vogt2012-02-241-0/+466
Symbols beginning with QDeclarative are already exported by the quick1 module. Users can apply the bin/rename-qtdeclarative-symbols.sh script to modify client code using the previous names of the renamed symbols. Task-number: QTBUG-23737 Change-Id: Ifaa482663767634931e8711a8e9bf6e404859e66 Reviewed-by: Martin Jones <martin.jones@nokia.com>