aboutsummaryrefslogtreecommitdiffstats
path: root/tests/auto/qml/qqmlecmascript/tst_qqmlecmascript.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* QQmlObjectCreator: Add scripts also to context of inline componentsFabian Kosmale2021-08-051-0/+11
| | | | | | | | | | | | | | | The object creator only called setImportedScripts on a context if subComponentIndex was -1 (indicating the root of a component). However, since the introduction of inline components, subcomponents can also be component roots. This patch adjusts the check to also consider inline components. This fixes the issue that javascript libraries could nod be referenced inside inline components. Fixes: QTBUG-95095 Pick-to: 6.2 6.1 Change-Id: I22d14c6f102edca6d2991d25280bfe3c42df820f Reviewed-by: Ivan Tkachenko <me@ratijas.tk> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* QV4::Heap::GeneratorObject: remove unused memberFabian Kosmale2021-08-021-0/+10
| | | | | | | | | | | | | The member was marked as a Pointer for the gc; however it was never used, and thus also left uninitialized. This could cause memory corruption or asserts during the gc's mark phase. Fixes: QTBUG-95417 Pick-to: 6.2 6.1 5.15 Change-Id: Ide826c0284b6060de8689e6f0dc753011108dba9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Use QV4::Scope::hasException() where applicableUlf Hermann2021-06-301-6/+6
| | | | | | | It is shorter and encapsulates the exception handling a bit. Change-Id: I8e2dc0eb3b930e222b8cb4852b73d99ca18a0379 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Evaluate type assertions in QMLUlf Hermann2021-05-261-0/+28
| | | | | | | | | | | | | | | | | | Type assertions actually check whether the expression matches the type, and return null if it doesn't. [ChangeLog][QtQml] You can use TypeScript-like type assertions using "as" now. In contrast to TypeScript, QML's type assertions are enforced at runtime. If the type doesn't match, null is returned for object types. Also, type assertions can only cast to object types. There is no way to create a value type or primitive type reference. As value types and primitives cannot be polymorphic, this doesn't matter, though. There are other ways of converting those. Task-number: QTBUG-93662 Change-Id: I00fce3d4ea7a8c6b4631c580eaf6c113ac485813 Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io> Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Make QDate handling consistent in its use of UTCEdward Welbourne2021-05-181-27/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to the quirk of ECMAScript's Date.parse() spec [0] stipulating the use of UTC for date-only strings, in contrast to most other ways of creating a Date using local time, reasonable users get surprised by the behavior of QDate properties initialized from strings. This can't be avoided without breaking other uses of Date, so document the work-around needed to cope with it (use UTC-specific methods to access the Date object). [0] https://tc39.es/ecma262/#sec-date.parse Make conversions back to QDate from Date work round the possibility that the Date, seen as a QDateTime(,, LocalTime), needs to be handled as UTC when extracting the date, and catch two more places that conversion from QDate neglected to use UTC's start of day, for consistency. Revised tests to call UTC-specific methods instead of the local-time ones, where appropriate. Drive-by: some tests were (entirely bogusly) constructing a fresh Date using the UTC-fields of the Date they had, in order to then test the non-UTC fields of this fresh Date; instead, simply test that the UTC fields are as expected. [ChangeLog][QML][Behavior change] Where a QDate is represented in QML's JavaScript as a Date, it is now more consistently associated with the start of the UTC day it describes. Previously cases where it was represented as the start of local time's day could lead to a Date turning into a QDate for the preceding day. Inconsistencies in the specified behavior of Date preclude eliminating such problems entirely, but they should now be limited to cases where (perversely for a date property or parameter) the date is specified with a local time late enough to make it coincide with the start of the next UTC day (in which case that next day's QDate will be its C++ representation). Fixes: QTBUG-92466 Change-Id: I2306dd9ecef0d5c2d59b562762392e51bb6d66ca Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Make tst_qqmlecmascript::dateParse() more thoroughEdward Welbourne2021-05-111-0/+5
| | | | | | | | | | | | Expand the test to pass a local-time QDateTime in (to check it arrives in the form expected) and, parallel to the UTC time test, that the various ways of constructing a local-time Date in JS do actually produce the expected results. Change-Id: I5ee8b4d3c0c15a5aa1168c7fb20646f3b55a7488 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Make a UTC time test more thorough and coherentEdward Welbourne2021-05-111-2/+3
| | | | | | | | | | | | | | | | | | It was previously mixing in testing of QString -> JS String and JS's Number() and its string's split(), none of which was relevant, illuminating or simplifying. It also had a MyDateClass instance in the test that wasn't used, and only failed or passed, without giving any clue to what went wrong. Add console.log()s to report each error, pass a UTC QDateTime as parameter instead of a QString, use the known values for the date and time fields instead of extracting them from a string, and verify that the passed QDateTime has all expected UTC properties. Test all ways of constructing a UTC time, rather than only one of them. Change-Id: I3f5828fc994e38d567e06edf96071188154de8bc Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Clean up tst_qqmlecmascript: don't leak on failureEdward Welbourne2021-05-111-1147/+933
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lots of tests were following the antipattern of deleting a pointer after the last QVERIFY() or QCOMPARE(), which leads to the pointer being leaked on failure. Use QScopedPointer consistently (it was already in use patchily). That changed one mis-use of QPointer (that was only checked for non-null immediately on creation, never referenced later, so being cleared on deletion wasn't relevant; and thus needed an overt delete, that QScopedPointer made redundant); but another appears to be deliberate, so documented that as such (to the best of my understanding, gc is meant to pick it up). This mostly arose with component.create() results, most of which were checked, albeit in inconsistent ways. Always check these before dereferencing, and use the same form for the check in all cases: use QScopedPointer's in-built cast-to-bool rather than !isNull(); and report the component.errorString(), using QVERIFY2(), on failure. In many cases the return from component.create() is passed through a qobject_cast<> before use; in principle, this could result in null even though create() returned a non-null pointer. Convert those to hold the return from create() in the QScopedPointer<> and cast its data() to get a plain pointer for subsequent use. Split assorted lines that got long (or longer) as a result. Removed a fatuous empty constructor. Change-Id: I88abba9e7ea72e30c92a11a5af5f17486f07f847 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Apply constant binding removal optimization to QProperty bindingsFabian Kosmale2021-05-101-0/+8
| | | | | | | | | | | | | | | | | | | This applies the logic from 7cb6dce1f3e140ea68d6b05281950f212fc99d38 to non-QQmlAbstractBinding bindings, too. The logic to detect whether a binding has no dependencies has consider the QPropertyBindingPrivate's dependency observer count. In addition, change the existing detection logic to remove properties without a context, too. The original logic probably wanted to guard against accessing binding->context()->unresolvedNames when context was nullptr; however, the check should have tested "context -> unresolvedNames", not "context and unresolvedNames". And after the refactoring which introduced hasUnresolvedNames() as a function, the context check became completely superfluous. Fixes: QTBUG-92996 Change-Id: Ia3bc39e184f431210b3bb2d38154acf820525e98 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QQmlPropertyBinding: Call RESET every time binding evaluates to undefinedFabian Kosmale2021-04-221-0/+36
| | | | | | | | | | | | To be in line with the behavior of the old bindings, we have to call reset, even when the binding was undefined before. Add a test which checks this behavior for both new and old types of properties. Amends d64e7c9c6cd172e426b9bb2c5e45fda5e6a5bfb2. Task-number: QTBUG-91001 Pick-to: 6.1 Change-Id: I1067a2fd56d5b7587281a9262e9bd389c825e587 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Adjust to QProperty using eager evaluationFabian Kosmale2021-04-191-2/+2
| | | | | | | | | | | | Besides API changes, we need to - adjust QQmlBind to unlink the binding properly (that probably was broken already before, but did not cause issues so far, as the old binding would not have been evaluated without a read access) and - skip tests in tst_qmlcompiler_manual, as the bindings are executed before the engine is correctly set. Change-Id: I97b0ac32b428c1a033664fe8593effadb69cd348 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Implement optional chainingMaximilian Goldstein2021-04-131-0/+87
| | | | | | | | | | | | | | | | | This change implements optional chaining (https://github.com/tc39/proposal-optional-chaining) by adding a new type of optional lookup with an offset to the end of a chain. If `undefined` or `null` is encountered during an access marked as optional, we jump to that end offset. Features: - Full support for all kinds of optional chain - With some codegen overhead but zero overhead during normal non-optional FieldMemberExpression resolution - Properly retains this contexts and does not need to resolve anything twice (this has been an issue previously) - No extra AST structures, just flags for existing ones [ChangeLog][QtQml] Added support for optional chaining (https://github.com/tc39/proposal-optional-chaining) Fixes: QTBUG-77926 Change-Id: I9a41cdc4ca272066c79c72b9b22206498a546843 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Adjust to QObjectCompatProperty API changesFabian Kosmale2021-04-081-3/+3
| | | | | | Change-Id: I600415cc7e472fb753e83fafbc89f074d13676d7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QV4QObjectWrapper: Store the whole signalFabian Kosmale2021-04-011-0/+8
| | | | | | | | | | | | | | | | | | | | | 90be89d771425044a84e9e79e4e668e065acc825 changed the connection logic to actually pass the receiver to connect in order to fix disconnect cleanup. However, we omitted to change QObjectSlotDispatcher::impl accordingly. The previous logic was: - store the index of the signal in signalIndex - In impl, in the call case, we would get passed the emitting object (sic!) as the receiver parameter. Then we would use the object and the signal index to obtain the QMetaMethod. - From the QMetaMethod, we could get the signal's number of parameters. After the aforementioned change, that does not work anymore: The receiver is now the actual receiver of the signal, thus we get the wrong method, and potentially the wrong number of parameters. To fix this, we now store the complete QMetaMethod of the signal. Pick-to: 6.1 Change-Id: I868c51edf24a61d14eaf958ed7942da27f54a5c3 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QV4::Engine::toVariant: Use metatype instead of metatype idFabian Kosmale2021-03-251-1/+1
| | | | | | | | | | This way, we can avoid the costly id to metatype lookup in case where we actually need the full metatype. Task-number: QTBUG-88766 Change-Id: Ibe29b323007f00d2f8d1807fb9b64f9a8f87e807 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Clean up JSCallData setupUlf Hermann2021-03-171-9/+9
| | | | | | | | | | | | | | | | | We either have pre-populated arguments and thisObject, then we can just use them and keep them const. Or, we want to allocate and populate the arguments and the thisObject. Then, do allocate them in a separate object, and transform that into JSCallData afterwards if necessary. Furthermore, avoid alloc(0) as that just returns the current stack top. Writing to it will clobber other data. Rather, just use nullptr and crash if it's written to. Also, remove the useless operator-> from JSCallData. That one just confuses the reader. Change-Id: I8310911fcfe005b05a07b78fcb3791d991a0c2ce Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQmlPropertyBinding: handle resetFabian Kosmale2021-03-151-0/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bindings are allowed to toggle between a defined state, and undefined which calls the property's reset function. Calls to the reset function must not remove the binding, even when they write to the property. To support this, we put the binding in a special undefined state, in which it is still active (and installed on the property), but does not actually provide its evaluated value to the property. Then, when the binding later becomes defined again, the binding leaves its undefined state and works normally again. Notes: - Calling the reset function during binding evaluation could have all kinds of unwelcome side-effects. We therefore have to suspend binding evaluation before the reset call (and restore that state afterwards). - QObjectCompatProperty expects that we write the current value into the propertyDataPtr. If we do not do this, it will overwrite the current value with the default constructed value of its property. Arguably, we should change the API so that we communicate that nothing has changed; but for now, we have to live with that limitation and read the current value and write it back again. - We currently do not handle the case correctly where a non-resettable property implemented via QObjectCompatProperty gets assigned undefined in a binding. Such a binding is likely unintentional (as the undefined assignment only creates a warning), and thus less of a priority. Nevertheless, a test marked with QEXPECT_FAIL is added for it. Fixes: QTBUG-91001 Change-Id: I7ecaa6c8dc1a1f1b33e67b1af65f552c4ca6ffb1 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* qv4generatorobject: Fix crash when creating new propertiesMaximilian Goldstein2021-03-081-0/+16
| | | | | | | | | | | | | | | | Previously HeapObject::GeneratorObject utilized a ValueArray member to store stack information. As we rely on all HeapObject members to have a constant size in order for QV4Table::inlinePropertyOffset to remain accurate, this lead to a memory conflict when a user defined his own property on the Generator. Please do not use ValueArray for any types that are user accessible or that you intend to add properties to. Now the stack information is stored into ArrayObjects instead which circumvents the issue. Fixes: QTBUG-91491 Pick-to: 5.15 6.0 6.1 Change-Id: Id6f638bf36a3ae3c9320ac99e67214c48dc81226 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* QML engine: Handle const QObject pointer correctlyFabian Kosmale2021-03-011-0/+32
| | | | | | | | | | | | | | | | | | | [ChangeLog][QML][Important Behavior Changes] If a QObject pointer is passed to the QML engine and subsequently frozen with Object.freeze, modifying its QObject properties now fails and throws a TypeError. The TypeError is thrown even in non-strict mode. [ChangeLog][QML] It is now possible to pass const QObject derived pointers to QML in properties, and to call Q_INVOKABLE functions which take such pointers as arguments. If the QML engine receives such a pointer, it is treated as if the object was frozen. Fixes: QTBUG-82354 Change-Id: Ib0dbcdfb2370654505936c3cf391d87dd2c9677b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
* Fix some "can be marked override" warningsAndreas Buhr2021-02-231-1/+1
| | | | | | Change-Id: I13da0d085901314950c4fa0afb5853e183652e67 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QV4QObjectWrapper: handle bindable propertiesFabian Kosmale2021-02-191-0/+19
| | | | | | | | | | | | | | | A function created by Qt.binding should lead to the binding being set (and replacing any previously existing binding). This was not the case for bindable properties so far. For those, we would have kept any existing C++ or QQmlPropertyBinding binding, and instead created a brand new QML binding which would have been set in addition. This patch also introduces a new class, QQmlPropertyBindingJSForBoundFunction, which is used to handle the case where the binding function is not a simple function, but has its parameters bound instead. Change-Id: Ia1417162b9822efb3f17ca4a6ecc02f959392927 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* tst_qqmlecmascript: Adjust to QObjectCompatProperty change in qtbaseFabian Kosmale2021-02-011-2/+2
| | | | | | | Fixes: QTBUG-90786 Change-Id: Id05afbeb18b7c30246a29b95673a1319649f389f Reviewed-by: Andreas Buhr <andreas.buhr@qt.io> Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
* V4: Store instruction pointer before CmpInUlf Hermann2021-01-271-0/+13
| | | | | | | | The "in" operator may throw an exception. Change-Id: I7d0b6e2212ac6ec237fbf14719349f8e23810028 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQmlPropertyBinding: improve error reportingFabian Kosmale2021-01-251-0/+75
| | | | | | | | | | | | | | | | | | This change ensures that bindings created in QML between new-style properties contain information about which property caused the loop. To do this, we store additional information about the property involved to retrieve its name and position at a later point. We print the warning in case we detect a binding loop in evaluate, and also set the error reporting callback correctly, so that the condition can be reported when the loop is detected in another part of the binding evaluation. In addition, we do not only set the QPropertyBinding's error member when JS evaluation results in an error, but also print the warning with qmlWarning. Fixes: QTBUG-87733 Change-Id: Idb25237d1f57355ca31189e6bf2a918430b3a810 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Use new QObjectPrivate connection mechanism in dynamic connectionsAndrei Golubev2021-01-211-0/+40
| | | | | | | | | | | Old API assumes sender == receiver, which results in wrong handling of connections when receiver is deleted: connection is not removed or notified elsehow as it's not really tied to a valid receiver Task-number: QTBUG-86368 Pick-to: 5.15 6.0 Change-Id: I0f3115f1b0f26cf353752ba2b8fd88e0f3bdd388 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QML engine: Fix writing function to property through aliasFabian Kosmale2021-01-181-0/+14
| | | | | | | | | | | | | | We special case writing functions to properties, only allowing assigning them to var properties and QJSValue properties. This would however break when aliases are involved. This commit fixes the issue by resolving the alias, and then checking and writing to the resolved property. Fixes: QTBUG-90373 Pick-to: 5.15 6.0 Change-Id: Ia09ebe92feeaf8359c99ff9aeadc676b9fcfaa07 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QML: Fix proxy iterationFabian Kosmale2020-12-171-0/+10
| | | | | | | | | | | If the target of a proxy was extensible, we did not set the iteratorTarget to its correct value, and thus the ForInIteratorObject would not be usable. Pick-to: 6.0 5.15 Fixes: QTBUG-86323 Change-Id: Id1924ac4087bab38c006b8eba92b619b79d36b7a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* tst_qqmlecmascript: Avoid memory leak on failureFabian Kosmale2020-12-031-3/+2
| | | | | | Pick-to: 6.0 Change-Id: Icf31fbe473e5b0659cfe09d5bef8652c22a2b1ce Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QML engine: Fix binding setupFabian Kosmale2020-12-031-0/+14
| | | | | | | | | | | We set QProperty bindings up in the wrong way: Parent components would overwrite their child component's binding. This patch reverses the order, fixing the bug. Task-number: QTBUG-87153 Pick-to: 6.0 Change-Id: I3e90d1d14a41a7c5c337745f1453484d360a3979 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix crash when calling hasOwnProperty() on proxy objectRichard Weickelt2020-11-241-1/+30
| | | | | | | | | | | Property pointer p needs to be checked for nullptr value in QV4::ProxyObject::virtualGetOwnProperty(). This can happen when calling hasOwnProperty() or propertyIsEnumerable(). Fixes: QTBUG-88786 Pick-to: 6.0 5.15 Change-Id: I43da58fed4d8656f9187213f7317f17398739e34 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QML: Rewrite Qt object in actual C++Ulf Hermann2020-11-091-18/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Quite obviously, the Qt object is a singleton, extended with a namespace, backed by a member of the JavaScript global object. Defining all the methods as JavaScript functions is unnecessary and duplicates the general type transformation code. Also, it makes it hard to use those same methods from a C++ context as we cannot properly set up the arguments outside the JS engine. Rewriting the Qt object reveals some deficiencies in the old implementation that we need to fix now: 1. The enums of the Qt type were listed as properties of the Qt object, which means you could iterate them with a for..in loop in in JavaScript. This is just wrong. Enums are not properties. This functionality is deleted and the test adapted to check for each enum value separately. The commit message for the change that introduced the iterability already mentioned that the author had failed to find any occurrence of this in the real world. 2. Parsing time objects from strings was done by parsing the string as a date/time and then picking the time from that. We still support that for now, but output a (categorized) warning. Parsing the time directly is preferred where possible. 3. Previously you could create (invalid) dates and times from various kinds of QML types, like int and color. This does not work anymore as we now validate the types before calling the functions. 4. Passing more arguments to a function than the function accepted was unconditionally ignored before. Now, a Q_CLASSINFO on the surrounding class can specify that the arguments should be checked, in which case a JavaScript error is thrown if too many arguments are passed. In order for this to work correctly we also have to ignore JS undefined values as trailing arguments for overload resolution. This way, if a method matching the defined arguments exists, it will be preferred over a method that matches the full argument count, but possibly cannot accept undefined as parameter. Consequently a number of error messages change, which is reflected in the qqmlqt test. [ChangeLog][QtQMl][Important Behavior Changes] You can not iterate the enumerations of the Qt object in JavaScript anymore. This does not work with any other enumeration type either. You can of course still access them by name, for example as Qt.LeftButton or similar. [ChangeLog][QtQMl][Important Behavior Changes] The time formatting functions of the Qt object in QML now allow you to pass an actual time string, rather than a date/time string as argument. Passing a date/time string results in a warning now. [ChangeLog][QtQml][Important Behavior Changes] Functions in the Qt object for formatting date and time will now throw a JavaScript error when presented with a value of an incompatible type, such as int or color. [ChangeLog][QtQml][Important Behavior Changes] The Qt.resolvedUrl() function now returns a URL rather than a string. This follows the documentation. [ChangeLog][QtQml][Important Behavior Changes] The GlobalColor enum of the Qt namespace is not exposed to QML anymore. It did not make any sense before as the enum values could not be used as colors. Change-Id: I7fc2f24377eb2fde8f63a1ffac5548d652de7b12 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* V4: Prevent heap objects from getting immediately swept by GCUlf Hermann2020-11-061-1/+4
| | | | | | | | | | | A destruction handler can cause a new object to be allocated during garbage collection. Depending on where in the heap the object ends up, it may be found during the sweep pass. As the mark pass had no chance to mark the object, we need to set the mark bit right at allocation time in this case. Change-Id: Ie43eeb548e78bd375b001b3a6bb4ef6596f91980 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QML engine: fix conversion scores for sequences in CallOverloadedFabian Kosmale2020-11-041-0/+14
| | | | | | | | | | | | A QV4Sequence can be converted back to its underlying container; we therefore should give the conversion of QV4Sequence to container a high score if metaTypeForSequence and the target metatype agree. This has a larger effect in Qt 6 than in Qt 5, as we now can have new sequence types for any (QMeta)Container. Fixes: QTBUG-87616 Change-Id: I2bf02ebadbf9b707719d09edaf14b112eb2caf4f Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix compiler warnings from testsVolker Hilsheimer2020-11-021-5/+5
| | | | | | | | Replace foreach with ranged for; don't name unused function parameters. Change-Id: If0d9138261567edb14b72791799c6da1b16b5a5b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: David Skoland <david.skoland@qt.io>
* Update tests to use new metaType systemDavid Skoland2020-11-021-22/+21
| | | | | | | | Change from the QVariant enum to the QMetaType enum and prefer typeId over userType where possible Change-Id: Ic89c55978d46cc23d23b8e9c82c475c0c220fae3 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QML: Make date parsing more lenientFabian Kosmale2020-10-291-0/+3
| | | | | | | | | | | This fixes a regression from Qt 5 to Qt 6, because QDateTime is now apparently more strict in its parsing of RFC2822Date. The string in the test-case is not valid according to that spec, but JS engines like V8 still accept it, and so did we in Qt 5. Fixes: QTBUG-87610 Change-Id: I2c6eb2087e4845b04fa0dc4f7aa9a229b3428a43 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix QProperty property interaction with aliasesFabian Kosmale2020-10-121-0/+37
| | | | | | | | | | | | | | | | With this change, an alias of a bindable property is also bindable, and shares its bindable interface with the target. Moreover, the logic in QQmlTypeCompiler is adjusted so that a change handler of an alias uses the bindable interface if possible, instead of connecting to the alias' change signal. That would never be emitted if the target is a QProperty without a notify signal. Alias properties still have a change signal, but those never get emitted. Change-Id: I857dfdbe51048a2b604ad632982e7f4adac6b907 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Handle QProperty inside bindingsFabian Kosmale2020-09-211-0/+12
| | | | | | | | | | | | | | | | | | | If we have a binding containing QProperties, and the binding target is an old style binding, still we have to trigger an update if any of the captured properties changes. We cannot reuse the QQmlJavaScriptExpressionGuards as those depend on Qt's signals, and a QProperty is not associated with a change signal in the general case. Therefore, we introduce a new list of QPropertyChangeHandler, which when triggered cause a reevaluation of the binding. As an optimization, we skip the whole capturing process for QQmlPropertyBinding, as that one already takes care of updating itself. Reverts 845bbb99a41a3e4f05c2b3d05d6db748c825dca0 (because skipping the capture is only possible when _both_ the bindee and the property in the binding are QProperty based.) Change-Id: Iafed2a41dcd708bcc33912ce810d803949379c63 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Fix additional warnings from usage of deprecated APIsVolker Hilsheimer2020-09-161-1/+1
| | | | | | | | | | Replace more QLibaryInfo::location with QLibraryInfo::path Replace old event accessors APIs, including relevant comments. Change-Id: Ie205fc93b6e1c0dfb3dca9100fbde417ab68fc9f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Adjust to qtbase changesFabian Kosmale2020-09-041-8/+9
| | | | | | | | | | | | | - isQProperty has been renamed to bindable - QNotifiedProperty is no more - Bindable properties have a function to obtain the QBindable; store that information in the qmltypes files. Task-number: QTBUG-86434 Task-number: QTBUG-86435 Change-Id: I2ba593af1e197d04d2c30cfb9e6904a3d2059e4b Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Unify "variant" and "var" properties in QMLFabian Kosmale2020-08-241-115/+1
| | | | | | | | | | | | | | | | | | | | variant and var properties differ in two important ways: - variant properties trigger "magic" string conversions: variant v1: "red" // contains a QColor var v2: "red" // contains a string - variant properties behave differently for value types: they create copies, instead of references. However, as variant properties were marked as obsolete and this behavior was effetively undocumented, it should be safe to give "variant" "var semantics". With this change, we can also avoid doing magic conversions when storing data in QVariant properties of QObjects/QGadgets Change-Id: I549b1beb98e6af9639c1ee81f316bda513d5ff65 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Do not set QQmlPropertyBinding until we reach finalizeFabian Kosmale2020-08-121-3/+15
| | | | | | | | | | | If we install the binding eagerly, context properties cannot be resolved yet, as the context object has not been created so far. This causes issues with a QNotifiedProperty using a callback which accesses the current value, and thus forcing the binding evaluation while the object creation is still ongoing. Change-Id: I3bf3def04cd044371cb757a1854a3224a9c669b8 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Give a better score for methods with a convertable type when matchingAndy Shaw2020-07-031-0/+14
| | | | | | | | | | | | When it is looking for a matching method based on the argument types, then if a QVariant can be converted to that type then it should give a better score for that method. This is so that it can see it as being more viable a choice when calling the method instead of potentially not being able to find a matching one. Pick-to: 5.15 Change-Id: Ief7e11feacd1d0b0959330af2576c2d01affbc54 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Add ; to Q_UNUSED and UNUSED_PARAMLars Schmertmann2020-06-261-1/+1
| | | | | | | | | This is required to remove the ; from the macro with Qt 6. Task-number: QTBUG-82978 Change-Id: Iead53d18fd790fb2d870d80ef2db79666f0d2392 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Drop special casing of QDateTime when setting valuesUlf Hermann2020-06-251-2/+2
| | | | | | | | | | | | | | | | | This introduced inconsistency in order to be compatible with V8 and Qt 5.0/5.1, respectively. We don't need to do this anymore. We standardize on the behavior observed when statically setting a property in QML, e.g. "foo: '2014-03-03'", rather than the behavior observed when dynamically setting it from JavaScript. [ChangeLog][Important Behavior Changes] Dates are interpreted the same way when assigned to QML properties as when parsed in JavaScript now. The time zone is generally left alone, not forced to UTC in some cases. Fixes: QTBUG-36635 Change-Id: I72a7045d7b39ee1c6e0ac1ef55d74ef8aa505f00 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QQmlPropertyBinding: convert to correct typeFabian Kosmale2020-06-251-1/+1
| | | | | Change-Id: I5b7b4d670c6308b33a2fd0580790934345bb3504 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* tst_qqmlecmascript: QList is now QList again (not QVector)Fabian Kosmale2020-06-231-1/+1
| | | | | Change-Id: Ib3b7437fcf3696111563cc1b5f9440b6b0d9c75e Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Do not resolve URLs when assigning them to a propertyUlf Hermann2020-06-221-6/+6
| | | | | | | | | | | | | | | We don't know in advance if a URL is part of the source code and should be relative to the current element, or if it is part of the application data and should not be touched. [ChangeLog][QtQml][Important Behavior Changes] URLs are not resolved or intercepted anymore when assigning them to a "url" property. Instead they are resolved and possibly intercepted when used to access an actual resource. Fixes: QTBUG-76879 Change-Id: Iaa2385aff2c13aa71a12e57385d9afb5dc60a073 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Adapt test to QMetaMethod changeFabian Kosmale2020-06-041-0/+1
| | | | | | | | | | With the new compile time type registration, the type is no longer unknown, causing the test to fail. Until we decide exactly how to deal with unknown types in QML, leave the test as is, but mark the failing comparison as an expected failure. Change-Id: Iaa23f096f686399b7199541b390655142fc40a37 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Implement URLSearchParamsMaximilian Goldstein2020-05-061-0/+59
| | | | | | | | | | Implements URLSearchParams (https://url.spec.whatwg.org/#urlsearchparams), completing our implementation of the URL object. Still needs the for..of iterator to get implemented. Change-Id: Iad33ed2f3fe0b2598ca2b0b21a4743f5f7dc19fd Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 13:37:32 +0000