QPair _is_ std::pair. If this wasn't a fake-definition under #ifdef
Q_QDOC, the compiler would have complained long ago.
Pick-to: 6.6 6.5
Change-Id: Idfe589ff13115d3d908572a17b849f634ec86787
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Which takes the array to be inverted by value, so we get free move
semantics and allowing us to perform the negation in-place.
[ChangeLog][Potentially Source-Incompatible Changes] The bitwise AND,
OR, XOR, and NOT operator functions on QBitArray are now hidden
friends. This may cause source-incompatibility in unusual coding styles
(like 'array.operator~()') or with classes that have a casting 'operator
QBitArray()'.
Change-Id: I85b3fc2dd45c4693be13fffd1795ba1fbaf23769
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This amends and corrects b63045477e. The
fix there was incorrect for two reasons:
1) it missed one symbol in QtCore (the QFutureInterfaceBase one
added in 0f0371c830.
2) it only worked for namespaces that were 15 characters long
Instead, just use a wildcard where the namespace should be for Qt
symbols (note: an extra wildcard appears for plain types because they go
from <N><type> to N<N><namespace><N><type>E).
Pick-to: 6.6
Change-Id: Iae41eb8991e349ceb836fffd179d6e709d6632f8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Provide qspan_p.h as backward-compatibility header.
[ChangeLog][QtCore][QSpan] New Qt equivalent of std::span.
Fixes: QTBUG-115022
Change-Id: I1cc27dc0aa1f7406f0a41d7a75f176cd7f858feb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qspan_p.h(35): error C2220: the following warning is treated as an error
qspan_p.h(35): warning C4245: 'initializing': conversion from 'int' to 'const size_t', signed/unsigned mismatch
Add an explicit (functional-style) cast to silence it.
Pick-to: 6.6
Change-Id: Id29fda3def1c60415b3e0fe72eaf82c8bc57d363
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The connection should be closed before executing
q_dbus_connection_unref(). Failing to do so results in an assertion
inside libdbus:
dbus[1573958]: The last reference on a connection was dropped
without closing the connection. This is a bug in an application.
See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call
dbus_connection_close(), since this is a private connection.
The q_dbus_bus_register() may fail if maximum number of active
connections for a bus was reached. This can be tested by creating
a custom bus with "max_completed_connections" parameter set to 0.
Add such a test to tst_qdbusconnection.
Fixes: QTBUG-34613
Change-Id: I6ae7df19bf8b6546c2a504931ba852dc15d35f78
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's required by the standard, see e.g. [1] and the eel.is links in
the code.
[ChangeLog][QtCore][QPartialOrdering] Added three-way comparison
operator (<=>) against literal zero, available when compiling in C++20
mode.
[1] https://en.cppreference.com/w/cpp/utility/compare/partial_ordering#Comparisons
Change-Id: I8a3b76661400930c6e247cf5b138ff52bf784395
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The misspelt flags (Less, etc) make it hard to use QPartialOrdering
interchangably with Qt or std ordering types, e.g. in generic code.
[ChangeLog][QtCore][QPartialOrdering] Added a set of lower-case flags
(::less, ::greater, etc) to improve source-compatibility with
{Qt,std}::partial_ordering.
Change-Id: I160600c01c4a2ab72c7b217a306d08045e363578
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Since QPartialOrdering is supposed to be a drop-in-replacement for
Qt::partial_ordering, it need to have the same conversions from
Qt::_ordering types that Qt::partial_ordering has.
Fix by adding the necessary conversion and relational operators and
conversion constructors.
Change-Id: Ib8e78c850b43c8bcb3bb15c5f7d25be9d0da7339
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The case statements I used when de-pessimising these functions were
pretty long, bumping against line-length limitations and annoying the
reader with overly long repetitive type names.
Add aliases to fix both issues, and also apply the form to
QPartialOrdering's operator std::partial_ordering for consistency.
I was kinda hoping that this would allow to DRY away some of the
repetition with macros, but it didn't work out in the end. It's still
a lot more pleasant to the eye, so don't let the experiment be for
nothing.
Amends 9c03935c9a.
Change-Id: I9786ae5c7be0b8fb30e4df219f1c65b2e8589904
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QPartialOrdering is suppsed to be a drop-in replacement for
std::partial_ordering, so it has to be convertible from all
std::_ordering types.
It was, however, only convertible from std::partial_ordering, and two
user-defined conversions in a row are not allowed.
Add the missing constructors. They, in turn, can then delegate to the
partial_ordering constructor.
Change-Id: I085d95677b258b4a61aabfd5468c1c43c2212766
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This makes sure that everything in-between will not accidentally come
to depend on QPartialOrdering. It also makes it much easier to
centralize the conversions to/from Qt::_ordering types in the
QPartialOrdering class, keeping the newfangled clases clean of legacy.
I should have done it this way to begin with... Mea culpa.
Amends 4b6f757020.
Change-Id: I269bdf0cbde59d317381ccd06001e56d5b3c289a
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
qCompareThreeWay() is a top-level wrapper around the helper
three-way comparison methods, which is mostly convenient for
generic client code.
When implementing compareThreeWay() for Qt types, we normally
provide the implementation only for (LeftType, RightType) pair,
but not the reversed one.
However, it is expected that qCompareThreeWay() would be available
for both combinations, because the reversed result can be easily
calculated.
Solve it by providing a helper hasCompareThreeWay<LT, RT> variable
and branching the implementation based on its value.
The noexcept check is inspired by the old implementation of qSwap().
[ChangeLog][QtCore] Added qCompareThreeWay() as a public API for
three-way comparison.
Task-number: QTBUG-104113
Change-Id: I6f24494d968c336f3dcdf620004b4190769cbdb2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
entryForSize() might return an entry with a scale != 1 (e.g. when
requesting the actual size for 32x32 it might return an entry with
size=16 and scale=2) but the returned size is not multiplied with this
scale so it returns a wrong size and in the case of QTBUG-114849 to a
wrong painting rect.
Pick-to: 6.6 6.5
Fixes: QTBUG-114849
Change-Id: I311e7401e61425efb20b37d13cc95c4b22d47e76
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Using the presence of the wayland-client lib as a condition.
Fixes: QTBUG-117386
Change-Id: If4336965ea06e3f4b06e9af661efdec38ba46136
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We only used it in one location and it's no longer needed.
Change-Id: I2092313b75d4510dda12f8f6decc9652f8191301
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
[ChangeLog][CMake] Added the DEPLOY_TOOL_OPTIONS argument to the
functions qt_generate_deploy_app_script and
qt_deploy_runtime_dependencies.
It doesn't make sense to map every option of the deployment tools to
arguments in our CMake deployment API. Allow the user to specify
extra arguments to windeployqt or macdeployqt.
Task-number: QTBUG-116551
Change-Id: I4cc67ab03f19101b695281e8c80f8af825bab7f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the inside-recursion marker to the
_qt_internal_collect_buildsystem_targets function and reset
the result variable only in the top-level function call.
Amends 1c82e92202
Pick-to: 6.5 6.6
Change-Id: I34b1e1edbb8a799900b95f67b80151b372073d2c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is a limitation of current implementation.
Task-number: QTBUG-92107
Change-Id: Idb1543f432348e66ca20aa67a2498034c2f05fa6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They are used when an icon is constructed via QIcon::fromTheme, unless
an application-defined theme provides the requested icon. Update the
documentation.
For now we don't provide a way to "opt out". This might change,
depending on the feedback during the Qt 6.7 beta phase.
[ChangeLog][QtGui][QIcon] Qt now has implementations of native icon
engines for macOS, iOS, Windows 10, Windows 11, and Android. These
engines provide access to the native icon libraries and fonts, mapping
standard icons to the corresponding native icon asset. Icons from
application-defined themes take precedence, but the last-resort fallback
icon passed as the second parameter into the
QIcon::fromTheme(QString, QIcon) overload is only used if the icon is
not available from the native library. See the QIcon documentation for
details.
Change-Id: I618e5c137c40f8e6309c0e4d4219a5a2759a475d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Those casts serve no useful purpose. Not having them results in
a slightly cleaner output.
Change-Id: If8ce1c680ce6f80a15534f9f4fe6d19d137f6443
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The _qt_internal_write_target_deploy_info function doesn't clear its
result variable, which is why we had left-over elements in the targets
variable. Some of these left-overs have a target type that's not
compatible with TARGET_RUNTIME_DLLS, leading to the CMake error:
Objects of target "lib1" referenced but is not one of the allowed
target types (EXECUTABLE, SHARED, MODULE).".
Fix this by clearing the targets variable initially.
Fixes: QTBUG-119792
Change-Id: I921aa2f0af72638ed0ed7434450a43c66c1fc9f1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Amends 7bc6f4ae8e.
Some refactoring caused a bug in the conversion from floating
point to the 16.16 fixed point values expected in Freetype. We
now need to do this conversion when passing the value to Freetype.
Task-number: QTBUG-117839
Change-Id: Iebec81adc26b27adf0661422a3f0534e6766d683
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use good old QString for the list of glyphs, and just render what we
get. The use case where we need to draw multiple symbols on top of
each other is (for now) academic, and we can support emojis just with
QString. Proof the latter point by mapping "banana" to the respective
emoji.
Change-Id: I8005a99f015e6eb2a2a635f9d892163f2008a673
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Structure the overview documentation a bit more around the different
ways to create a QIcon (from resources or theme). Replace the use of
QIcon::pixmap with a call to QIcon::paint in the example widget, and
tighten the High-DPI documentation a bit.
This does not add any mentioning of the upcoming "native icon library"
support.
Change-Id: I9cc7eab1fb5d134e5119660b534c2efdb0b03730
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add a list of constant string literals for a subset of icons from the
freedesktop specification. Those are icons we document to support today,
and that users might have written themes for.
Omit icons that are mime types (we have Q(Abstract)FileIconProvider
and QPlatformTheme::fileIcon for that), the "flag-aa" icon (where 'aa'
is an ISO 3166 country code, and Face* icons. Flags and Face icons can
be added as supported QIcon constants, but should then be rendered as
emojis from the respective font (they are not provided by any of the
native icon libraries or icon fonts).
We use string constants instead of an enum so that we have the same code
path for icon constants, user-defined icons, and native icons. I.e. in
addition to QIcon::fromTheme(QIcon::ThemeIcon::EditCopy), code can
request the icon for "trash.circle.fill" on Apple platforms, or
or for U"\ue5cd" on platforms where the engine is font-based; or an app
can define their own icon name and provide the assets through a theme-
description, as before.
The downside is that we cannot use arrays for looking up the native icon
for an enum-value in the engine implementations, but given that icons
are cached this is an acceptable trade-off.
To make the list of icon contants more manageable, have them in a
separate header file. Since we want those constants to live in the QIcon
"namespace", we then include that header in a declaration of a nested
struct, "ThemeIcon", resulting in e.g. QIcon::ThemeIcon::EditCopy.
Change-Id: Ic20e36ab321e6c4b20806ec0b400bba13fffc983
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If the QIconLoaderEngine (which respects theme and fallback theme) does
not provide the icon, then try the QIconEngine provided by the
QPlatformTheme implementation of createIconEngine. If that provides the
requested icon, then use it; otherwise keep using an QIconLoaderEngine.
Clean up the logic of that code a bit, while maintaining the invariant
that we need to return a valid QIconEngine pointer.
[ChangeLog][QtGui][QIcon] If neither theme nor fallback theme provide
the requested icon, we fall back to the QPA plugin implementation. On
platforms where an implementation exists, this will override the
explicitly provided fallback (second parameter to QIcon::fromTheme).
Change-Id: Idbf9ed049f5e975e1fbcdbb30dbdf6eac08e5827
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Running the test case leads to multiple calls to show the software
keyboard, which due to Android QPA implementation leads to the
keyboard being shown during subsequent test cases, leading to
random failures. Skip it temporarily on Android until the
Android QPA implementation is fixed.
Task-number: QTBUG-119574
Change-Id: I29f234fe08cb33358cb5cb0f8e51b1cc0f8e8906
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
grabWindow() currently returns a null QPixmap on Android due to even
raster windows being backed up by OpenGL/QRhi. The test case uses
grabWindow() internally to grab contents to a pixmap and comparing
whether the pixmap contents are as expected, leading now to failures
due to null QPixmap being returned.
Task-number: QTBUG-118849
Change-Id: I51cda2d43fe482252d5604f6b18281d810aa4d2f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Refactored platform windows on Android so that all window
types, including raster windows, have their own surface to
draw on.
Raster windows now flush the backing-store via RHI/OpenGL.
As a drive by, update to newer JNI syntax where appropriate.
Task-number: QTBUG-116187
Change-Id: I3b764b7126abf53556750b0ccbb7d27efe007bc1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If a QPA-provided engine provides an "edit-cut" icon, then it won't be
null. We cannot reliably test that the icon came from the fallback theme
as the cacheKey of the icon doesn't change (the proxying to a different
theme is handled internally by the QThemeIconEngine).
That the cacheKey of a QIcon doesn't change even if the pixmaps we get
from it change is not a problem in practice; QIcon is a named container
for transient graphical assets that might change for reasons outside of
Qt's control (such as color scheme, or display resolution).
Change-Id: I695e8ad0c8f0aec7f17a2c242e64b615178b78b5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The previous attempt to fix this bug did not work out well since it
tried too hard to avoid double calculations. Therefore restore the old
behavior and fix makeVisible() instead.
This amends 1082038bd8
Pick-to: 6.6 6.5
Fixes: QTBUG-119366
Change-Id: I738a3cd3537ecf0983480d2f961f45f81d101bd9
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When a type was explicitly made non-copyable and non-movable, refuse
attempts to mark it as relocatable.
Trivial relocatability is an optimization for move+destroy, so we
shouldn't allow working around the class author's wish to have a
non-movable type by a user making it Q_RELOCATABLE_TYPE.
Therefore, add a static_assert() to Q_DECLARE_TYPEINFO that fires
when a non-copy/move-constructible type is made Q_RELOCATABLE_TYPE.
Also add a similar static assertion to QTypeInfoMerger: All members
of a class T may be Q_RELOCATABLE_TYPE. But that doesn't mean that
T itself is:
class T {
QString m_s;
QByteArray m_b;
Q_DISABLE_COPY(T)
public:
~~~~
};
so check that T is actually copyable (or movable) when QTypeInfoMerger
would have have yielded isRelocatable.
Since Q_DECLARE_TYPEINFO and QTypeInfoMerger are not the only ways in
which a user can mark a type as relocatable (manual QTypeInfo
specialization is another option, and required, for certain template
classes), also check in q_uninitialized_relocate_n().
[ChangeLog][QtCore][QTypeInfo/QTypeInfoMerger] No longer allows
marking as Q_RELOCATABLE_TYPE a type that is neither movable nor
copyable.
Change-Id: If6b3e5c1bfb6538bd280262eefbb08ba3c810e4c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When 3535f46374 dropped the
Q_ASSERT(end[-1] == '"') by reviewer request from the original
767beb7fff change, it didn't replace it
with some other check, leaving the possibility open that we'd be
passing an invalid range (end < begin) to QString::fromUtf8(), with
unknown consequences.
While technically a security problem, this has very low impact, since
the files being parsed should contain "trusted content", being
supposed to be owned by root, and not writable by mere mortals. I
hasten to add, though, that the code doesn't check permissions of the
files it reads.
The bug existed with the original Q_ASSERT, too. Namely in release
mode. And in debug mode, it would be a DOS.
Port to QByteArrayView to get the more expressive API and as a
prerequestite for follow-up (non-security) patches.
Pick-to: 6.6 6.5
Change-Id: Ib79cdad8680861d1f11b6be9234695273d0a97c2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QVarLengthArray is the only Qt container currently known to be fine.
std::vector is supposed to be fine, too, since C++14. Turns out that
libstdc++ gets resize(n, v) wrong, though, because it never
implemented the resolution to wg21.link/lwg2033. Known issue, linked
in code comment. Worked around for the time being. Keeping std::vector
in, though, because in this test suite we do cross-check with
std::vector, and other platforms, and most of GCC's std::vector
functions, adhere to the standard.
Pick-to: 6.6 6.5
Change-Id: I26e11c4a100695c604cebcf7e14a1ae5078d9ec7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The (internal) docs say that - and _ are ignored, and they're ignored
everywhere, except as suffixes. If the old code only ignored them as
infixes, fine, that would make some sense, but it ignored infixes and
prefixes, so there's no reason for it to not ignore suffixes, too.
Fix by continuing the loop until both input ranges are exhausted, or a
mismatch was found.
[ChangeLog][QtCore][QStringConverter] Fixed a bug where
encodingForName() failed due to trailing characters (`_`, `-`) that
ought to have been ignored.
Pick-to: 6.6 6.5
Change-Id: Iec21489d988eda7d33c744c170f88cd665b73f34
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
There's no restriction on the number of enable_if's in a
template-initializer, so simplify the compareThreeWay() constraints by
having separate constraints each for LeftType and RightType. Fewer
templates to instantiate = faster compile speed.
As a drive-by, drop remove_reference_t. We control all users and all of
them pass already-decayed types.
Change-Id: I17c01c7aa1ac03bb6db4b0bef1371ebc0641641d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Provide a custom variable template to detect float types and
specialize it for QtPrivate::NativeFloat16Type.
This will allow to enable three-way comparison for qfloat16.
Task-number: QTBUG-104113
Change-Id: Id12c42c86f8dc9e233fe39776b0f0e28088de9e1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
... and put it into QtPrivate namespace as NativeFloat16Type.
Keep the qfloat16::NativeFloat definition for SC.
This is in preparation of Qt::compareThreeWay() for NativeFloat16Type
(where available and mis-classified as non-is_floating_point).
Amends 99c7f0419e.
Pick-to: 6.6 6.5
Task-number: QTBUG-104113
Change-Id: Ie12c42c86f8dc9e233fe39776b0f0e28088de9e2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
We accepted QSpan as a NIH-type instead of waiting for C++20 and
std::span, because we said that there's no impedance mismatch between
the two, as they both implicitly convert into each other.
But we actually never checked that they do.
Fix this omission by adding constructors that treat std::span exactly
the same as QSpan itself, and adding the respective static_assert()s
to tst_QSpan to check that (within the constraints imposed by the
standard on std::span), they actually do convert into each other.
The only two problematic cases are that fixed-size std::span
constructors are explicit, so span is only constructible, not
convertible, from QSpan. Likewise, for an rvalue QSpan to be
acceptable to the std::span constructor, QSpan needs to opt-in to
enable_borrowed_range (while we're at it, do enable_view, too).
We so far have rejected adding these opt-ins for our own container
classes because we wanted to avoid the compile-time overhead of
including the huge <ranges> header into such central headers as those
that define our containers.
But std::span itself has to specialize these traits, and its range
contructor has to use them, so they must be available from <span>,
too, possibly the stdlib puts the definition into a much smaller
header. So just assume we can specialize it after including just
<span>, provided __cpp_lib_concepts is also defined.
Pick-to: 6.6
Change-Id: I2202869b60c98047256b0fbcb12336f5d8e550ba
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
My notes inform me that my intent was for QSpan::extent to be size_t,
for compatibility with both its template argument and
std::span::extent.
So fix it to be size_t instead of qsizetype. While extents that go
beyond numeric_limits<qsizetype>::max() will be unusable in practice,
QSpan doesn't actually allocate memory, so declaring one should be
possible, if only for compatibility with std::span, without getting
into a situation where E != extent.
Pick-to: 6.6
Change-Id: Ic8ae3a1c03801b4a23b7ba56388372cac64f9e5e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The docs at cppreference.com hint at a corresponding ctor being added
for C++26 (though I don't see it in eel.is/c++draft, yet).
Even so, replacing former initializer_list functions with QSpan ones
is definitely one of the upcoming use-cases, so test it.
Can't use from_container_impl() here as initializer_list<T> is already
immutable, so QSpan<int> is not compatible, only QSpan<const int>.
Pick-to: 6.6
Change-Id: Iecdf29e629d48313edd5e56d358b9137da76deb6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Hide the base class; the documentation isn't supposed to show this
implementation detail.
Don't use auto return types for the begin/end family of member
functions; QDoc doesn't resolve them, but just shows auto, which,
without seeing the implementation, is pretty useless.
Pick-to: 6.6
Change-Id: If75cc1e7de9c5c1490cb37241739449df4e5d0c2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Marc Mutz
Thiago Macieira
Ievgenii Meshcheriakov
Ivan Solovev
Christian Ehrlicher
Rym Bouabid
David Redondo
Mårten Nordheim
Joerg Bornemann
Alexey Edelev
Volker Hilsheimer
Eskil Abrahamsen Blomfeldt
Tasuku Suzuki
Tinja Paavoseppä