Instead of copying a list, sorting it just to check it's sorted, and
making a QSet out of it just to check the size is the same as that of
the list (thereby checking there were no duplicates), simply apply
adjacent_find with greater_equal. If none of the elements is ≥ their
successor, that means all elements are < their successor, and _that_
means the range is sorted and has no duplicates. q.e.d.
Pick-to: 6.6 6.5
Change-Id: Id73c674ad4e29117370e8fc6af9fdfc690a3fba9
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The density of Q_FOREACH uses isn't very high here, but at this time,
this author just goes through the code-base and white-lists TUs that
still use Q_FOREACH in order to globally enable QT_NO_FOREACH.
Mark the whole plugin with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TU by #undef'ing QT_NO_FOREACH
locally, at the top of each file. Since the TU is part of a larger
executable, this requires the file to be compiled separately, so add
it to NO_PCH_SOURCES (which implies NO_UNITY_BUILD_SOURCES, too).
Task-number: QTBUG-115839
Change-Id: If731d02f65131c94afa8beb51679ed2ff7d2cdaa
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
As a header, it would otherwise make all TUs that include it (with
PCH: all) incompatible with QT_NO_FOREACH.
Without deeper analysis (which economy of time forbids in this case,
given this is just a manual test that's probably run 10 times per
year), and seeing as this is in an event handler, I opted to play it
safe and iterate over a copy (which is exactly what Q_FOREACH
does). Added a comment to indicate it may not be needed.
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I7db75321dd34888f6dd7a64cccb7462ff35935fa
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
First include the common tst_qmimedatabase.cpp (and nothing else),
then implement the differing
tst_QMimeDatabase::initTestCaseInternal().
This will allow adding #undef QT_NO_FOREACH to tst_qmimedatabase.cpp
in the next step.
Pick-to: 6.6 6.5
Change-Id: Icc1890229e9443bd35c81d4f0440ba7df5da906c
Reviewed-by: David Faure <david.faure@kdab.com>
The single Q_FOREACH use here is simple, as it's over a local variable
that just isn't marked as const due to the way it's constructed, and
the loop body clearly doesn't modify the container, so the protective
copy that Q_FOREACH performs is not needed. But std::as_const() is, to
prevent a detach() (attempt). Add that.
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: If228f649efd87388f6e312078b24a5b46ac8dc36
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: David Faure <david.faure@kdab.com>
Drag the QCOMPARE (which even dynamically allocated a QString
fromLatin1()) out of the QBENCHMARK loop. Testing performance of
QString::fromLatin1() and/or qCompare() is not pertinent to the task
at hand, which, ideally, doesn't involve any memory allocations, so
there's at least the chance that this skewed the result noticably.
Didn't run the benchmark as this was developed on an asan build.
Yes, this breaks comparability with the stone-age measurements
reported in comments there, so sue me.
As a drive-by, replace the fromLatin1() with a u_s UDL.
Pick-to: 6.6 6.5
Change-Id: I9b2a8b2e3596ec9b07c6b4ea369257b1a86e09db
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: David Faure <david.faure@kdab.com>
QDate's constructor can see maxJd() and minJd() without namespace prefix.
QDateTimeParser::SectionNode's name() inherits visibility from
QDateTimeParser of its Section enum's members.
Change-Id: I6315c4ede8875ef725d5b778eebac1e2027cd8b1
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The code of a class doesn't need that class's prefix to access members
of the class.
Change-Id: I4cc2f72c90cff48b331dc12d390c45c0639606b3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Simplifies the code at the call site.
Even though QDebug has support for streaming std::list (SpanList), the
format of the output would be different than what's already used here,
hence the custom operator<<().
Drive-by, port from Q_FOREACH to ranged-for
Task-number: QTBUG-115803
Change-Id: I30953c92e0c9febc01497c1117fa472b4718820e
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Now that the "and" is only seen in enumdata.py and comments, we can
s/And/and/ in all the various territory names that used it.
Change-Id: Ic376d5904b6f5ab54931f96230c1dd5b7f357b8d
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Various comments need to continue using the enumdata.py names, as they
associate data with particular enum members, but we can now correctly
use the en.xml versions of their names when we report them, rather
than the enum-friendly names we use in the code. Since this now means
the data may stray outside plain ASCII - it'll be UTF-8-encoded - this
implies replacing the QLatin1StringView()s of the code that formerly
read this data with QString::fromUtf8().
Fixes: QTBUG-94460
Change-Id: Id3b08875a46af58c0555c3e303b0e15a19441509
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We could already use dashes in some, rather than spaces, and now no
longer need to capitalize each word. This changes the *_name_list[]
entries for affected languages to more closely match what CLDR gives
as their names. It also amends various comments. Added tests for the
QLocale::*ToString() functions to cover the entries changed.
Task-number: QTBUG-94460
Change-Id: I0163795cb282881f15a97be00a5311c1936c3a09
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test names and output need to be UTF-8 for the XML data formats to not
end up malformed - which would upset Coin's testrunner, when it
validates the XML as part of checking - and the few other uses of
toLatin1() were to ASCII content anyway, so can harmlessly (this being
test code, where the slight performance advantage of Latin-1 doesn't
matter) use toUtf8() as well, for the sake of uniformity.
Use of toLatin1() broke an imminent commit in which some territory,
script and language names depart from ASCII, leading to malformed
UTF-8 when they appear in test-data-row names.
Task-number: QTBUG-94460
Change-Id: Ifb826b1e417ba24fd862b93d24d0e7a38858a17f
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The former needed the latter's .dupes to do the job, so can now just
take a method as a tool to do the job instead, letting .dupes become
private. In the process refine the munging to free enumdata.py from
having to capitalize each word in its names. This will, in due course,
let us use more natural forms in various comments. This causes no
change to generted data.
Update enumdata.py's introduction doc, mainly to reflect this but also
fixing the out-of-date names (old *_list have long been *_map) and
adding some details to other paragraphs.
Task-number: QTBUG-94460
Change-Id: If195b2e94a53a495fc4f1f216bed07a910439fa7
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Moving it makes it easier to document what it's up to and why, while
leaving __checkEnum() easier to read; and I'm going to need it
elsewhere anyway. This makes no difference to generated data.
Task-number: QTBUG-94460
Change-Id: I684375bc926d5d54928fbf5b5e08978528aef487
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Currently QT_USE_QSTRINGBUILDER is added for all Qt module targets by
default, and it's not possible to remove this definition.
Replace this definition with the generator expression that is
propagated by the PlatformModuleInternal target.
Change-Id: I1c606e16809dc720e2eb72191e1670dfc48f1b48
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Currently QT_USE_QSTRINGBUILDER is added for all Qt tool targets by
default, and it's not possible to remove this definition.
Replace this definition with the generator expression that is
propagated by the PlatformToolInternal target.
Change-Id: Iac3bd3ea76e7b439cf7957146b4b6dd20ecdbe3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since the feature breaks Qt build in some configurations, disable it
by default and make private, so users should enable it explicitly and
make sure that openssl libraries are accessible for linking at build
time by either PATH or LD_LIBRARY_PATH.
Fixes: QTBUG-114783
Pick-to: 6.6
Change-Id: I6eb53c43ed937ec1c0164025bc8953cc5170dc44
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The MIME database appears to use underscore to join its locale tags,
where QLocale::uiLanguages() uses dashes. This meant that lookups by
anything but the raw language were failing even when there was an
entry in the MIME database for the desired locale. Also, since 6.5,
the uiLanguages() list always does contain the locale's own name, so
don't add it to the list again.
At the same time, the search was putting the "default" key (used by
the MIME database parser for the entry with no locale specified) at
the end of the list but macOS (at least) uses that for the "en_US"
version, omitting "en_US" itself from the locale-specific data, with
the result that those using en_US as locale, but with some other
languages later in the list, got the translation for one of those
languages instead of the en_US one, since they were found before
"default" was reached. So insert "default" after the first block of
en-entries in which en_US appears, if it does, rather than at the end.
As a drive-by, amend a comment about using "pt" as fall-back for
"pt_BR"; as it happens, for pt_BR, uiLanguages() will contain "pt" in
any case, as pt_BR is the default for "pt". (Like en, pt anomalously
defaults to a territory other than the one the language is named
after.) So use de_CH -> de as example, instead (and place the comment
where the decision is taken).
Fixes: QTBUG-105007
Pick-to: 6.6 6.5
Change-Id: I1f4835190748256ce53a51321a94ae450ab7f61e
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ElideNone was originally introduced as a way of modifying behavior
of specific widgets, such as QTabBar. The text would previously
always be a elided and an ellipsis character would be added somewhere
to indicate this to the user. Given that context, it makes sense
that the documentation says the effect of ElideNone is that ellipsis
does not appear in the text, since the text would still be elided
if it were too long, given that the painter would draw it clipped to
the widget.
When QFontMetrics::elidedText() was introduced later, this became more
confusing. In the context of this function, you would expect the text
to be returned truncated to the width but without the ellipsis character.
Instead it just returns the full string.
Since this has been the effect of ElideNone since the start and multiple
places use it as a way of disabling the truncation of the string, we
simply update the documentation to make this more clear.
Pick-to: 5.15 6.2 6.5 6.6
Fixes: QTBUG-40315
Change-Id: If037430da6260020b1d99be7bd43e622f8afa844
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A zone may have transitions, none of which is for daylight-savings;
notably, Kiritimati has never done DST but did make a whole-day
transition to move the international date line from its west to its
east. (It also has, before that, the usual transition out of LMT and a
rounding transition from an initial UTC-10:40 offset to UTC-10.)
Change-Id: I5779e965d677cf9698b403d6a11242c9edeac864
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The following commits neglected to amend
tst_QImageReader::supportsOption() with the ImageOption enumerators
they added to QImageIOHandler:
- c0ba249a48
- 163af2cf53
- ba323b04cd
Fix first and foremost by adding the missing ImageOption::ImageFormat
to the list of PNG-supported formats (which, curiously enough, predates
the public history and therefore the above three commits), and second,
by rewriting the whole test function to enable -Wswitch, so further
additions are less likely to be forgotten.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I102121b2c8a9067864b8ade2ebe2650be6fb6010
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Ivan Komissarov <ABBAPOH@gmail.com>
[ChangeLog][qmake] Allows to override _DATE_ with SOURCE_DATE_EPOCH
to make builds reproducible.
See https://reproducible-builds.org/ for why this is good
and https://reproducible-builds.org/specs/source-date-epoch/
for the definition of this variable.
Fixes: QTBUG-115737
Change-Id: I1964aa0a3d849628440618aa6f0a51af2017d824
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The density of Q_FOREACH uses is high here, too high for this author
to tackle in a short amount of time. But they're concentrated in just
a few TUs, so pick a different strategy:
Mark the whole library with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too). Created QTBUG-115803 to keep track of
this.
Task-number: QTBUG-115803
Change-Id: Ib5d6192632d98bdcc6625a9a14e05d13bb7f759b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Identifiers matching _[A-Z_].* are reserved for use by the C++
implementation. Replace the __ prefix of variable names with _v_,
making them non-reserved.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I35127d7473678e2efd93a4b21847db562c53abd2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
In main.cpp, the loop is over a local variable which would be const
were it not for the multi-step initialization that I didn't want to
change. The loop body clearly doesn't modify the container, so port to
ranged for loop with std::as_const().
In printvolumes.cpp, the loop _does_ invoke unknown code (through the
function pointer passed as the second argument), but, as could be
expected, the two users of the function don't pass functions that know
about `volumes`:
- in the tst_QStorageInfo auto-test, an rvalue `volumes` is passed,
so we don't need to analyze the qInfoPrinter function passed there,
as it cannot possibly reference the temporary
- and in main.cpp of the manual test, we just pass printf (which is
technically UB (taking the address of a standard library function),
but I don't care right now).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ibcd10a0e0b3229d8f2a1d98545d8fa6d473a0f75
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Most of these are of trivial kind (loops over const locals).
The one that isn't, in cleanupTestCase(), is, however, also simple:
it's a loop over a local, too, but it would be too much churn to
change the initialization to make the container const, and the loop
body clearly doesn't modify the container, so just go with the
std::as_const() pattern here.
Task-number: QTBUG-115839
Pick-to: 6.6 6.5
Change-Id: I188a78ea67a63be2d50a81fea431e5ea9f2783cb
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Those are "public-ish" and exported functions (qstringalgorithms.h), so
one wouldn't expect that they get inlined most of the time. But they can
be inlined by other code inside qstring.cpp and if QtCore is compiled
with LTO.
More importantly, we want the compiler to inline qustrXXX_avx2() into
it, instead of tail-calling into qustrXXX_avx2(). This may seem like a
no-op but has one very important difference: backtraces will point to an
exported, function instead of an internal symbol. This will then allow
us to create valgrind suppressions.
Before unstripped:
==12492== Invalid read of size 32
==12492== at 0x53142EE: qustrchr_avx2(QStringView, char16_t) [clone .lto_priv.0] (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x54A7AE6: QString::indexOf(QChar, long long, Qt::CaseSensitivity) const [clone .constprop.0] (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x5218EC4: treatAsAbsolute(QString const&) (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==12492== by 0x5218FBA: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
Before, stripped:
==19477== Invalid read of size 32
==19477== at 0x5314395: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x54A7AE6: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x5218EC4: ??? (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19477== by 0x5218FBA: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/installed/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
After:
==19692== Invalid read of size 32
==19692== at 0x53143C5: QtPrivate::qustrchr(QStringView, char16_t) (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x54ABA46: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x5218824: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x521891A: QDir::filePath(QString const&) const (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== Address 0x741919e is 2 bytes before a block of size 32 alloc'd
==19692== at 0x4843794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==19692== by 0x54A8A84: ??? (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
==19692== by 0x531EB1C: QString::fromLatin1(QByteArrayView) (in /home/tjmaciei/obj/qt/qt6-release/qtbase/lib64/glibc-hwcaps/x86-64-v3/libQt6Core.t.so.6.7.0)
Recommended suppressions:
{
qustrchr_avx2
Memcheck:Addr32
fun:_ZN9QtPrivate8qustrchrE11QStringViewDs
}
{
qustrchr_avx2-with-debuginfo
Memcheck:Addr32
fun:UnknownInlinedFun
fun:UnknownInlinedFun
fun:_ZN9QtPrivate8qustrchrE11QStringViewDs
}
Change-Id: Ib84fc618ac204205bf7afffd1772b1d87343dfd0
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
I'd previously understood CLDR's minimumGroupingDigits to mean the
most significant group must have that many digits. It turns out to
mean only that the first grouping separator doesn't get added unless
the more significant group has this many. Once we have one separator,
more can be added that do isolate a single digit.
In the process, I discover some of the prior arithmetic is incorrect;
it is now fixed. Added some basic testing, amended some existing
tests. In the process, fixed naming of some double validator tests.
Pick-to: 6.6 6.5
Fixes: QTBUG-115740
Change-Id: Ia6ce011ba72e72428b015ca22b97d815ebf751b2
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
This source file is included in four other test projects, so it makes
more sense to port it away from Q_FOREACH than to white-list it
everywhere it's used.
The change in ModelMoveCommand::doCommand() is trivial. I only dropped
the pointless top-level const of the loop variable as a drive-by.
The change regarding `parents` in ModelChangeChildrenLayoutsCommand's
doCommand() is also trivial, I just ported to braced initialization to
get the QList to be const. We're forced by the Qt API
(layoutChanged()) to use a QList here, therefore no array.
Ibid., the change regarding `persistent` is simple. The container
cannot be marked as const without a lot of churn to its initialization
(applying IILE, basically), but other than that, it's a local
variable, and the loop body clearly doesn't modify it.
Task-number: QTBUG-115839
Pick-to: 6.6 6.5
Change-Id: I7a0e85804626a3cc612921b49e72e4b9f30b676d
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ib89d07fb751e3905a230ee5641e2e509e9415bed
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
There was a gap in its numbering, and the quick brown fix could do
with some competition.
Change-Id: I1283bbb6ba321ae2b65b4459327f2428a45f85cc
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This one isn't trivial, but straight-forward: the only place the
container is modified is in fill(). Like the setOpaqueChildren()
function, this is only called from top-level test functions, and, in
particular, not from event handlers (setAttribute() sends events).
That fill() doesn't clear() the container, even though the single
UpdateWidget instance is being reused across test functions, looks
wrong, but doesn't invalidate this analysis.
Task-number: QTBUG-115803
Change-Id: I284a19da2fe476278986c61810dd334fc73034b0
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The Q_FOREACH is in a header, so we need to port away from it,
otherwise it makes any TU that includes it (in PCH builds: all)
incompatible with QT_NO_FOREACH.
This is a trivial case of marking the local constructor const, but go
a step further and replace the QList with a C array ("never use a
dynamically-sized container for statically-sized data"). Both
consumers of the container (after s/foreach/for/) can deal with array.
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I142e438dcf2d785bb34022a3fb1ff46b8eaa0edd
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Prevents using the channel after it was destroyed.
Change-Id: I5d65fcde0d451dd8ce2c56f403e0bd1f41510382
Reviewed-by: Janne Koskinen <janne.p.koskinen@qt.io>
This is more readable and at the same time helps to eradicate some
more Q_FOREACH uses for an eventual global QT_NO_FOREACH for all Qt
sources (QTBUG-115796).
Task-number: QTBUG-115803
Change-Id: I9cbe76bee8a6306fab0c0bc94cd874405ca825ba
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: I40773a0397b83cce0c803967ee3fd7ae274933d3
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Ifef42704c4f695a8fb05ea5d9b3e095af3f35171
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
"Never use a dynamically-sized container for statically-sized data."
Port the loop from Q_FOREACH (which can't deal with arrays) to ranged
for (which can).
Pick-to: 6.6 6.5
Task-number: QTBUG-115839
Change-Id: Iecfc037c8bbfc0b3196ed0c65f680768a8d2353a
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The density of Q_FOREACH uses is high here, too high for this author
to tackle in a short amount of time. But they're concentrated in just
a few TUs, so pick a different strategy:
Mark the whole plugin with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. Since the TUs are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too). I'm aware that Objective-C/C++ files are
currently probably implicitly NO_PCH_SOURCES, but don't rely on that.
Task-number: QTBUG-115839
Change-Id: If451501f3cb7cc3a182854a94bc5d27c907f6161
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QList rather pointlessly has a startsWith() function, which means this
code compiled. But the code makes no sense: it tests the same
condition over and over again, so I'm assuming that it should be
path.startsWith() and not path_s_.startsWith().
Amends 3f56950862, but that just
imported the code from qttools. I didn't check whether the bug was
present there, already.
Pick-to: 6.6 6.5
Change-Id: I98a4bbfe0400700655a5c2137f7a976a835a8d28
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
