Add some macros to enable systematic testing of QStringBuilder
expressions.
Change-Id: I6b7dbcb4a4ca0d1aebdfe7cb9861af881c0cd346
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Also adjusted the text segmentation and line break algorithms
so that they can handle the new data, and pass the test suite.
Change-Id: Ib727fd80003e34e96458d7a681996de3fa3691e7
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Make sure we properly handle both directional embeddings as well as
directional isolates to determine the direction of the string.
According to the latest version of the Unicode bidi algorithm,
parts of the string contained inside an directional isolate is
to be ignored when determining the paragraph direction. Embedding
markers themselves are to be ignored as well, but not the characters
inside an explicit directional embedding or override.
This is also some required pre-work to get our BiDi algorithm
updated to the latest version of the standard.
Move the implementation to QStringView and implement the methods
in QString and QStringRef through that implementation.
Task-number: QTBUG-57743
Change-Id: I7f24e09198e22d6359c6534c9ae40a904e94c46e
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Since its initial implementation, QRingBuffer had the following
fragilities in the architecture:
- it does not guarantee validity of the pointers, if new data will
be appended. As an example, passing an address of the QRingBuffer
chunk as a parameter to the WriteFileEx() function on Windows
requires the stability of the pointer. So, we can't add new data
to the QRingBuffer until the overlapped operation completed
(related issues were fixed for QWindowsPipeWriter and QSerialPort
in 5.6 branch by introducing an intermediate byte array);
- inefficient reallocations in reserve(), if a shared chunk was
inserted in the queue (we can get a reallocation in the place
where we don't expect it:
char *writePtr = buffers.last().data() + tail; <- line #133
).
Proposed solution is to avoid reallocation by allocating a new
block instead. That was accomplished by introducing a QRingChunk
class which operates on a fixed byte array and implements head/tail
pointers strategy for each individual buffer in the queue. So,
QRingBuffer is no longer dependent on QByteArray's internal
shrink/growth algorithms.
Change-Id: I05abab0ad78e22e4815a196037dfc6eff85325d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This autotest fails on the new Ubuntu 16.04 template with UTC timezone
in the system settings.
Task-number: QTBUG-65435
Change-Id: I397f01ab3fed354a4eeec8b05415226a75fce5a1
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
Commit 68bcccac took account of MS TZ APIs mis-describing non-DST
zones making changes to standard offset (e.g. Europe/Samara in 2011 at
the end of October); however a DST transition that coincides with an
equal and opposite change to standard offset, while the other end of
its DST period changes normally, ends up looking exactly the same
(although it's nominally subtly different), in MS's APIs. Thus fixing
the more common case broke this more obscure case; there is no way to
fix this (other than not using MS's broken-by-design APIs). So kludge
the test to skip the bit we know this breaks.
Task-number: QTBUG-64985
Change-Id: I068500e2e783ab72b400bfd6dbb7dbbd5b08a7bc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously, a 1, 2 or 3 for "dd" would be rejected because 10, 20 or
30 would fit in the field and be valid; but 4 or more was accepted,
even though it was too short for the field, because no suffix could
make it valid within the field-width.
[ChangeLog][QtCore][QDateTime] When parsing dates and times from
strings, fixed-width date-time fields, such as a "dd" for day,
QDateTime now rejects all values that should be padded, rather
than only doing so when the value is a prefix of some value that
would fill the field-width. Use a single letter for the field,
e.g. "d" for day, if you want to accept short
values. (QDateTimeEdit is not affected.)
Task-number: QTBUG-63072
Change-Id: I22d223c50057c3edab4ef7f01d9ed0f58e9139c1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Test-case taken from bug-report; fits in as an easy row in an existing
data-driven test. Add similar tests for date-time and time; and an
isValid test on the end of year 9999. The date-time parser was using
the end of year 7999 as maximum value for dates and date-times; extend
this to year 9999, as I can see no reason not to.
[ChangeLog][QtCore][QDateTime] Years up to 9999 can now be parsed
without error (previously 8000 and beyond were treated as invalid) in
all formats (not only in ISO format). Widgets handling dates now
support dates to 9999, likewise.
Task-number: QTBUG-64401
Change-Id: I518cfa6c2cb4ecc5a85b896dc9e56b4fdd8a8bb1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since removeAll() takes its argument by cref, if passing a reference
to an element of the container to removeAll(), the element may be
deleted (overwritten) by anyother value, leading to UB.
Add a test that actually happens to fail for me without the patch,
even though that might not be guaranteed (we may invoke UB).
Change-Id: If8c795113aeb515f4a9bdf1e072395b932295667
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
During the container BoF session at the Qt Contributor Summit 2017 the
name of the signed size type became a subject of discussion in the
context of readability of code using this type and the intention of
using it for all length, size and count properties throughout the entire
framework in future versions of Qt.
This change proposes qsizetype as new name for qssize_t to emphasize the
readability of code over POSIX compatibility, the former being
potentially more relevant than the latter to the majority of users of
Qt.
Change-Id: Idb99cb4a8782703c054fa463a9e5af23a918e7f3
Reviewed-by: Samuel Gaist <samuel.gaist@edeltech.ch>
Reviewed-by: David Faure <david.faure@kdab.com>
When parsing a date-time's zone, a stray Z denotes UTC (a.k.a. Zulu
time), despite not being a valid name for the zone. Clients parsing
such date strings had to treat the Z as a literal, rather than a
zone-ID, but then they got back a LocalTime instead of the UTC the
string actually described. So teach QTimeZoneParser to handle this
special case and adapt an existing test (that used a time ending in Z,
but had to treat it as a local time) to check this works.
[ChangeLog][QtCore][QDateTime] When parsing a time-zone, "Z" is now
recognized as an alias for UTC.
Change-Id: Ib6aa2d8ea2dc6b2da526b39aec74dbc007f90fd8
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The vast majority is actually switched to QRandomGenerator::bounded(),
which gives a mostly uniform distribution over the [0, bound)
range. There are very few floating point cases left, as many of those
that did use floating point did not need to, after all. (I did leave
some that were too ugly for me to understand)
This commit also found a couple of calls to rand() instead of qrand().
This commit does not include changes to SSL code that continues to use
qrand() (job for someone else):
src/network/ssl/qsslkey_qt.cpp
src/network/ssl/qsslsocket_mac.cpp
tests/auto/network/ssl/qsslsocket/tst_qsslsocket.cpp
Change-Id: Icd0e0d4b27cb4e5eb892fffd14b5285d43f4afbf
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The milli-seconds since epoch value for an invalid transition is,
of course, invalidMSecs(), not invalidSeconds().
Added a comment while I was at it, explaining why we expect a
transition before the epoch, if such transitions are supported.
Change-Id: I0f376f9d69c0e6e79a309dc011943baa41175135
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ultrix and reliant have not seen a release since 1995. dgux not since
2001. bsdi not since 2003. irix not since 2006. osf not since 2010.
dynix... unclear, but no later than 2002. symbian needs no mention.
All considered obsolete, all gone.
sco and unixware are effectively obsolete. Remove them until someone
expresses a real need.
Change-Id: Ia3d9d370016adce9213ae5ad0ef965ef8de2a3ff
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Discussed during Qt Contributor Summit 2017. We concluded that we don't
want to make these functions public, as they do not follow Qt coding
style API. Specifically,
qStartsWith(a, b)
is not easily understood which argument is the needle and which argument
is the haystack (same problem memcpy() has). Compare that to
a.startsWith(b)
which can clearly be read in English as a subject-verb-object sentence.
This commit removes the unit tests that called compare().
Discussed-on: http://lists.qt-project.org/pipermail/development/2017-October/031060.html
Change-Id: Icaa86fc7b54d4b368c0efffd14ee6205eb9043fb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
This avoids looping prior to the main 16-byte loop, by performing one
load that may include bytes prior to the start of the string. This is
guaranteed not to fault, since str points to a valid character, but it
may cause Valgrind to print warnings.
Change-Id: I6e9274c1e7444ad48c81fffd14dcae854bba24b2
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remaining uses of Q_NULLPTR are in:
src/corelib/global/qcompilerdetection.h
(definition and documentation of Q_NULLPTR)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Remaining uses of Q_DECL_OVERRIDE are in:
src/corelib/global/qcompilerdetection.h
src/corelib/global/qglobal.cpp
doc/global/qt-cpp-defines.qdocconf
(definition and documentation of Q_DECL_OVERRIDE)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: Ib9b05d829add69e98a86238274b6a1fcb19b49ba
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
For self-consistency with QSharedPointer and minor consistency
with std::unique_ptr (although QScopedPointer isn't movable, so we
can't claim STL compatibility with it).
[ChangeLog][QtCore][QScopedPointer] Added get().
Change-Id: Ib58f936afa0e0d5bce57a61d1467b69956f37ceb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Performance is more important in this case than the theoretical benefit
of constexpr. This commit implements the SSE2 search for 16-bit null and
it might be possible to implement the equivalent for AArch64
(investigation required). It also adds a fallback to wcslen() for
systems where wchar_t is short (non-x86 Windows or 32-bit x86 build with
-no-sse2).
We can re-add the constexpr loop once the C++ language has a way of
overloading constexpr and non-constexpr. GCC has a non-standard way to
do that with __builtin_constant_p, which is also implemented in this
commit, but note that the inline function is still not constexpr.
Change-Id: I6e9274c1e7444ad48c81fffd14dcaacafda5ebdc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QMacAutoReleasePool is backed by an NSAutoreleasePool, which documents that
"you should always drain an autorelease pool in the same context (invocation
of a method or function, or body of a loop) that it was created".
This means allocating QMacAutoReleasePool on the heap is not a supported
use-case, but unfortunately we can't detect it on construction time.
Instead we detect whether or not the associated NSAutoreleasePool has been
drained, and prevent a double-drain of the pool.
Change-Id: Ifd7380a06152e9e742d2e199476ed3adab326d9c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Actually check that there's a T where ISO 8601 wants it (instead of
just skipping over whatever's there), with something after it; move
some declarations later; add some comments; and use the QStringRef API
more cleanly (so that it's easier to see what's going on). Simplify a
loop condition to avoid the need for a post-loop fix-up.
This incidentally prevents an assertion failure (which brought the
mess to my attention) parsing a short string as an ISO date-time; if
there's a T with nothing after it, we won't try to read at index -1 in
the following text. (The actual fail seen had a Z where the T should
have been, with nothing after it.)
Add tests for invalid ISOdate cases that triggered the assertion.
Change-Id: Ided9adf62a56d98f144bdf91b40f918e22bd82cd
Reviewed-by: Israel Lins Albuquerque <israelins85@yahoo.com.br>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Check we do handle DST after epoch and don't before.
Check we do notice various unusual transitions.
Check we do handle non-whole-hour-offset zones.
(Unfortunately, MS-Win lacks data for some of the zones and is wrong
about the two date-line crossers, so we skip those for it.)
Change-Id: If420d61b9db7f914ca25c22297c16e917ad2307a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This needs a zone with transitions near the epoch; and the only CET
with DST that winter was Italy (copied by Malta), for which the Olson
database had a recent (2016) correction to its data, for that winter.
That means we get inconsistent results on O/Sen of different ages.
So add a separate testEpochTranPrivate(), alongside testCetPrivate(),
and test it with America/Toronto. (Unfortunately, MS-Win gets the
date wrong on the first transition after the epoch, so we have to code
round that.)
Since information before the epoch isn't reliably available, only test
the search backwards if nextTransition does find something before it.
(We can safely assume all real transitions happened since 1601;
non-celestial time-keeping wasn't accurate enough, before that, for
anyone to synchronize with anything but celestial time.)
Change-Id: I984b46938a2805b93bb2afd6855e317b5d66b386
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Currently QLocale::c().bcp47Name() returns "C" which, according to [BCP47], is
not a valid language tag. In particular it does not conform to the ABNF grammar
in section 2.1 which specifies a minimum length of 2 characters for all language
tags.
[BCP47]: https://tools.ietf.org/html/bcp47
This patch changes the return value to "en" seeing as the documentation for
QLocale::Language states that the C language is identical in behavior to
English.
Task-number: QTBUG-61949
Change-Id: I2a381def8fb7156467e01d105da92bb1f4821204
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
When QCOMPARE(,) reports two 12-digit numbers, it's not always
immediately obvious what the difference is (much less what 1/3600000
of it is); nor is it obvious that (or why) a given 12-digit number is
in fact correct. In contrast, our eyes can make sense of a
QDateTime's reported value quite well, enabling us to see what's
different; and it's possible to at least confirm the plausibility of
2-or-3 am on a spring or autumn day at a plausible transition (or even
to confirm it exactly by consulting suitable web-sites). Also
document the actual transition happening in each case (since I *did*
consult a suitable web-site). So prefer to QCOMPARE(,) two QDateTime
values instead of two 12-digit qint64s.
Where a that would be unsuitable, at least compare the difference to
zero, to make the error easier to understand (except when one of the
twelve-digit numbers consists entirely of 9s; that, for once, actually
is easy to see).
Write various multiples of 3600 as the relevant intelligible whole
number times 3600, rather than premultiplying, to make it obvious to
reders what's going on.
None of this changes what is actually tested.
Change-Id: I488e751283a55d4623c93612af13ad631144900d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A loop initialized i = 0 and used i > 2 as its condition; it didn't
get very far. Consequently, the test it was in never checked whether
CET's 2011 transitions happened at the times expected - which they
didn't, as the times in question were in fact the times at which
Pacific/Auckland had its transitions that year.
Change-Id: I94d1f8df615c5bcfe48e73d41b4c7faf2beccb96
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The output didn't previously make clear that the datum was invalid.
It's now explicitly invalid. At the same time, use QDebug's space()
and nospace() methods to make spacing choices explicit.
Revised a QDate test to match.
Change-Id: I4699f5897530b4caa31c22fdb07de149832b30f4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Separate the part varying between tests from the common form of all
the tests, so the reader can see the common pattern and know for sure
that there's not a typo or copy-and-paste glitch.
Change-Id: I3145a26ab42c104eb27756d906ac87f937024bad
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore][QLocale] Fixed the conversion of QTime to string
form and parsing from string form to always treat the value as the
decimal fraction of the seconds component. That is, the string format
".z" produces/parses ".2" for 200 milliseconds and ".002" for 2
milliseconds. Use of "z" or "zzz" is discouraged outside decimal
fractions to avoid surprises.
Task-number: QTBUG-53565
Change-Id: Ia19de85ad35e4eb7bb95fffd14792caf9b4a5156
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
