aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/qml
Commit message (Collapse)AuthorAgeFilesLines
* On network redirects, update finalUrl, not urlUlf Hermann2018-05-251-8/+11
| | | | | | | | | | | | | | | | We want all further imports to be relative to the redirected URL, not the base one. Note that this will incorporate any prior URL interceptions into the final URL if a redirect happens. We don't really want this to happen because the result of interception is not meant to be the base for further URL lookup. However, as interception occurs before redirection, this is unavoidable. Don't use URL interceptors on remote URLs. Task-number: QTBUG-67882 Change-Id: I6693d14c8af8212dda9954d0bd0293c3c85441ef (cherry picked from commit cda2680d801acce4e221b23e88d9b3c5504f86e8) Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix QML context leak with visual data model and list property modelsSimon Hausmann2018-05-072-5/+13
| | | | | | | | | | | | | | | | | | | | | | | When using the VDM or QML list properties as models, the delegate model injects an intermediate QQmlContext that provides access to the properties of the exposed QObject as context properties. Before commit e22b624d9ab1f36021adb9cdbfa9b37054282bb8, that context was marked to be owned by the parent QQmlContext. When the reference counting was introduced, that parent became referenced from the cacheItem (DelegateModelItem), but that intermediate QQmlContext became floating and was leaked. This can be observed by running the objectListModel test of tst_qquickvisualdatamodel with detect_leaks=1 in ASAN_OPTIONS. The leak is fixed by re-introducing the exceptional case of a parent holding a strong reference to the child, in just this one case. Change-Id: Iabc26990d39757b0abe0cddf69e76e88e40fba40 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Michael Brasser <michael.brasser@live.com> (cherry picked from commit 01df9e5f46fd05a80f8f6fcaa91204e6184ded6f)
* Fix crash when calling QQmlEngine::clearComponentCache()Simon Hausmann2018-04-106-61/+71
| | | | | | | | | | | | | | | | | We must protect various resources in the type loader with our existing lock. The QQmlTypeLoaderQmldirContent is now value based, so that we can release the lock on the shared cache early. Copying it involves adjusting the refcount of the QHash and QString instances in the QQmlDirParser. The safety of this was verified with a TSAN build and the example supplied in the task. It crashed reliably with TASN errors first and with this patch it runs without errors. Task-number: QTBUG-41465 Change-Id: I616843c4b8bdfd65d1277d4faa8cb884d8e77df8 Reviewed-by: Lars Knoll <lars.knoll@qt.io> (cherry picked from commit a3ad52526f79c1528f170c8affe5af00b68ca61d)
* Handle function expressions as signal handlersErik Verbruggen2018-03-281-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two ways to use function expressions on the right-hand side of bindings: property var somethingPressed somethingPressed: function() { /* ..press something else.. */ } signal buttonPressed onButtonPressed: function() { /* ..handle buttonPress.. */ } In the former case, it declares a property that holds a function. So on initialization, the right-hand side of the binding returns a closure that gets assigned to the property 'somethingPressed'. In the latter case, the signal handler is explicitly marked as a function for clarity. So, the handler should not be returning the closure, but the handler should *be* the closure. In general, it is not possible to detect if the left-hand side is a property or a signal handler when generating QML cache files ahead of time. So for this case, we mark the function as only returning a closure. Then when instantiating the object, we check if it is a signal handler, and if the handler is marked as only returning a closure. If so, we set that closure to be the signal handler. This patch also handles function expressions in SignalTransition and function expressions as signal handlers. Task-number: QTBUG-57043 Task-number: QTBUG-50328 Task-number: QTBUG-50328 (cherry picked from commit 22b13921f8067f8a93164875a4ad59bed85b0400) (cherry picked from commit dc4d6293f9473c0f03c570430d08867d2d01c6e2) (cherry picked from commit 21301c1dbb00f4a2cd991e520423ed039b297ffb) Change-Id: I3008ddd847e30b7d0adef07344a326f84d85f1ba Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix issue with bindings to aliases that cannot yet be resolvedErik Verbruggen2018-03-155-60/+100
| | | | | | | | | | | | | | | When an alias points to a child object which has not yet been initialized, it's id won't have been registered yet, so setting up a binding to it will result in a crash. The fix is: when setting a binding target fails, and its target property is an alias, queue them until all bindings have been set up, and try again. Task-number: QTBUG-57041 Change-Id: I4dc5a6d25c0a32fed9fd952c955e2006c76be45a Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> (cherry picked from commit aa94c6c0469b0595f483f13ac88459f0035deef9)
* Fix memory leak with JS importsSimon Hausmann2018-02-092-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Strictly speaking this is a regression introduced with commit e22b624d9ab1f36021adb9cdbfa9b37054282bb8, making the QQmlContextData objects reference counted, especially from the V4 QML context wrapper objects. That change (correct as it is) introduced an accidental circular dependency in the simple scenario of importing a .js file in a .qml file: Each time the type in the .qml file is instantiated, we create a dedicated QQmlContextData for the .js file. If the .js file has no imports itself, that new context will get the same ctx->importedScripts JS array as the QML context of the .qml file. That is a strong reference via QV4::PersistentValue. That array in turn contains the QV4::QmlContextWrapper that belongs to the imported script, which in turn holds a strong reference (via refcount) to the script's context. This patch breaks the circular reference when we perform context invalidation, as the least intrusive measure. For the auto-test to work, we must also clear the qmlContext persistent of the QV4::Script that's used to evaluate the .js file. In subsequent imports that persistent will be initialized to new values, so it will only hold a strong reference to the last import, but strictly speaking that is still a leak - hence also part of this fix. Change-Id: I3e543c946e5e683425072dc3df7e49ca0e0c0215 Task-number: QTBUG-66189 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix memory leak with deferred propertiesSimon Hausmann2018-02-061-1/+2
| | | | | | | | | | | | | | | | | | | | | | This is a regression introduced with commit 3b6eeee177b64eebe240d51be0c7bb5f031471d8 in the 5.9 branch. When constructing an object with deferred properties and not running qmlExecuteDeferred, then the deferred data would never get deleted because the bindings list remains non-empty and we would leak the deferred data as well as the entire compilation unit behind it. This happens for example when declaring when instantiating a QML file with states: states: [ State { ... }, State { ... }, ... } Unless every state is entered, its deferred changes property is never applied (via qmlExecuteDeferred) and thus the defer data is leaked. Task-number: QTBUG-66189 Change-Id: I1b2119c601d1e0ab4e37f53d4cf2f569586ee883 Reviewed-by: J-P Nurmi <jpnurmi@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Clean up manual refcounting of compilation unitsSimon Hausmann2018-02-064-13/+23
| | | | | | | | | | | | | | | | Replace manual use in QQmlData and QQmlData::DeferredData with QQmlRefPointer. Due to forward declaration trouble this required declaring a non-inline constructor/destructor for QQmlData and DeferedData and disabling copying, so that not every C++ compilation unit including qqmldata_p.h needs to instantiate the QQmlRefPointer destructor and thus know whether QV4::CompiledData::CompilationUnit has release(), etc. The out-of-line declarations however should not have any negative impact as the only call sites are within qqmlengine.cpp, too. Change-Id: I2e8295cb0d7f876a5d7d18765dbac285184e6c99 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix memory leak with value typesSimon Hausmann2018-02-021-0/+2
| | | | | | | | | | Commit 3b14e2ffdd8eb4b7f7f4508768b75f2acc399370 replaced the QQmlRefPointer<QQmlPropertyCache> with a raw QQmlPropertyCache pointer and added a V4_NEEDS_DESTROY tag. However unfortunately the destroy() method in the heap class does not decrease the reference count. Change-Id: I90a8c56cd638592b67aae7041fbb57c879c4146c Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix dead lock / race in QML type loader when importing pluginsSimon Hausmann2018-02-021-66/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When importing modules - in the QML loader thread - with plugins we keep globally track of the Qt plugins that we have loaded that contain QML modules, to ensure that we don't call the engine-independent registerTypes() function on the plugin multiple times. After registerTypes() we may also call initializeEngine() on the plugin for the engine-specific initialization, which - as a QQmlEngine is provided as parameter - must happen in the gui thread. For that we issue a thread-blocking call that waits until the gui thread has woken up and processed the event/call. During that time the global plugin lock is held by that QML loader thread. If meanwhile the gui thread instantiates a second QQmlEngine and attempts to issue a synchronous type compilation (using QQmlComponent::CompilationMode::PreferSynchronous), then gui thread is blocking and waiting for its own QML loader thread to complete the type compilation, which may involve processing an import that requires loading a plugin. Now this second QML loader thread is blocked by trying to acquire the global plugin registry lock (qmlEnginePluginsWithRegisteredTypes()->mutex) in qqmlimports.cpp. Now the first QML loader thread is blocked because the gui thread is not processing the call events for the first engine. The gui thread is blocked waiting for the second QML loader thread, which in turn is stuck trying to acquire the lock held by the first QML loader thread. The provided test case triggers this scenario, although through a slightly different way. It's not possible to wait in the gui thread for the plugin lock to be held in a loader thread via the registerTypes callback, as that also acquires the QQmlMetaType lock that will interfere with the test-case. However the same plugin lock issue appears when the first QML engine is located in a different thread altogether. In that case the dispatch to the engine thread /works/, but it won't be the gui thread but instead the secondary helper thread of the test case that will sit in our initializeEngine() callback. This bug was spotted in production customer code with backtraces pointing into the three locations described above: One QML loader thread blocking on a call to the gui thread, the gui thread blocking on a second QML loader thread and that one blocking on acquisition of the plugin lock held by the first. Fortunately it is not necessary to hold on to the global plugin lock when doing the engine specific initialization. That allows the second QML loader thread to complete its work and finally resume the GUI thread's event loop. Change-Id: If757b3fc9b473f42b266427e55d7a1572b937515 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Disallow registration of types beginning with lowercase lettersMitch Curtis2018-01-311-0/+9
| | | | | | | | | | | | | | Allowing types with lowercase names causes ambiguity, as can be seen in QTBUG-43567 and the comment in IRBuilder::visit(), which explains that "the grammar can't distinguish between two different definitions" whose only difference is casing of the first letter. - Prevent registration (return -1 with e.g. qmlRegisterType()) when a type name doesn't begin with an uppercase letter. - Document the uppercase type name rule in more places. Change-Id: I4e522c65990f418eaafa45a256e3cb07a3e01ba4 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix exposure of -1 as enum value in QML exposed C++ singletonsSimon Hausmann2018-01-311-10/+12
| | | | | | | | | | | | | | | | | When a C++ singleton has an enum with the value -1, we would expose that value correctly when taking the accelerated property access code path in the optimizer, but when going through the slower QQmlTypeWrapper we would return undefined. This turned out to be a silly logic error that assumed that -1 is not a valid value for an enum and instead indicates an enum value not present. [ChangeLog][Qml] Fix -1 as enum value in QML exposed C++ singletons showing up as undefined. Task-number: QTBUG-66067 Change-Id: Ib66dad7a4b59822b2c40ad6bd9af4b72469582e9 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Michael Brasser <michael.brasser@live.com>
* Allow for currentQmlContext to be inlinedErik Verbruggen2018-01-182-6/+12
| | | | | Change-Id: Ic2a98a3a4b4362036222df05a92c0bed633c1d1c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Optimize QQmlProperty constructor for the common property caseSimon Hausmann2018-01-171-66/+70
| | | | | | | | | | | | | The common case is that QQmlProperty is constructed on the property of an object, not a group property. Therefore we should do the QVector<QStringRef> split on the property name by '.' only if a dot exists, and can avoid the allocation and deallocation of the vector. Shaves off ~1.2% off delegates_item_states.qml. Task-number: QTBUG-65708 Change-Id: Iffbde176e616beec0ae0a47216360558adc793ee Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Speed up PropertyChange state applicationSimon Hausmann2018-01-172-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Every time we decode a potential binding of a PropertyChanges{} object, we call qmlContext(this) and we go through a full QQmlProperty construction (which involves property name decoding by dots and property lookups), just to determine if we're doing a binding on a property or a signal. QQmlProperty::isSignalProperty() will only return true if the property is valid and if it's a "function" type. The QQmlProperty constructor on the other hand only constructs a valid regular property if it's _not_ a function type and a signal property _has_ to start with "on" followed by an upper case character. We can copy this shortcut out into decodeBinding() to avoid the QQmlProperty construction in the common case of plain property bindings. This is also legit in the scope of group properties, as signal bindings on group properties are not supported (we always use the state's target object for signal lookup, never the group object). In addition, avoid creating a public QQmlContext for the PropertyChange object by allowing for the construction of the QQmlProperty object via the QQmlContextData, as that's the only data structure we really need. These two changes used to be separate, but they need to go together to keep the tests passing, as the property validation and warning issuing is now moved from decodeBinding() into ::actions() itself. Shaves off 1.5% off delegates_item_states.qml Task-number: QTBUG-65708 Change-Id: I32a17d815bd3495a907a51068a971eb7cb69c6ef Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Prevent a QVector detachErik Verbruggen2018-01-171-1/+1
| | | | | Change-Id: Ibda07de7a83cf9a1434532c485583b8b49b0a605 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Revert "Allow canceling incubation"J-P Nurmi2018-01-176-49/+0
| | | | | | | | | | | This reverts commit ca6b787a01ea289bd5c2a3e4ff3c7442a4ff58fc. This internal API was added as a workaround for Qt Quick Controls 2. It is no longer needed now that Qt Quick Controls 2 are using deferred execution. Task-number: QTBUG-50992 Change-Id: Iaddf22460f091743e1a68acd16813a28f3e82ecb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Have more bindingBits available inlineLars Knoll2018-01-172-43/+40
| | | | | | | | | | Many QML items have more than 32 properties, so we ended up malloc'ing the binding bit table on the heap quite often. Extending the inline data to be able to accommodate for up to 64 properties fixes that. Change-Id: I90a42d601a5406ffacf2506f1957b0c2080bbb7b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Constify QObject* argument to QQmlData::wasDeleted()Mitch Curtis2018-01-111-4/+4
| | | | | | | | Because it doesn't hurt and it makes it easier to use it in QObjectWrapper::query(). Change-Id: I727ce4b862fa34866513cbb80a221a8a3aeca363 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Allow QQmlComponent::loadUrl() to load absolute URLs with relative pathsMitch Curtis2018-01-041-13/+19
| | | | | | | | | | | | | | | | | | | | | Currently, QQmlTypeLoader::getType() will assert if passed a relative URL, because it needs absolute URLs in order to ensure that it can use them as keys for its cache. After dc6b73390 was merged, URLs like QUrl::fromLocalFile("main.qml") (which are currently used in examples of how to load a QQmlComponent) started causing the assertion to fail. As mentioned in the comments of the bug report, some patches have already been applied to QQmlComponent's QString-based constructors, but both the constructors taking a QUrl and loadUrl() itself need fixing. This patch puts the fix into loadUrl() (the constructors call this function) so that every operation involving URLs is successful when using the documented methods. Task-number: QTBUG-58837 Change-Id: Ib54ca52eddce6e7781cf96015f4c15af604233d3 Reviewed-by: David Faure <david.faure@kdab.com>
* Use potentially intercepted URL as ID for compilation unitsUlf Hermann2017-12-216-39/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | We generally have to pass a URL and a file name everywhere because the logical URL might be something else than the actual file being loaded. For example a QQmlFileSelector might modify the URL to be loaded for a specific file. This resulting URL, however, should not be used to resolve further URLs defined in the file loaded that way. As we need to access QQmlTypeLoader::m_url as string more often now, cache it and avoid frequent translations between QUrl and QString. Furthermore, QQmlDataBlob's URLs are changed to follow the same semantics. The finalUrl is the one that should be used to resolve further URLs, the url is the one used to load the content, and subject to any redirects or interceptions. This changes the semantics of URL redirects. Previously a redirected URL was used as the base URL for furher URL resolution. This doesn't work because redirection occurs after interception and interception should not influence the resolution of further URLs. We now use the original URL as base URL for resolution of further URLs and rely on the server to redirect those, too. Task-number: QTBUG-61209 Change-Id: I93822f820bed2515995de3cb118099218b510ca4 Reviewed-by: Michael Brasser <michael.brasser@live.com>
* Add a means to unregister custom qml typesAndy Shaw2017-12-012-0/+23
| | | | | | | | | | | | | | | In cases where Qt is used in a plugin it is possible that a plugin will be unloaded while Qt itself is still loaded and as a result there is a chance that there will be conflicting types registered. Therefore, to ensure that plugins correctly clean up after themselves cleanly, we need to add a means to unregister qml types. This is intended to only be used when the user knows what they are doing. Task-number: QTBUG-56521 Task-number: QTBUG-56532 Change-Id: Ie396e522385004e6e9f3841e04f8072ff29cb15b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Check linked contexts for context objects being deletedUlf Hermann2017-11-281-1/+4
| | | | | | | | | | In QQmlObjectCreator::createInstance we can assign the new object as context object to a linkedContext of its QQmlData, not only it's ownContext. Consequently, we have to check all the linked contexts and remove the object when found on deletion. Change-Id: I09bccdb0190406245fa5a379edaff0a8f118062f Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Merge "Merge remote-tracking branch 'origin/5.9.3' into 5.9" into ↵Liang Qi2017-11-251-1/+9
|\ | | | | | | refs/staging/5.9
| * Merge remote-tracking branch 'origin/5.9.3' into 5.9Liang Qi2017-11-231-1/+9
| |\ | | | | | | | | | Change-Id: Ic6457df47bed359fd43653e73726f1896944241c
| | * Improve encapsulation of the the IR de-serialization from QtQuick CompilerSimon Hausmann2017-11-121-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code used by QQC to deserialize the IR requires setting the javaScriptCompilationUnit member in order to connect the generated C++ code. Knowledge of the QmlIR::Document data structure layout on the side of the generated code (thus application) has its downsides though (see referenced bug). We can avoid that dependency easily by doing the entire de-serialization on the QtQml library side. The old "API" (load member function) is still around until the qqc change is also in. Task-number: QTBUG-63474 Change-Id: I239838afacc71474c86114b5b05679ff36e4c2e2 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | | More fine-grained deferred property executionJ-P Nurmi2017-11-254-13/+113
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows Qt Quick Controls 2 to defer the execution of certain building blocks until needed. For example, a button control can defer its background item so that the default background is not executed at all when replaced by a custom background. First of all, this gives a massive performance boost for customized controls. Secondly, this avoids the most burning issue in QQC2, problems with asynchronous incubation ("Object destroyed during incubation"). Task-number: QTBUG-50992 Change-Id: If3616c9dac70e3a474a20070ad0452874d267164 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Don't reject plugin-only qmldir filesUlf Hermann2017-11-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | On QQmlImportsPrivate::updateQmldirContent we need to check if the new module has actually been established after figuring out that it doesn't have any components or scripts. If it has, then we shouldn't fail, as obviously a plugin has been loaded. We don't need to check the component and script versions in that case, as plugins don't have separate versions. Change-Id: Ie328b59038fe65c3f6a2eeecfe969927bba6cd68 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Fix URL interception for qmldir filesUlf Hermann2017-11-223-17/+59
|/ | | | | | | | | | | | | | | | | We need to intercept the URL when it is created. This relieves us of the need to hack around in it when actually retrieving the content of the qmldir file and prevents the futile attempt to load remote qmldir files via the code path that should load local ones (or vice versa). The back and forth conversion between URLs and strings is unfortunate, but can only be solved by using QUrl rather than QString where we actually mean URL. This would be a bigger change which is unsuitable for 5.9. Mind that nothing changes for code that doesn't use URL interceptors. Task-number: QTBUG-36773 Change-Id: I6bff3ae352009fdc0a17ec209691c7b390367f11 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Prevent the QML engine from registering circular dependenciesErik Verbruggen2017-11-062-1/+10
| | | | | | | | Change-Id: Ic4fd2bde745e7dfaf0909e8cc575441bb04cefa3 Task-number: QTBUG-64017 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Marco Martin <mart@kde.org> Reviewed-by: Bhushan Shah <bshah@kde.org>
* Fix crash with dangling context object pointersAndy Shaw2017-10-261-0/+2
| | | | | | | | | | | | | This is a regression introduced by commit e22b624d9ab1f36021adb9cdbfa9b37054282bb8, where the object that owns the QML context would destroy the context upon destruction. Now the context may live longer and thus the context->contextObject pointer would become a dangling pointer. Task-number: QTBUG-63733 Change-Id: Idc660116752d312917a0a149110b92a042ccfb17 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Return "qnx" for Qt.platform.os when appropriateLiang Qi2017-10-242-0/+3
| | | | | | | | | | [ChangeLog][QtQml] Qt.platform.os returns "qnx" when running on QNX platforms. Task-number: QTBUG-52515 Change-Id: Ie46f235248f7832fff12906cf858e8527e8060b1 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQmlTypeLoader: Drain events before shutting down the threadUlf Hermann2017-10-201-10/+17
| | | | | | | | | | We take references to types when sending events to the other thread. If we don't process the events, the references are kept, which leads to memory leaks. Therefore, when shutting down a QML engine, we have to make sure the event queues are emptied. Change-Id: Id8b0440029cfd7d03a9e540747eaedbcaa7c9ff3 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Tell QQmlImportInstance::resolveType what kind of type we wantUlf Hermann2017-10-195-29/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | In QQmlTypeData::resolveTypes() we know if we're looking at a reference to a composite singleton type, or some other type reference. When we call resolveType() we expect the correct type to be returned, not only based on URL, but also based on its singleton property. QQmlTypeData::resolveType() eventually invokes QQmlImportInstance::resolveType() which will call fetchOrCreateTypeForUrl(), passing a parameter on whether the result should be a composite singleton. When operating on a qmldir component the component itself encodes this. When fetching a type from a local file without qmldir, we currently assume that it isn't a singleton, no matter QQmlTypeData::resolveTypes() has determined. This means that actual singletons loaded this way later get refused by the sanity check. In order to fix this, pass the information about the expected singleton property on to QQmlImportInstance. This is done using QQmlType::RegistrationType, which gets another entry for "any type". If the expected type is CompositeSingletonType QQmlTypeData::resolveType() will not create a non-singleton type. If it is any specific other type, it will not create a composite singleton. And if it is AnyRegistrationType, it will behave as it previously did. Change-Id: I6b7e082b63582e0aed946bb3d19077b94c7a45f7 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix execution of deferred propertiesJ-P Nurmi2017-10-186-31/+60
| | | | | | | | | | | When deferred properties were assigned in multiple contexts, only the outermost context was executed. Any deferred property assignments in other inner contexts were never executed. Collect the deferred data to a container to be able to execute them all. Task-number: QTBUG-63200 Change-Id: I88fab27c1f81b5188430ada086dcc19842507e99 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QQmlTypeLoader: The profiler is a quintptr(0) if QT_NO_QML_DEBUGGINGUlf Hermann2017-09-271-2/+2
| | | | | | | | | | This follows the pattern established in other places. Task-number: QTBUG-63392 Change-Id: I11cd66d5552f751804dd0a9460b26bda546c1726 Reviewed-by: Mikko Gronoff <mikko.gronoff@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
* Fix behaviors not working when sub-types declare propertiesSimon Hausmann2017-09-221-0/+2
| | | | | | | | | | | | | Since commit 81867dfbf9c16d4300727a08eed9b5c6c979e0ba we have an optimization in place to avoid the virtual meta-call when writing properties that cannot be intercepted. Unfortunately that check did not take parent VME meta-objects into account, which triggered the bug. Test case by Harald Hvaal <hhvaal@cisco.com> Task-number: QTBUG-63365 Change-Id: I66cb2967da2c09ca5e38cebd9db2ee6e3ee78f5f Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
* Fix qmlClearTypeRegistrations() not dropping all registrationsSimon Hausmann2017-09-192-0/+9
| | | | | | | | | | | | | In commit 48c09a85ce397979c7e706e3694c879ffe456e09 we added the undeletableTypes container to hold a reference on C++ registered types to keep the indices returned by the public qmlRegisterType() API stable. Since qmlClearTypeRegistrations() is API that also resets those indices, we must also clear the undeletableTypes container to avoid leaking memory. Change-Id: I2038c00913f894d58aca3714d64d497493585326 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix qml cache invalidation when changing dependent C++ registered QML singletonsSimon Hausmann2017-09-123-0/+25
| | | | | | | | | | | | | | | | | | When a qml file uses a qml singleton, we need to reliably detect when the singleton changes and re-generate the cache of the qml file using it. This is a scenario covered and fixed by commit 5b94de09cc738837d1539e28b3c0dccd17c18d29, with the exception that currently QML singletons registered via qmlRegisterSingleton were not added to the list of dependent singletons for a qml file. We can fix this by extending findCompositeSingletons() to also cover the singletons that do not originate from a qmldir file. [ChangeLog][Qt][Qml] Fixed bug where sometimes changes to a qml singleton would not propagate to the users or cause crashes. Task-number: QTBUG-62243 Change-Id: I16c3d9ba65fd82e898a29b946c341907751135a9 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove temporary allocations during type cleanupSimon Hausmann2017-09-081-1/+1
| | | | | | | | | | As a follow-up commit to 48c09a85, avoid the use of key() to create a temporary string when cleaning the QML type registry. There is strictly speaking no need to perform another hash lookup anyway. Change-Id: Ibd5f0210d5584d1f847d8ec61f25cb0972076365 Reviewed-by: Pasi Petäjäjärvi <pasi.petajajarvi@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Get rid of the root object index variableSimon Hausmann2017-09-082-3/+3
| | | | | | | | This is a follow-up to the parent commit to remove the variable that is really a constant (zero). Change-Id: I8fc20027c5c7b871269b814cb8b93636e94be267 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix crash with dangling context object pointersSimon Hausmann2017-09-081-0/+2
| | | | | | | | | | | | This is a regression introduced by commit e22b624d9ab1f36021adb9cdbfa9b37054282bb8, where the object that owns the QML context would destroy the context upon struction. Now the context may live longer and thus the context->contextObject pointer would become a dangling pointer. Task-number: QTBUG-63078 Change-Id: I8fdab4086b0472d5d4930cf57aa76922b7ed9e2e Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix crashes with closures created in QML componentsLars Knoll2017-09-068-78/+183
| | | | | | | | | | | | | | | When closures created inside QML components are called after the surrounding component (and consequently QML context) has been destroyed, we are in a somewhat limited environment. Initially we would just crash as the calling QML context is not valid anymore. We can alleviate that by introducing reference counting on the context and letting the QML context wrapper keep a strong reference. This avoids the crashes and also ensures that at least imports continue to be accessible within these contexts (as the singleton test case demonstrates). Task-number: QTBUG-61781 Change-Id: I893f171842d01b0863d95a02ea738adc2620e236 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Qml Tooling: Replace bare pointers with QScopedPointerUlf Hermann2017-09-062-11/+12
| | | | | | | This way we don't have to manually initialize and delete them. Change-Id: I0104c744dba380e957271d0924498e3643856e9e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QmlProfiler: Avoid race conditions in QQmlTypeLoaderUlf Hermann2017-09-052-4/+25
| | | | | | | | | | | | | We have to make sure all profiler calls to one adapter are done from the same thread. It turns out that all the calls from QQmlTypeLoader are done from the type loader thread. By using a separate adapter for that, we avoid any extra locking. Task-number: QTBUG-62987 Change-Id: I5cffcc30b84dd4154daa0c56312a1141ce2033e1 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Update doc to clarify the slot parameter for connectNotifySignalAndy Shaw2017-08-251-0/+3
| | | | | Change-Id: I89da2d258d6e5663d45497bd4b7fa105a11e46e7 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* Fix memory corruption with type trimmingSimon Hausmann2017-08-232-4/+4
| | | | | | | | | | | | | | | | | | When creating a composite type, we register the meta-type in the qml loader thread. However we would require linking of the compilation unit to the QML/engine thread before we would be able to also undo that registration in unlink(), because we require the engine member to be set. If that did not happen, i.e. a qml type was loaded and trimmed from the cache before it was ever linked, we would end up with a dangling pointer in m_compositeTypes. Let's handle the case of CompilationUnit referring to a QML composite type separately from it being a compilation unit resulting from a .js file or in a plain QJSEngine environment. Task-number: QTBUG-62630 Change-Id: Ia68cc46f05345702bd9ba0378f61118f1964d141 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Small cleanupLars Knoll2017-08-231-2/+1
| | | | | Change-Id: Ifb111ceab64244965569f59eda8d9604131d209d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Cleanup obsolete TODO in source codeLars Knoll2017-08-231-3/+0
| | | | | Change-Id: I0c4f5d908215b9b6fac0fadb352f7c36849dce6f Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Clean up void * usageLars Knoll2017-08-235-13/+16
| | | | | | | | Don't use void * in our internals, when we can simply pass a typed pointer. Change-Id: Id02033c7e66df7e041c079d3546f9dd6027ef8d5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-10 18:19:41 +0000