Conflicts:
examples/opengl/doc/src/cube.qdoc
src/corelib/global/qlibraryinfo.cpp
src/corelib/text/qbytearray_p.h
src/corelib/text/qlocale_data_p.h
src/corelib/time/qhijricalendar_data_p.h
src/corelib/time/qjalalicalendar_data_p.h
src/corelib/time/qromancalendar_data_p.h
src/network/ssl/qsslcertificate.h
src/widgets/doc/src/graphicsview.qdoc
src/widgets/widgets/qcombobox.cpp
src/widgets/widgets/qcombobox.h
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro
tests/manual/diaglib/debugproxystyle.cpp
tests/manual/diaglib/qwidgetdump.cpp
tests/manual/diaglib/qwindowdump.cpp
tests/manual/diaglib/textdump.cpp
util/locale_database/cldr2qlocalexml.py
util/locale_database/qlocalexml.py
util/locale_database/qlocalexml2cpp.py
Resolution of util/locale_database/ are based on:
https://codereview.qt-project.org/c/qt/qtbase/+/294250
and src/corelib/{text,time}/*_data_p.h were then regenerated by
running those scripts.
Updated CMakeLists.txt in each of
tests/auto/corelib/serialization/qcborstreamreader/
tests/auto/corelib/serialization/qcborvalue/
tests/auto/gui/kernel/
and generated new ones in each of
tests/auto/gui/kernel/qaddpostroutine/
tests/auto/gui/kernel/qhighdpiscaling/
tests/libfuzzer/corelib/text/qregularexpression/optimize/
tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/
tests/libfuzzer/gui/text/qtextdocument/sethtml/
tests/libfuzzer/gui/text/qtextdocument/setmarkdown/
tests/libfuzzer/gui/text/qtextlayout/beginlayout/
by running util/cmake/pro2cmake.py on their changed .pro files.
Changed target name in
tests/auto/gui/kernel/qaction/qaction.pro
tests/auto/gui/kernel/qaction/qactiongroup.pro
tests/auto/gui/kernel/qshortcut/qshortcut.pro
to ensure unique target names for CMake
Changed tst_QComboBox::currentIndex to not test the
currentIndexChanged(QString), as that one does not exist in Qt 6
anymore.
Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
This leads to "make benchmark" actually running the benchmark, which
would be nice, I think. Purged various CONFIG += release or -= debug
lines from the same configurations; those surely only configure how
the test code is compiled, which is more or less pointless; it's the
code under test whose debug/release state matters, and I don't suppose
that's affected by the build config of the test code.
In the process, reduce diversity of the ordering of lines within these
*.pro files and purge some dangling space.
Change-Id: Ia9f9f0ca4c096262de928806bdfa6ea3b9e7b9ba
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Constantly re-reading the timezone information only to be told the exact
same thing is wildly expensive, which can hurt in operations that cause
a lot of QTimeZone creation, for example, V4's DateObject - which
creates them a lot (in DaylightSavingTA).
This performance problem was identified when I noticed that a
QDateTime binding updated once per frame was causing >100% CPU usage
(on a desktop!) thanks to a QtQuickControls 1 Calendar (which has a
number of bindings to the date's properties like getMonth() and so
on).
The newly added tst_QTimeZone::systemTimeZone benchmark gets a ~90%
decrease in instruction count:
--- before
+++ after
PASS : tst_QTimeZone::systemTimeZone()
RESULT : tst_QTimeZone::systemTimeZone():
- 0.024 msecs per iteration (total: 51, iterations: 2048)
+ 0.0036 msecs per iteration (total: 59, iterations: 16384)
Also impacted (over in QDateTime) is
tst_QDateTime::setMSecsSinceEpochTz(). The results here are - on the
surface - less impressive (~0.17% drop), however, it isn't even
creating QTimeZone on a hot path to begin with, so a large drop would
have been a surprise.
Added several further benchmarks to cover non-system zones and
traverse transitions.
Done-With: Edward Welbourne <edward.welbourne@qt.io>
Task-number: QTBUG-75585
Change-Id: I044a84fc2d3a2dc965f63cd3a3299fc509750bf7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Test more methods.
Document what the existing test covers.
Use the right #include for QDate.
Change-Id: I051542c244e5bc381aafa3ae38144e246919db7a
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Aside from the start-date and the end-date, and a variant with a
time-zone, the lists various tests were building were all built the
same way; so pack that up as a pair of functions (one without
time-zone, one with) to save duplication. Make the list in each
function const, ready for conversion of foreach loops to ranged for.
In the process, replace QList with QVector, reserve space before we
populate and use auto for the now-const list variables it's saved in.
Change-Id: I7d8cce459a4d6111cd645e8d3966ad769ab7e201
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Multiplying a Julian Day number by the number of milliseconds per day
does not get you a time since the start of 1970; it gets you a time
since the start of the Julian Day number system, which was several
millennia earlier.
Change-Id: Ic90a6c3de445baf9cfd30f28dd847f146e6a7adf
Reviewed-by: David Faure <david.faure@kdab.com>
We'll be adding calendar code here as well, and tools/ was getting
rather crowded, so it looks like time to move out a reasonably
coherent sub-bundle of it all.
Change-Id: I7e8030f38c31aa307f519dd918a43fc44baa6aa1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
