aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/qml/qqmlcompiler_p.h
Commit message (Collapse)AuthorAgeFilesLines
* Remove QQmlCompiledData in favor of QV4::CompiledData::CompilationUnitSimon Hausmann2016-06-011-101/+0
| | | | | | | | | QQmlCompiledData used to contain the binary data for instantiating QML types in the QML VME. Nowadays the QML type compiler as well as the JavaScript compiler create a QV4::CompiledData::CompilationUnit. Change-Id: I155f62a5ecfb55a3fe230520231b6d8fd5b28ac9 Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
* Ensure that CompilationUnit instances are deleted in the engine threadSimon Hausmann2016-06-011-3/+0
| | | | | | | | | | | | | When using CompilationUnit with a QML engine, ensure that they are deleted in the same thread as the QML engine. Only the QML engine has a secondary thread (not a plain QJSEngine) and there it may happen that the last refcount drops within the loader thread. For example when the trimCache() is called within the loader. The destruction of the CompilationUnit however is not safe to perform in a secondary thread. Change-Id: Ia0105a8885ec97b0b2159e32e637adbd4e99f016 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Remove inheritance of QQmlCompiledData from QQmlCleanUpSimon Hausmann2016-06-011-5/+1
| | | | | | | | | The clear() re-implementation from QQmlCleanUp was empty, so this added no functionality. Commit 19c6f620dd35916466c36234231d798f79732ab0 removed the last usage of it. Change-Id: I499a6daeb1f74cc8bad1cacc5c367fde1e6eee75 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Moved meta-type id members to QV4::CompiledData::CompilationUnitSimon Hausmann2016-05-311-4/+0
| | | | | Change-Id: I808d0a36094e873b69cf24a5b0113e741ff2a25d Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Moved resolved type references over to QV4::CompiledData::CompilationUnitSimon Hausmann2016-05-311-27/+0
| | | | | Change-Id: I99bb37bf4d4aa4aedd8e02a0fb4afb4a908573a6 Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
* Move dependent scripts to QV4::CompiledData::CompilationUnitSimon Hausmann2016-05-311-2/+0
| | | | | Change-Id: I85e8267ce4cd26ae83fe567357e1368658fdb43d Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Moved object/bindings/customparser counters to CompilationUnitSimon Hausmann2016-05-311-4/+0
| | | | | | | These allow pre-allocating some arrays when instantiating types. Change-Id: I2ca4ba4a69429918f03a5ba4c501c763e7ffa8dc Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Moved the import cache from QQmlCompiledData to CompilationUnitSimon Hausmann2016-05-311-2/+0
| | | | | Change-Id: I77892919678cb01ba1e697a44122760679a72045 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Move property caches from QQmlCompiledData to QV4::CompiledData::CompilationUnitSimon Hausmann2016-05-311-8/+0
| | | | | | | | | This makes particularly sense as the binding property data per object that allows us to avoid a by-name property lookup when instantiating types is also stored there. Change-Id: I4d9275c1d8fde252df83eb11a9dfea71e5e9583a Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Remove the custom parser binding bits hash table from QQmlCompiledDataSimon Hausmann2016-05-301-2/+1
| | | | | | | | | Similary to the other hash tables we can store the actual information about whether a binding is covered by a custom parser or not straight in the CompiledData::Binding. Change-Id: Iab9044af57338cec935d3ef38764d7dc1aa507e8 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Centralize deferred binding bit information in CompiledData::BindingSimon Hausmann2016-05-301-1/+0
| | | | | | | | | | | Ultimately the decision which bindings to initialize in a deferred way depends on the data in the meta-object (deferred property names entry). The hash in QQmlCompiledData is just caching this information. We are better off storing this single bit right in the binding itself instead of in a parallel data structure. Change-Id: Ib66d3550210af1f882b98b0ba9089391813d69ad Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Optimize named object handlingSimon Hausmann2016-05-261-3/+0
| | | | | | | | | | | | | | | | By storing the object indices of named objects in the CompiledData::Object of a component, we can achieve two things: (1) We can eliminate the hash of vectors in QQmlCompiledData for the object-to-id mapping (2) We can store the mapping from object name to integer object id in the CompilationUnit and share it across different QQmlContextData instances (as long as it is not modified). Also added a new test that verifies the functionality of a .qml file starting with Component{} itself with object names, something that was previously only implicitly tested through some of the examples (corkboards.qml for example). Change-Id: I28c70217222dc0e5252bf5247b7e3fc4def47446 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Simplify object to id-in-context mappingSimon Hausmann2016-05-261-3/+3
| | | | | | | | | By storing the calculated integer id for an id-named object in CompiledData::Object we can simplify the code and replace a hash table with a plain vector. Change-Id: I4a84cdd00e98766d603d152e5a6574b232771a02 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Add a flag to CompiledData::Object record component boundariesSimon Hausmann2016-05-261-1/+0
| | | | | | | | This allows simplifying some code and reducing the usage of the objectIndexToId hash maps. Change-Id: I1f08d4b224c4f9fa498d90471fa545ae4e4f2af4 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Get rid of QQmlCompiledData::rootPropertyCache memberSimon Hausmann2016-05-241-1/+1
| | | | | | | | This would not seem like a member variable that is hot enough to keep there and it is two loads away. Change-Id: Id7088771bd33545a2846cc3497e5904dd8ac4f5d Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Get rid of QQmlVMEMetaDataSimon Hausmann2016-05-241-3/+6
| | | | | | | | | | | It is unused now and we can remove it as well as its QByteArray based storage. The non-emptyness of the meta-data QByteArray was also used to indicate whether it is necessary to create a VME meta-object when instantiating an object. This bit is now folded into the flag of the QFlagPointer storing the property caches. Change-Id: I3c3604c61ff16a4e76912e68b1c19afdb0f2bd9d Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* CleanupSimon Hausmann2016-05-191-2/+0
| | | | | | | Remove two dummy forwarding functions Change-Id: I053f9aecc761772c932550a0ddbea390621049c1 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Updated license headersJani Heikkinen2016-01-191-14/+20
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* Update copyright headersJani Heikkinen2015-02-121-7/+7
| | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9 Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
* Simple cache of url for QQmlCompiledDataRobin Burchell2014-12-171-1/+1
| | | | | | | | | | | Removes URL parsing and allocation/deallocation overhead as a bottleneck from cached instantiation. Takes total runtime percentage of beginCreate from 6208ms to 4987ms out of a 15 second trace of the instantiation_cached librarymetrics benchmark with the empty Item data. Task-number: QTBUG-43096 Change-Id: Ie4ec8e83461b4926e502dd78a7178cc8e8131e70 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* Fix QQmlExpression/QQmlScriptString/QQmlBinding crashesSimon Hausmann2014-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | In the QQmlScriptString we store the binding id and it is an index into the runtimeFunctions array of the compilation unit. However we don't store the compilation unit and instead in QQmlBinding and QQmlExpression try to retrieve it from the cache via the context url (we have the context after all). That turns out to be not a reliable way, as sometimes the URL might slightly differ from the originally compiled cache (qrc:/// turning to qrc:/ maybe). Consequently the type is (unnecessarily) compiled again and unfortunately not _linked_, therefore the runtime functions array is empty. Another option is that when the component was created from a QByteArray, then no entry exists in the cache in the first place. This patch addresses the problem by storing a reference to the compilation unit in the QQmlContextData. That we can safely retrieve and it'll make sure the compilation unit also stays alive. In the process of that the manual reference counting was switched over to QQmlRefCount and QQmlRefPointer for QV4::CompilationUnit. Task-number: QTBUG-41193 Change-Id: I9111f9a3b65618e453954abcd789c039e65a94f7 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Update license headers and add new licensesJani Heikkinen2014-08-251-19/+11
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 & LICENSE.GPLv2 - Removed LICENSE.GPL Change-Id: I84a565e2e0caa3b76bf291a7d188a57a4b00e1b0 Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
* CleanupSimon Hausmann2014-08-151-3/+2
| | | | | | | | | Merge QV4::CompiledData::QmlUnit into QV4::CompiledData::Unit. For pure JS units it means a slight increase of memory usage by a few bytes, but overall it makes the code a lot simpler. Change-Id: Ib48927749720b056f004aac0fe22cb8ec729e3f6 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Cleanup: Get rid of the url and file name members in QQmlCompiledDataSimon Hausmann2014-06-051-2/+2
| | | | | | | | This is part of the effor of moving members from QQmlCompiledData into QV4::CompilationUnit in order to eliminate the former in the long run. Change-Id: Icce7fe0ee9a49cb3a7677fd7020008fc55ecdcf6 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Rework custom parser integrationSimon Hausmann2014-06-041-10/+2
| | | | | | | | | | | | | | | | | | | | | | | The custom parser design used to be so that the custom parser operates on the "AST", creates its own binary representation of the data it needs, stores it in a QByteArray and gets that at object instantiation time. That meant serializing everything necessary. With the introduction of the "binary" QML data structure, that process of serialization becomes obsolete and would require extra work in the custom parsers for example for QQuickStates to store the translation parameters. The clean solution is to eliminate this unnecessary serialization process and instead let the custom parsers do a verification pass at type compile time and then simply operate directly on the QV4::CompiledData::Bindings at object instantiation time. That simplifies the code, and allows for support of translations throughout all list model properties. Additionally this speeds up the creation of state objects and reduces memory consumption. Previously a text: qsTr("foo") binding in states would result in an actual java script binding. After this patch it is merely stored as a string and translated at object instantiation time. Change-Id: I7550274513f54abb09a0ab4de51c4c0bcdb23cae Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Avoid recompiling of signal handlers defined in QtQuick state changes and ↵Simon Hausmann2014-04-021-0/+3
| | | | | | | | | | Connection objects We can re-use the expression we've compiled at QML type compilation time, as long as we "inject" the signal parameters in the dynamic qml lookup chain. Change-Id: Icc417531c41dea06ff5d033011179af49b03f542 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Cleanupsv5.3.0-beta1Simon Hausmann2014-03-211-7/+2
| | | | | | | | | * Get rid of members in QQmlCompiledData that were used by the VME and are now unused * Get rid of QQmlVME friend declarations that are not needed anymore Change-Id: I11b4b6f0b4b0b60edf92a1256be3d0d44d76bbc9 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Cleanup: Remove last traces of QQmlScriptSimon Hausmann2014-03-191-1/+0
| | | | | | | | | | What remains is the code for removing .pragma from script source code (and replacing it with white-space to preserve line/column numbers). The previous code even returned the value of the pragmas, but for the remaining caller sites that value isn't used, so we can just return void. Change-Id: I16db15da236970660b817d6c4493005365a7a1af Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Cleanup, part 2Simon Hausmann2014-03-181-1/+0
| | | | | | | | | | | * QQmlCodeGenerator -> QQmlIR::IRBuilder (it doesn't generate code, it generates the Object/Property/Signal/etc. IR of the .qml file, that's going to get transformed to QV4::CompiledData::*) * ParsedQML -> QQmlIR::Document Change-Id: I329e858487b66e1ae528d44316761f5dd34b79f4 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Remove old compiler and VMESimon Hausmann2014-03-071-348/+0
| | | | | | | | | | | | This removes the bulk of the code. A few smaller cleanups remain, to be done in smaller changes as they move code around. Additionally the "optimize" option of qqmlbundle was removed. It called QQmlScript::Parser::preparseData, which however was not implemented and always returned an empty QByteArray. Therefore "optimize" would not do anything and the class is gone now :) Change-Id: I0c265e756704cb53c5250be1f69e4a3e1b6e64d5 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Add support for deferred propertiesSimon Hausmann2014-03-051-0/+1
| | | | | Change-Id: I592518444ef353cfcf153df0e6afa2fbac613560 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Fix some qqmlincubator testsSimon Hausmann2014-03-041-0/+1
| | | | | | | | | | | | | | | We need to track the objects created and pass them over to the VME guard used in the incubator. The incremental build nature of the incubator requires that to avoid crashes. For nested incubators we need to set the activeVMEData field in the root QQmlContext, to allow child incubators to locate the parent. Lastly we need can emulate most of the VME behavior in terms of build states when running with QQmlInstantiationInterrupt by presenting four build steps: The initial state, two build steps, a finalization step and the state when we're done. Change-Id: I16cd7f71744decb9d4735ec77e9d944fad18e88d Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Fix for tst_qqmlconnectionsSimon Hausmann2014-03-021-1/+5
| | | | | | | | | | | | | Make sure to pass onFooChanged handlers to QQmlConnection's custom parser by not relying on the signal handler converter to set the IsSignalHandlerExpression flag. That should only be set for real signal handlers, the custom parser gets the raw bindings. Also don't try to initialize bindings at creation time the custom parser covers. Change-Id: Iae22bc886c312843136f073959e59da440f4184c Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* Clean up our internal namespacesLars Knoll2014-02-231-1/+1
| | | | | | | | QQmlJS::MASM -> QV4::JIT QQmlJS::V4IR -> QV4::IR Change-Id: I707e8990459114a699c200fe3c22cec3c8df1afc Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* [new compiler] Fix parser status and created bindings allocationSimon Hausmann2014-02-071-0/+3
| | | | | | | | | | | | | | | Pre-calculate the amount of space we need for binding and parser status callbacks at compile time and therefore use a much simpler data structure (vector) to store the points to the bindings and callbacks. They need to be stored because during object construction and binding enabling phase, it may happen that they get destroyed and thus their m_mePtr pointing into the array gets deleted. The contiguous vector will also make it possible to interrupt the completion phase. Change-Id: Ic7c985bb8325ab355112e30e9d33d6ae4e7476d1 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* fix whitespaceOswald Buddenhagen2014-01-221-15/+15
| | | | | | | remove trailing spaces and expand tabs Change-Id: Ieacb9d096b612c45d1a64700044c114d1f7522bc Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
* [new compiler] Add support for QML list modelsSimon Hausmann2014-01-201-1/+0
| | | | | | | | | | | | | List model definitions make heavy use of custom parsers, which requires AST access as well as a general port to the new QQmlCustomParser API. Additional fixes in the custom parser support were needed to pass all tests: * Fix support for AcceptsSignalHandlers and AcceptsAttachedProperties * Don't call setCustomData unless the compiler generated data earlier Change-Id: Ic42f8a890391267c94f63d35f055b60fdbf3c83d Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Fix refcounting leaks with property cachesSimon Hausmann2014-01-201-1/+1
| | | | | | | | | | | The TypeReference is not copy-safe, as it holds refcounted property cache pointers. For the new compiler code path, don't copy them but keep pointers to TypeReference objects around. Also make sure to ref the root property cache correctly and avoid the unnecessary addref for the property cache when creating new vme meta objects (initial refcount is 1). Change-Id: I0c4b952c8300c2167d926d9c35b8579fd505d596 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Add support for type and enum resolution for custom parsersSimon Hausmann2014-01-171-3/+5
| | | | | | | | | This is in preparation for listmodel support, share the code for resolving types and enums between the old and the new compiler, as all it needs is the imports. Change-Id: I4908d71eee50c769108e0e2b68b03496722fa49d Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Clean up property cache / meta object builderSimon Hausmann2014-01-171-2/+2
| | | | | | | | Move the outter loop into the builder class itself, use a vector instead of a list (we know that it's a fixed size and we only do indexed access) Change-Id: I933f0496ea47b3bc7c2bebde7f1a14b4f603b4c3 Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* [new compiler] Initial support for custom parsersSimon Hausmann2014-01-081-0/+2
| | | | | | | | Enough to support the Connections {} element. What's missing are pre-compiled bindings signal handlers. Change-Id: I3ad1413fa636434d899ae8fb380249aaf40363dc Reviewed-by: Lars Knoll <lars.knoll@digia.com>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-12 17:00:20 +0000