The QTZP base implementation of the availability check was to
construct the list of all available IDs, then see whether the given ID
appears in it. This can be very inefficient. The ICU backend has
recently grown a more efficient solution than that, matching the TZ
and Darwin backends. For Android this was still very inefficient, but
its instantiation is cheaper, so simply instantiate and see if the
result is valid. For MS, the backend caches the list of available
zones, so searching the list is a reasonable solution, given the
complexity of its constructor.
Add an implementation for Android and document, in the base-class,
that the fall-back is only suitable for use if the list is cached.
Pick-to: 6.7 6.6 6.5
Change-Id: I9dc2ba4be1492ec811c8db6cff9490ac0303115d
Reviewed-by: Volker Krause <vkrause@kde.org>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Introduce namespace QtTimeZoneCldr instead of having a Q prefix on
each class name used for the data.
Change-Id: Icb22a91340b67f9cc93173b77374a70f69f81bbe
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Also use C locale for this, rather than QLocale().
This makes the ICU backend's override redundant.
Change-Id: I3d668dd3a784b48d0a5fff7d11cc25a6e1423c84
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The zone and Windows data tables are sorted on Windows ID and its key
(which are monotonic functions of one another) so we can use binary
chop to find the first matching entry in each, when searching on
these. Furthermore, the search for ID from key can be shortcut as the
keys should normally be consecutive integers starting with 1.
Change-Id: I53f7ff8c93fd6d3d9e48c7bb86060746b68fab3d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The list is meant to be sorted in increasing order, requiring
"<anything> (Mexico)" to appear after "<anything>" but in two out of
four cases such pairs were in the wrong order. China sorts after
Chatham Island and lexical sorting of numbers doesn't match sorting by
numeric value.
Assert the expected ordering. (The more important check needs a
QBAV::compare(), which isn't constexpr, so we can't static_assert.)
Later commits shall use binary chop exploiting this ordering. The
assertion failed without the rest of this change.
Also improve the comments describing the data tables these searches
check and the types of their entries. Some were inaccurate, others
merely unclear. Likewise, comment the sorting expectations in the
python code that generates the tables.
Change-Id: I640a3cca8f820c5fd5939a2fe5feb96b04407335
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Various parts of QTimeZone's code were, for no immediately apparent
reason, conditioned on !defined(QT_NO_SYSTEMLOCALE). All are in any
case conditioned on feature timezone; and none had any obvious
relationship with QLocale::system(). Assume this is a fossil left over
from initial development of timezone support and purge.
[ChangeLog][QtCore][QTimeZone] Some features are now available
whenever feature timezone is enabled, that were previously dependent
on system locale support.
Change-Id: I7f2246e17ace22d2aecc9286295ae522ee2a0f5f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
While it would be perverse for availableTimeZoneIds() to list all
supported UTC-offset zone IDs, it makes reasonably good sense for its
offset-specific overload to include the ID QTimeZone would use for the
relevant UTC-offset, since passing this ID to the ID-based constructor
will indeed get a zone with this offset. In particular, it already
does include the offset-zone's ID if there is an IANA UTC-offset zone
with the given offset; and its list is apt to be empty otherwise.
Only applies to IDs we would in fact accept, checked with
offsetFromUtcString() to match the QTZ constructor's check.
Change-Id: I77bb60b166c3d3af5824d84952e1e10a5d32a5ad
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Principle of least surprise: prefer IANA IDs over synthesized ones.
This also aligns what id() returns more nearly with what
availableTimeZoneIds() reports. Amend some tests to match the new
behavior, extend one test to verify id-round-tripping (also for the
IANA zones) and another to verify single-digit offset IDs get
zero-padded.
Document the complications in how id() relates to what is passed to
the constructor. (It was already complicated; the present change just
aligns it better with IANA IDs, where possible.) Mention, in
availableTimeZoneIds(), that (and why) it only includes IANA's offset
IDs. Drive-by: fix a typo in another availableTimeZoneIds() overload's
doc.
[ChangeLog][QtCore][QTimeZone] When created from (only) a UTC offset,
or from (only) a non-IANA UTC-offset ID, a QTimeZone instance now uses
an IANA UTC-offset ID, where one is available with a matching offset.
Previously it used a synthesized UTC±hh[:mm[:ss]] one which would omit
trailing :00 for minutes or seconds, which the IANA ID may well
include.
Task-number: QTBUG-118586
Change-Id: Ifc4976f36361c830c88a8bef0e8b963fe5a2ab43
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The table was almost sorted by offset - its UTC entry, with offset 0,
was at the front rather than first among the offset 0 entries. The
lookups in it were being done as if the IDs were in space-joined lists
(as for the IANA IDs in the Windows table), splitting on space,
despite the fact that it had separate entries for different IDs at the
same offset (this only arose for offset 0). So actually massage the
input table in python to combine IDs with the same offset using space,
placing UTC first among the offset 0 entries, and ensure the C++ table
is sorted. Regenerated the CLDR data tables using the updated script.
In the process, fix an off-by-one error in the iteration over
space-joined IDs, where the search only advanced to the space, rather
than to just after it. That wasn't a problem before, but now would be.
Change-Id: Ib49c27bac269b557166fa10738c3e396d58456c0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QTimeZone(id) constructor accepts these IDs, but
isTimeZoneIdAvailable() did not admit to this. Although we cannot
sensibly list all 183,047 of them in availableTimeZoneIds(), we should
not claim they are unavailable. The custom QTZ constructor needs to
know when the ID it's been given is an IANA one (to refuse to use it),
so it has to be able ask the backends for "is this IANA", so the UTC
backend still has to report these IDs as invalid, leaving the QDT
frontend to include the check for these offset zones.
Extend isTimeZoneIdAvailable() test to include every offset-zone's ID
within QTZ's recognized range of offsets. Although the actual range
accepted by offsetFromUtcString() is wider, bounded by ±24:59:59, the
constructor from offset seconds (rather than offset string) is bounded
by ±16 hours.
Pick-to: 6.6 6.5
Fixes: QTBUG-118586
Change-Id: Id9b378aee122ec841635584367022fcb47041fdd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously, requesting a time that got repeated - on the given date,
due to a fall-back transition - would get one of the two repeats,
giving the caller (no hint that there was a choice and) no way to
select the other. Add a flags parameter that captures the available
ways to resolve such ambiguity or select a suitable time near a gap.
Add such a parameter to relevant QDateTime methods, including
constructors, to enable callers to indicate their preference in the
same way. This replaces DST-hint parameters in various internal
functions, including QTimeZonePrivate's dataForLocalTime(). Adapted
tst_QDateTime to test the new feature.
Adapt to gap-times no longer being invalid (by default; or, when they
are, no longer having a useful toMSecsSinceEpoch() value). Instead,
they don't match what was asked for. Amend documentation to reflect
that. Most of the code change for this is to QDTParser and QDTEdit.
[ChangeLog][QtCore][QDateTime] Added a TransitionResolution parameter
to various QDateTime methods to enable the caller to indicate, when
the indicated datetime falls in a time-zone transition, which side of
the transition to fall or whether to produce an invalid result.
[ChangeLog][QtCore][Possibly Significant Behavior Change] When
QDateTime is instantiated for a combination of date and time that was
skipped, by local time or a time-zone, for example during a
spring-forward DST transition, the result is no longer marked invalid.
Whether the selected nearby date-time is before or after the skipped
interval may have changed on some platforms; unless overridden by an
explicit TransitionResolution, it is now a date-time as long after the
previous day's noon as a naive reading of the requested date and time
would expect. This was the prior behavior at least on Linux.
Fixes: QTBUG-79923
Change-Id: I11d5339abef9e7125c4e0dc95a09a7cd4f169dab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
We can use plain data() for the recent and imminent that are further
from forLocalMSecs than its UTC equivalent can be: more than 99% of
the time these shall agree and we can save some fiddly details. We can
also use data(recent) as place-holder for the last transition's data,
saving a need to call previousTransition() - which may be expensive
(at least on Darwin). This avoids a quirk around minMSecs(), used by
the MS backend for a fake transition, so marginally simplifies some
initializations (and comments). It also gives us the information we
need for the fall-back (when transitions don't help or aren't known),
that uses the offsetFromUtc from recent and imminent, which the early
data() values supply.
Task-number: QTBUG-104012
Change-Id: I08403d129c0fec478b09de5b660f4a0a97b17148
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These APIs started out as private APIs in qnumeric_p.h, but have since
been made pseudo-public in qnumeric.h. The qnumeric_p.h versions just
forward to the qnumeric.h ones, so just use the latter.
This is in preparation of removing the {add,sub,mul}_overflow
versions, which, despite being defined in the unnamed namespace, don't
sport the q prefix, so potentially clash with global symbols.
The change is a simple textual search and replace, manually excluding
qnumeric_p.h.
Picking to 6.5 to avoid cherry-pick conflicts going forward.
Pick-to: 6.6 6.5
Change-Id: Ic0f7c92f7c47923317109e8a9dc06fa66bdff2c2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It turns out that Alaska and The Philippines had historical offsets
exceeding 15 hours, prior to day-transitions to bring their dates in
sync with their respective sides of the international date line.
Change-Id: I48fdf3aa6d8c0bacb368d08316733a10ee11a281
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
isHexDigit, isOctalDigit, isAsciiDigit, isAsciiLower, isAsciiUpper,
isAsciiLetterOrNumber.
This de-duplicates some code through out.
Rename two local lambdas that were called "isAsciiLetterOrNumber" to not
conflict with the method in QtMiscUtils.
Change-Id: I5b631f95b9f109136d19515f7e20b8e2fbca3d43
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Mixed operations with QByteArrays trigger deprecation warnings. We
don't have a Latin1/UTF-8 mixed comparison, so simply unroll what
operator== did: convert the byte array to QString and then do the
conversion there. But do it better -- only once and not at every
operator== call.
Task-number: QTBUG-100234
Change-Id: I4c6a4b92e175c536f69debf822b10688588e6c6b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This saves (mostly in corelib/time/) some complications that used to
arise from needing different code-paths for different time-specs.
Task-number: QTBUG-108199
Change-Id: I5dbd09859fce7599f1ba761f8a0bfc4633d0bef9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The CLDR data from which they're obtained may contain a space-joined
sequence of timezone IDs, rather than a single ID. (This applies
principally to the mapping from MS-specific names to IANA IDs, but in
principle may also apply to the other data obtained from same-shaped
XML.) Note this on the methods of internal types and actually take it
into account when using this data to match IDs.
See CldrAccess.readWindowsTimeZones() in util/locale_database/cldr.py
for the form of the CLDR data from which these are extracted; the type
attributes of mapZone elements in the XML are the source of the
space-joined lists of IANA IDs.
Change-Id: I3f940e4c352d8312ff735f972c9f8f3961572884
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code computed the transition gap and subtracted it from one side's
proposed UTC time, or added it to the other's; the effect was the same
as swapping these two values. Doing that overtly as a swap simplifies
the remainder of the code. Clarified the accompanying comment in the
process.
Change-Id: I00b8d2bb98ea08b6edd11e01d05a091cb39f3511
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The exception was previously limited to Android, but I now find that
ICU has the same over-long names; it seems likely that's where Android
gets them. Also update the link to the theory page from the TZ DB, as
it now has an official home on www.iana.org.
Task-number: QTBUG-99747
Pick-to: 6.3 6.2
Change-Id: I9af67426d15609dfaf5f335405ceb1218fcf40ff
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The minMSecs() itself is one more than the type's min(), which is used
as invalidMSecs(). As (at least) the Windows back-end uses minMSecs()
as the time of a start-of-time transition (that we'd like to find as
our current transition), use one more than it as lower-bound for where
to search from for a previous transition, so that we do find that
first ever transition.
Pick-to: 6.3
Change-Id: Iae861e740e02bd38ffb2af77aff625d3b48182d2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The methods give them more appropriate names. This revealed one place
where the min() that's actually invalidMSecs() was being used for a
time that should have been in the supported range, so amend that to
use minMSecs(). Replaced a use of invalidMSecs() + 1 with minMSecs(),
to which it is equal, as that was the meaning it was used for.
At the same time, make those methods constexpr (because they are) and
[[nodiscard]], since their values should be used, while dropping their
fatuous inline (the bodies are inline in the declarations).
Pick-to: 6.3
Change-Id: Idcd51c55850573372b44e6fcf08d5d2665b8a60e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The MS-Windows back-end neglected to check for overflow when mapping
date and time to milliseconds from the epoch. Add the checks for that
and take care not to return qint64-min as a transition time - that's
the invalidMSecs() value used as a special marker.
QTimeZonePrivate::dataForLocalTime() neglected to handle the case of
the backend being unable to answer offsetFromUtc() for one of the
times requested, which the MS backend might.
Change-Id: I6d7ee2cbf9aaf6678abb24a20e18b5cdac7f5a23
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This was handled correctly when the backend supplies transitions
bracketing the time in question, but the fallback code tried to use
the DST offset at the time with larger offset from UTC; this did not
work when the gap was due to a change in standard time. Discovered by
ANS1 parsing of a date-time with two-digit year, for which the
date-time parser tried to use 1921-05-01T00:00 local time when filling
in the fields it had parsed; but, when run in Europe/Helsinki, there
is no such time due to the 20m 11s skipped when joining EET from the
prior local solar mean time.
Correct the calculation to use the actual change in offset from UTC,
as used in the (far better tested) between-transitions branch of the
code, rather than the DST offset after the transition.
Add a test-case based on the ASN.1 certificate date whose parsing
revealed the issue. Although it seems nothing in Coin can reproduce
the issue, the reporter has verified that the test does indeed fail on
the system where the bug was found and the fix does fix it.
Fixes: QTBUG-96861
Pick-to: 6.2
Change-Id: I12b02bad01daca2073d1a356452cd573684aa688
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe
Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Add some trivial inline methods to the classes that populate the
tables to simplify access to their data. Use ranged-for loops to
iterate those tables (now that they no longer have bogus all-zero
entries at the end).
In the process, noticed windowsIdToDefaultIanaId() doing a double
iteration of the windowsDataTable, first via toWindowsIdKey() to map a
windowsId to a key, then again to map that key to the matching ianaId;
inline the former and use the table row from which it got the key to
extract its ianaId instead.
Change-Id: I76267f53c7e6f5c593e33b6146b8f98bfb6d042f
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
They are not needed. Iterations over the table track their sizes.
The size-of-table constants just needed their -1s removed.
Incidentally use std::size() rather than sizeof(array)/sizeof(element).
Change-Id: Ie20eef9f6f5786d93c10b830a87e006d3c5bcc1a
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Missed in a recent fix to QTimeZonePrivate::dataForLocalTime(), but
noticed during picking back to 5.12
Pick-to: 6.2
Change-Id: I63964952150fedf857b7aef12dfc866097d2e2d1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If the local time for which we want data is after the last known
transition, the two transitions we get to bracket it are the last
known and an invalid one. The code checked the former was valid, but
neglected to check the latter, leading to nonsense arithmetic later in
the function. In this situation we unequivocally want the last known
transition, so the problem is easily solved.
Fixes: QTBUG-96152
Pick-to: 6.2 6.1 5.15 5.12
Change-Id: I6fc830ce538e8a572093cd8dfe832e10689bf904
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QByteArray creates copies of data, but we usually don't need the copy
and a view, for comparison or fetching substrings, is enough. So instead
we use QBAView and QLatin1String (when we need to go through
QStringTokenizer).
Change-Id: I12e0bd8777fc63f676b9371abfd345fab1046c44
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
A follow-up to 6ec3321875 where the
function was optimized using a hand-rolled lazy-split on a QBAView.
Now that QLatin1String::indexOf(QLatin1String) has been optimized we can
use QStringTokenizer instead.
Change-Id: I30b15d309e7c364c0a4dafe31651b39ea14db7e5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
In debug this cuts off about 4 seconds off of the qtimezone test on my
machine. In release it's about 300-400 milliseconds.
Change-Id: I92ec18794247e3846704a7c8e87a8c34fdae5e3c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If the final result is outside the representable range, we can only
declare the given date-time invalid.
Change-Id: Ibce09462048bf351199657a5da2c55bb3ce5b934
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If the backends run into an error in computing the offset, they return
INT_MIN; but they are valled via the front-end, which returns zero
when the zone is invalid. So treat INT_MIN returns from the backend
the same as the case of being invalid.
Change-Id: Ic3c4dfe964dbfba4030c770213eca8a63e84736d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The use of "Country" is misleading as some entries in the enumeration
are not countries (eg, HongKong), for all that most are. The Unicode
Consortium's Common Locale Data Repository (CLDR, from which QLocale's
data is taken) calls these territories, so introduce territory-based
names and prepare to deprecate the country-based ones in due course.
[ChangeLog][QtCore][QLocale] QLocale now has Territory as an alias for
its Country enumeration, and associated territory-based names to match
its country-named methods, to better match the usage in relevant
standards. The country-based names shall in due course be deprecated
in favor of the territory-based names.
Fixes: QTBUG-91686
Change-Id: Ia1ae1ad7323867016186fb775c9600cd5113aa42
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When computing a recent and imminent time, to bracket the time for
which we want data, take care not to cycle round to the other end of
the range of representable times.
Rephrased comments on this function, in the process, to more
accurately reflect what we're doing.
Change-Id: Iacd36186abc6b19d0ca03981aec80b2c5af077b3
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In QTimeZonePrivate::dataForLocalTime(), mistrust the Android
backend's hasDaylightTime(), as it has a comment saying it only knows
about future transitions, not past. This caller of it really needs to
query "has ever had a transition", which this doesn't answer. Many
zones that have no plans for future transitions have had transitions
in the past; these were failing the transitionEachZone() test.
In the process, refine the test itself, making sure we catch some
quirk cases that shouldn't arise and making the debug message on
failure more informative (while eliding the zone name, as this is part
of the test name anyway, so added to the output by qDebug() itself).
Fixes: QTBUG-69131
Change-Id: I88a0528182c247acb8b6327b40516178e455bcc0
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Cuts off 1 second from the timezone test locally
Change-Id: I184728e97bcd65ca0362df4c26a3407576e12dfb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When creating a time-zone from a UTC+offset name that isn't known to
the system, QTimeZone (since the fix to QTBUG-77738 in 5.15.0) falls
back to constructing a suitable UTC-offset backend; however, the id of
this is not guaranteed to match the id passed in to the constructor.
In all other cases, the id of a QTimeZone does match the id passed to
its constructor.
Some utcOffsetId testcases had different id() than the id passed to
the constructor, due to mismatches where a zone was constructed using
the fall-back but the generated id included its minutes (as :00) or
omitted its seconds. The omission of seconds is clearly a bug, but we
also don't want to include :00 for seconds when it's not needed. So
change QTimeZonePrivate::isoOffsetFormat() to accept a
QTimeZone::NameType to configure how much we include in an id. Its
callers other than the relevant constructor (from offset) still get
minutes, even when :00, but will also get seconds added if that isn't
zero; and the constructor from offset now gets the short form obtained
by omitting all trailing zeros.
Since all valid whole-hour offset names that do include :00 for the
minutes field are in fact known standard offset names, the elision of
minutes will only affect zones created by ID in the case of a
whole-hour offset given without :00 minutes specifier, so these shall
necessarily in fact get the ID passed to the constructor. Creating by
UTC-offset with a name that specifies zero seconds will result in a
QTimeZone instance whose id() differs from what was passed to its
constructor (eliding the :00 seconds and potentially also minutes, if
also zero) but this should be the only case where a QTimeZone's id
doesn't match the one passed to the constructor, when constructed by
id.
Fixed inconsistency between the offset-constructor's declaration
(taking offset as int) and definition (taking qint32) in the process.
Added an id check to the utcOffsetId() testcase. Amended two tests of
offset-derived time-zones' IDs, added comments to make clear how one
of those differs from a matching standard name test and converted two
uses of QCOMPARE(, true) to QVERIFY().
[ChangeLog][QtCore][QTimeZone] QTimeZone instances created by offset
from UTC (in seconds) shall now only include minutes in their ID when
the offset is not a whole number of hours. They shall also include the
seconds in their ID when the offset is not a whole number of minutes.
Pick-to: 6.0 5.15
Task-number: QTBUG-87435
Change-Id: I610e0a78e2aca51e12bfe003497434a998e93dc7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
There is no reason for keep using our macro now that we have C++17.
The macro itself is left in for the moment being, as well as its
detection logic, because it's needed for C code (not everything
supports C11 yet). A few more cleanups will arrive in the next few
patches.
Note that this is a mere search/replace; some places were using
double braces to work around the presence of commas in a macro, no
attempt has been done to fix those.
tst_qglobal had just some minor changes to keep testing the macro.
Change-Id: I1c1c397d9f3e63db3338842bf350c9069ea57639
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Although the relevant conditions are indeed likely, we don't want to
push the less likely branch into hard-to-load pages; they're not
anomalous conditions, merely ones with lower probability.
Change-Id: Icc12a921d38d8c398cd832964e9d57d7648698b2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Edward Welbourne
Marc Mutz
Ahmad Samir
Giuseppe D'Angelo
Lucie Gérard
Sona Kurazyan
Jonas Kvinge
Mårten Nordheim
JiDe Zhang
Lars Schmertmann
Liang Qi
Qt Forward Merge Bot