Making properties FINAL is an API break not covered by any QUIP rule.
However, this does not apply to the attached and uncreatable types
(either explicitly, or because they are singletons or value types) whose
properties were marked FINAL in the referenced commit, as it is not
possible to derive from them anyway. So those are left with their
properties still marked as final.

This partially reverts commit 351979e05ad2a861fc3e6f8d1de6197a751316a8.

Pick-to: 6.6 6.7
Change-Id: I1ce8c0873c4600ec2aad8e078c379239ad03f74a
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>

Task-number: QTBUG-117983
Change-Id: Ia904c9390efb13b92de2e16fa0690e48394f9bab
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>

They are generally not useful for anything.

Change-Id: I12e959ce9338e6eb7465633496c7921fa09a3fe8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

Without setting the FINAL flag, properties can be shadowed by users.
In the following example:

Image {
  property string source: "Shadowing QQuickImage::source"
}

The source property of QQuickImage, will be shadowed by a new property
with the same name.

This can both cause confusion for non-experienced users, and it causes
issues with qmlsc.

Shadowing a property is usually unwanted. But there are some situations
where it might be intended. The QML Object Attributes doc page
demonstrates that you can override the color property in
QQuickRectangle, for instance.

[ChangeLog][Important Behavior Changes][QtQuick] Most properties for
types in the QtQuick module are now FINAL, meaning that they can no
longer be shadowed by declaring new properties with the same names.
With few exceptions. A warning will be printed out to the console, when
a FINAL property is shadowed. We recommend that users rename those
properties to avoid potential unexpected behavior changes.

Task-number: QTBUG-108739
Pick-to: 6.6
Change-Id: I1070926606f4d88ef7edf088ff80fb3ec82305c8
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>

Replaced in most common patterns.

Change-Id: Idcaff1f2e915f29922702d3600a2e5f1e2418a7a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>

acceptProposedAction is simply a plain function taking no arguments.
accept has exactly two overloads, one taking no arguments, and one
taking a Qt::DropAction. We can thus replace the V4Function there with
an explicit overload set.

Change-Id: I587c80fed40a18e1b827fd3f757e1af2436c1e7c
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

With QQmlV4Function we have no information at compile time about what
a arguments a function expects, and what it returns. Considering that
getDataAsString does not actually have an overload set, but simply
expects and returns a string, we can change to QString types. For
non-QString parameters, the engine will then transparently take care of
converting them.
The same applies to getDataAsArrayBuffer and QByteArray/ArrayBuffer.

Change-Id: I007796c3c01a6f021babd0dff2832506c7c63c30
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>

It is a documented type, and naming signal parameter types allows easier
composition of QML types:

// MyCustomDropArea.qml
Item {
  id: root
  signal dropped(event: DragEvent) // with named type
  // signal dropped(event: QtObject) without we could only use QtObject
  DropArea { onDropped: (ev) => root.dropped(ev) }
}

Pick-to: 6.2
Change-Id: I751fec7356b5f1bb58e61e4f8de72c9b8d9d5c60
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>

The semi-private headers of QML-exposed types should follow our
conventions regarding include formatting.

Change-Id: I224603d37ea5debcfad258b1e14907b40328c8f6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>