We can access the same QObject in const and non-const contexts. Both
should be possible. Store the const objectwrapper in
m_multiplyWrappedObjects. That's somewhat slow, but const QObjects are
rather rare.
Pick-to: 6.4
Fixes: QTBUG-98479
Change-Id: I047afc121f5c29b955cd833e0a2c8299fc52b021
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously we've assumed the whole allocation can be used, even though
the first and the last page are actually not usable. This makes a
difference when the size of the guard pages grows, such as on macOS,
which these days has 16k pages.
Add the extra guard page size to the amount of memory to be allocated in
order to fix the calculation.
Pick-to: 6.4 6.3 6.2 5.15
Fixes: QTBUG-93188
Change-Id: I0ebece94449da3127e9a78a19d8a22722ad8d698
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When we use an attached object as an argument to a function call, we
need to properly extract it from the QmlTypeWrapper. Before this change,
we simpley left the argument pointer as null, which lead to subsequent
crashes when it got dereferenced.
Moreover, treat passing namespaces to functions expecting a QObject as a
TypeError, by returning false from CallArgument::fromValue (used to
crash for the same reason as with the attached object case).
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-106119
Change-Id: Ifa6a32e20a29935aff1f265eb0edd3e35ea1c11b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is basically the same as QTBUG-105204, only with the QML engine
being involved.
Fixes: QTBUG-104982
Pick-to: 6.4 6.3 6.2
Change-Id: I5afaadedcd7af41198702a8f2331703b4f6ef2e7
Reviewed-by: Sami Shalayel <sami.shalayel@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We need to preserve them as they notify us about protoId related
changes. In order to avoid wasting heap space in case many properties
are added and removed from the same object, we put a mechanism in place
to rebuild the InternalClass hierarchy if many redundant transitions are
detected.
Amends commit 69d76d59ce.
Pick-to: 5.15 6.2 6.3 6.4
Fixes: QTBUG-91687
Task-number: QTBUG-58559
Change-Id: I3238931b5919ed2b98059e0b7f928334284ce7bf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We need to properly convert value type lists on assignment and we need
to add the "length" property to the own properties. Furthermore, the V4
sequence methods were confused about integer type ranges. We teach
them about qsizetype, properly range check everything, and drop the
artificial limitation to INT_MAX.
Pick-to: 6.4
Task-number: QTBUG-82443
Change-Id: Ie5af1130c9e78e412c171e6fa26a28a6a7a5d498
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This change adds a colon after scheme in methods 'setProtocol' and
'setUrl' on its protocol line. Likewise, this includes a test called
'colonAfterProtocol' to check if colons were correctly added by using
different schemes: ftp, http and https, or if colons were removed when
setting the scheme (i.e. from protocol 'ftp:', 'ftp:http:' or 'ftp:::'
to 'ftp').
Fixes: QTBUG-103746
Change-Id: I8f847bedd23e476e0ae7901a2f3f3963da3ca04d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If an overload set contains a function with a QUrl parameter, and we
pass in a string, that would have resulted in the worst-possible score
of 10 for that function.
Given that URLs are often provided as strings in QML for convenience
(instead of using e.g. Qt.url), that is arguably a bad idea.
Starting from this commit, they'll get a score of 6: QJsonValue still
wins (to minimize the risk of breaking existing overload sets), but we
no longer claim that there is no match at all for such a parameter.
Change-Id: Ic0faa0029c9d5f14aff143cbd7fd4859d9ac2b2a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I72c89a98c42bbc9234d8495e9e503bec81d11037
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Instead of a bool we can just return an enum of the actual kind. This
way all the checks become more readable. Furthermore, we can eliminate a
dynamic_cast without sacrificing readability.
Change-Id: I8a38687f9b796cd47196a6ab0385624c737e4435
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Internally they've been called "value types" all along. Now that we are
adding the ability to define your own value types the "basic" name is
not really fitting anymore. Value types can be quite complex.
Change-Id: I5fb4abec1dd2f0bbf7fb7f08b02db0882490e983
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Autotests in Qt are usually GPL3, or BSD. No point in using the LGPL
here.
This also gets rid of last references to LICENSE.LGPLv3 in this
repository, so we can delete both LICENSE.LGPLv3 and LICENSE.GPLv3,
which it references.
Change-Id: Idbdefe0c68cc8047ede72b439a4d7ff40dfd71b6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QQmlEnumTypeResolver constains logic to find enumerations in bindings
and turn those bindings into simple integer bindings. However, that
logic got confused when we had a complex expression (as in, not only an
identifier but any compound expression).
Instead of trying to create a mini-expression parser, we opt to be more
conservative in the analysis and reject anything that does not look like
one or more identifiers separated by dots.
The use case of optimizing simple arithmetic operations involving enums
in bindings is left to qmlsc.
Pick-to: 6.2
Fixes: QTBUG-98311
Change-Id: I6f8c3fa2a2712dabdea035e2447d52c415ebfc3f
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
If an inner function contains a yield expression, we need to reject the
program even if that function is inside of a generator function.
Fixes: QTBUG-98356
Pick-to: 6.2 5.15
Change-Id: I2e820a1ca5f0da4080e313fd9809aa8bfdc1b681
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Top level functions, that is, those directly defined in a QML component
as opposed to those defined inside another function or class, are not
visited directly by the ScanFunction visitor. Instead, they are manually
considered in generateJSCodeForFunctionsAndBindings, and the visitor is
then run on their body.
This worked mostly fine, with one notable exception: In case there is a
function expression used as the default value of a function parameter,
that function would have never been visited. This would lead to
subsequent asserts/crashes in the codegen, as the function was not
properly set up.
We fix this by manually visiting the function's formals in addition to
the body.
Pick-to: 6.2 5.15
Fixes: QTBUG-98032
Change-Id: I5cb4caae39ab45f01a0dfa1555099d7d4b796a19
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If given, all properties but the ones mentioned in
ImmediatePropertyNames are deferred. Also add some warnings related to
DeferredPropertyNames being ignored in some cases. Finally, scanObject()
can return false now. Therefore adapt its caller to take that into
account.
Task-number: QTBUG-95117
Change-Id: I1e696228de7ad3b495bf7791fdb014768aff4c96
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
QQmlV4Function should be used as the last fallback if there are other
options available. Also, take QVariantMap into account.
Change-Id: I9ebf39f4f860cf3bf44c6cbc80efbac7ea30c70b
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
For QProperty bindings, we would not explicitly remove bindings that were
added and later overwritten.
For "complex" bindings, that would cause some unnecessary binding
evaluation during object creation.
Worse, in the case of a literal binding overwriting a complex binding,
we would acutally end up with the complex binding still being there,
because the literal binding would result in an immediate write of the
value, whereas the binding was only installed at a later point.
We fix this by removing the binding from the list of to-be-installed
bindings when it gets overwritten.
We also now take the IsPropertyObserver flag into consideration when
checking whether existing bindings should be removed: IsPropertyObserver
is basically the same as IsSignalHandlerExpression, but for QProperty
bindings instead of "old-style" bindings.
Pick-to: 6.2
Fixes: QTBUG-96668
Change-Id: I2ef00d5b62af4f6fcc71960c38e1f0568b3b9c40
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Function declarations add their name to the outer scope, but not the
inner scope. Function expressions add their name to the inner scope,
unless the name is actually picked from the outer scope rather than
given after the function token.
We don't add the name to any scope in the case of functions declared in
QML elements because the QML element will receive the function as
appropriately named, and typed, property. It is always better to use
that one than to use a JavaScript local.
This causes some additional ecmascript tests to pass.
Pick-to: 6.2
Fixes: QTBUG-96625
Change-Id: I0b8ee98917d102a99fb6b9bd918037c71867a4a5
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Previously each test would include and build sources from the shared
folder. Now we make those sources a library, build it once, then have
each test link to it instead.
We also take the opportunity to move some helpers that qtquickcontrols2
had added into the quicktestutils library where it makes sense, and
for the helpers that don't make sense to be there, move them into
quickcontrolstestutils.
We add the libraries to src/ so that they are internal modules built as
part of Qt, rather than tests. That way we can use them in a standalone
test outside of qtdeclarative.
Task-number: QTBUG-95621
Pick-to: 6.2
Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It is arguably a bad idea to defer properties which might get defined in
child classes, but checking it in the engine would be expensive: We
cannot simply check that the property exist, as we might want to defer
attached properties.
So for now, we add a test to document and verify the behavior.
Change-Id: I264b136638c4ecddfa52b6687797cb981d9b531e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This test is meant to narrow down the semantics of the currently
underspecified deferred properties.
Task-number: QTBUG-95117
Change-Id: Iee6b9d4caea1a248cf5c2d6773e12a314c01bae7
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It's content was incorporated into CMakeLists configuration, so it no
longer makes sense to keep dead file around.
Change-Id: Id85ce8d14c8862a59af1475e67666a3debc660e7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
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>
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>
It is shorter and encapsulates the exception handling a bit.
Change-Id: I8e2dc0eb3b930e222b8cb4852b73d99ca18a0379
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
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>
End statements in JavsScript functions with semicolon, slightly
improve the naming of some variables, only use as many parentheses as
actually grant us some benefit.
Change-Id: Ib2c68a84366bf74b9bc2ab8145603170dc559ad4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The .pro files corresponding to the .prev_CMakeLists.txt files
have already been removed.
Change-Id: I254eafe4c7de1a516e33bd9cb3d9879e73fa83b4
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
I needed it while debugging QDate <-> Date conversions, so we might as
well keep the more informative form of it to make life easier for
anyone else doing similar.
Change-Id: I99057535f2f3b2783997102cc7db98290e40c220
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The test-cases I added for QTBUG-78996 tested the root cause of the
bug, but neglected to test the symptom actually reported - the day of
the week was wrong. Add actual an day-of-week check to each (and
semicolons on the ends of statements).
This amends commit 290dc2da70.
Task-number: QTBUG-78996
Change-Id: Ic7064ddd5a8e4fa0806a10d73cd5955c7be4a4bc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
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>
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>
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>
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>
This applies the logic from 7cb6dce1f3 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>
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 d64e7c9c6c.
Task-number: QTBUG-91001
Pick-to: 6.1
Change-Id: I1067a2fd56d5b7587281a9262e9bd389c825e587
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
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>
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>
90be89d771 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>