In QStringListModel, the display and the edit roles are synonyms,
so when one is changed, the other changes with it. However, in
setData() we only emitted a vector with just the role that was
passed in by the user.
Fix by always passing both roles, regardless of which one was used
to set the data.
Change-Id: I498e7cb33796fae266901817b01ad85d861d4bb4
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
We can't (at present) actually exercise the failure in
QWindowsLocalCodec::convertFromUnicode() that prompted us to consider
the possible failure here, but we should at least test for it.
Change-Id: I5066c88d7b4caeb48aebc6b79c355fa49e1c581c
Reviewed-by: Frederic Marchal <frederic.marchal@wowtechnology.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Sometimes, this test fails in CI due to notifications arriving
asynchronously from the OS. This happens inside closeWriteChannel()
call, where we are flushing the write buffer and I/O completion on
the read pipe could occur there as well. So, take this into account
before waiting for the new incoming data. Also, improve the checks
on successful reading and writing.
Change-Id: Iabe875fc346eb4420c72d03208d22ea861a570c6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Use QStringRef::isNull instead of QStringRef::string()
for validation. Non-NULL str.string() may yet leave us
with a useless str.unicode(), which is the actual problem here;
whereas !str.isNull() does really confirm that str.unicode()
is sensible.
Such test prevents situation like:
const QString a;
QString b;
b.append(a); // b.isNull() == true
b.append(QStringRef(&a)); // b.isNull() == false
Auto test updated: create QStringRef from QString directly, without
any condition.
Change-Id: I082cd58ef656d8a53e3c1223aca01feea82fffb9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
As it were, QStringLists were not handled explicitly when comparing
QVariants. If both QStringLists contained only a single entry, they
were treated as QStrings - if both QStringLists were empty, there were
equal (correctly so) - but if one of the QStringLists had more than
one entry, the compare function fell through to returning always 1.
As discussed here: https://stackoverflow.com/a/38492467/3444217
Added rich comparison tests for all non-numerical, non-recursive
QVariants that support them (except QModelIndex and
QPersistentModelIndex)
Task-number: QTBUG-54893
Change-Id: Icc5480d9ba056ee5efe83da566c5829caa1509d7
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
We can't forward a VerticalSortHint or HorizontalSortHint hint, because we might
be filtering extra items.
The documentation of QAbstractItemModel::LayoutChangeHint states:
Note that VerticalSortHint and HorizontalSortHint carry the meaning that
items are being moved within the same parent, not moved to a different
parent in the model, and not filtered out or in.
And some of the views rely on this assumption (QQmlDelegateModel for example)
What happens in the test is the following:
- 'model' emit the dataChanged signal when its data is changed.
- 'proxi1' QSortFilterProxyModelPrivate::_q_sourceDataChanged does not forward
the dataChanged signal imediatly, it will instead first re-sort the model and
call layoutAboutToBeChanged / layouChanged with the VerticalSortHint
- 'proxy2' would forward the layoutAboutToBeChanged with the hint, but in
QSortFilterProxyModelPrivate::_q_sourceLayoutChanged, it will redo the mapping
which will cause the changed data to be filtered.
So proxy2 can't forward the VerticalSortHint as it removed rows in the process.
Change-Id: I20b6983e9d18bf7509fe6144c74f37d24e4a18c2
Reviewed-by: Tobias Koenig <tobias.koenig@kdab.com>
Reviewed-by: David Faure <david.faure@kdab.com>
They look relative because the path doesn't start with a '/' but they
have a scheme so they shouldn't be combined as if it was one absolute
and one relative URL.
[ChangeLog][QtCore][QUrl] QUrl::resolved() no longer treats a URL with
a scheme as a relative URL if it matches this URL's scheme. This special
casing was incompatible with RFC 3986 and broke resolving data: URLs,
for instance.
Change-Id: I3758d3a2141cea7c6d13514243eb8dee5d510dd0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It crashed when d was equal to Data::unsharableEmpty().
Task-number: QTBUG-51758
Change-Id: If9f2a7d11892507135f4dc0aeef909f59b7478fc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
For platforms not providing mkdtemp(), QTemporaryDir relied on an implementation
of q_mkdtemp() operating on char *, converting back and forth using
QFile::encodeName()/decodeName() when passing the name to QFileSystemEngine.
This caused failures on Windows (which uses "System"/Latin1 encoding)
for names containing characters outside the Latin1 space.
Reimplement q_mkdtemp() to operate on QString, which avoids the conversions
altogether and also enables the use of larger character spaces for the
pattern.
Add tests.
Task-number: QTBUG-54810
Change-Id: Ie4323ad73b5beb8a1b8ab81425f73d03c626d58a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The XML parser uses fastScanLiteralContent() to read a block of
text. The routine was not checking the range of valid characters as
defined in the XML standard:
https://www.w3.org/TR/2008/REC-xml-20081126/#NT-Char
A check has been added to stop reading the bad character.
Note that the characters are legal in XML 1.1, but QXmlStreamReader
is a well-formed XML 1.0 parser
[ChangeLog][QtCore][QXmlStreamReader]
Fixed a bug in the XML parser that prevented to load XML that
contained invalid characters for XML 1.0.
Change-Id: I10aaf84fbf95ccdaf9f6d683ea7c31925efff36d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When replacing each copy of one text with a copy of another, we do so
in batches of 1024; if we get more than one batch, we need to keep a
copy of the sought text and replacement if they're part of the string
we're modifying, for use in later batches.
Also do the replacements in full batches of 1024, not 1023 (which left
the last entry in an array unused); marked some related tests as
(un)likely; and move some repeated code out into a pair of little
local functions to save duplcation.
Those new functions can also serve replace_helper(); and it can shed a
const_cast and some conditioning of free() by using them the same way
replace() now does. (There was also one place it still used the raw
after, rather than the replacement copy; which could have produced
errors if memcpy were to exercise its right to assume no overlap in
arrays. This error is what prompted me to notice all of the above.)
Added tests. The last error proved untestable as my memcpy is in fact
as fussy as memmove. The first two tests added were attempts to get a
failure out of it. The third did get a failure, but also tripped over
the problem in replace() itself. Added to an existing test function
and renamed it to generally cover extra tests for replace.
Change-Id: I9ba6928c84ece266dbbe52b91e333ea54ab6d95e
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
In Qt, null QStrings compare equal to empty ones, so add an explicit
check that the corresponding hash values are identical, too.
Ditto for QByteArray.
Change-Id: I190fc95a765305928d9b6b0e4955433865b6b247
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These expressions only work because they contain no non-parenthesized
commas and an int literal is last.
Fix by wrapping only the integer literal in Q_(U)INT64_C.
Change-Id: I6b8e508b6c7c022f4b3342f65c26aab89ce17702
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... and reject invalid ones. There was one error: we accepted schemes
starting with pluses, dashes and dots.
Change-Id: Ie585843cfb684bc3b6e3fffd145cfe12227ec4ad
Reviewed-by: David Faure <david.faure@kdab.com>
A Qt5 program writing a null QTime() using setVersion(QDataStream::Qt_3_3),
and then a Qt3 program reading that, would lead to a weird QTime,
with isNull=false, isValid=false, hour=1193, minute=2, second=47, ms=295.
This commit restores interoperability, by writing out the expected value
(0) for a null QTime rather than the -1 value used by Qt4 and Qt5.
Change-Id: Icde468a8f6fc9434ef7018296725819b44d672af
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since Qt 5.0.0 we never built the test plugins on Windows, because we
checked for the existence of QtCore[d]4.dll, and the actual test does
not complain if it cannot find any plugins.
Use the right conditions to check for debug/release Qt builds on
Windows. Use subdirs dependencies on every platform and then actually
pass the right variable to SUBDIRS. Clean up the pro file while we're at
it.
Change-Id: I099f30afd445fbf43dc5677d256ffe55b27639b3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This reverts commit 55655abfaf.
The crashes in release mode cannot be locally reproduced.
Change-Id: I4e7b1defbeac5d5512b2fa82a367d2e04e3c37a4
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
This reverts commit b373d183de.
The crashes in release mode cannot be locally reproduced.
Change-Id: I38ff5e9e045cff0e94e24ca07fb6e18e88b677c7
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@theqtcompany.com>
When using a 8 bit encoding to write a file, a test discovers if the
encoding is really ASCII compatible by examining a letter and one of the
XML reserved characters. EBCDIC, in the current base, was not well
handled.
[ChangeLog][QtCore][QXmlStreamWriter] Fixed a bug that prevented the
generation of valid XML files when using encoding with 8 bit per
character but not ASCII compatible. QXMLStreamWriter generated XML
markup using always ASCII in this case.
Change-Id: I9c86a122dd91b2290d50c358638442f99777d4ae
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Commit 9ef3ff30 introduced a new function, putUcs4(), to
output QChar, char16_t, char32_t as a, possibly escaped,
character literal, but got the order of stream modifiers
wrong. Instead of applying the field width to the 'ucs'
streaming, it applied it to the prefix '\u'. The same
problem exists for the pad char, leading to the result
'00\ue4'
for a QChar containing
ä (LATIN SMALL LETTER A WITH DIAERESIS)
Fix by reordering the elements streamed so that the
prefixes come last.
Added a test.
Change-Id: I6eaa0586501b9e780aaa3bb5dcec0e5c2f86a219
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Limit the macro #ifdefery and allow for more test cases.
Task-number: QTBUG-53712
Change-Id: I2c185efc7c3b8fcd0217d2021bd98ab6044b5aee
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The test leaks a file (named qt_...xxx) in QDir::tempPath(). Moreover,
when tests fail, it can happen that more files are leaked and subsequent
runs do not recover since the check for non-existence of those files fails.
Change-Id: Iaea6d09ee7c271903a1b9c63e263c19f9e90bba9
Reviewed-by: David Faure <david.faure@kdab.com>
...if a PMF connection had already happened. Since UniqueConnection
isn't implemented for non-PMFs (functors and lambdas aren't comparable,
even if static member functions or non-member functions are), we pass a
null pointer for comparison argument. The disconnect() code already
protected against a null pointer there, but not the connect code path
with Qt::UniqueConnection
Change-Id: I87e17314d8b24ae983b1fffd145324beced0494d
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Dario Freddi <dario.freddi@ispirata.com>
POSIX.1-2001 allows quoting a zone name so that it can contain other
characters besides letters, by enclosing it in angle brackets ('<' and
'>'). This hadn't been used until recently (tzdata2016b), when the
Asia/Barnaul rule started using a zone name "+07" (the name variable
contained the value "<+07>-7").
Thanks to Paul Eggert for reporting and investigating the root cause.
Task-number: QTBUG-53071
Change-Id: Id5480807d25e49e78b79ffff1449bc410776cb66
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
QVariant::canConvert<Enum> was returning true for everything can can be converted
to integer, but not for integer itself. That's because in QVariant::canConvert
we set the targetType to Int of it's an enum, but the Int->Int case was not
on the conversion matrix. So this commits adds it to the conversion matrix
and now QVariant::canConvert<Enum> returns consistently true for int itself.
But even tough canConvert returned true, it did not actualy do any conversion
to the enum type itself. Fix that by handling the case properlt in 'convert'
[ChangeLog][QtCore][QVariant] Fixed QVariant::canConvert and conversion from
integer types to enumeration types.
Task-number: QTBUG-53384
Change-Id: I6ac066f3900e31bfcea7af77836ddfc7730bd60b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
So we know what we're looking at if there's a test failure. This is like
QNetworkInterface.
Change-Id: Id75834dab9ed466e94c7ffff1444bf51f615e944
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The path "/usrfoo" starts with "/usr", so if you tried to get
QStorageInfo("/usrfoo") when "/usr" is a mount point, you'd get the
wrong filesystem.
[ChangeLog][QtCore][QStorageInfo] Fixed a bug that caused QStorageInfo
to report information for the wrong filesystem if there is a mounted
filesystem at a path that is a prefix of the requested path (e.g., it
would report "/usr" filesystem for "/usrfoo").
Task-number: QTBUG-49498
Change-Id: I3e15a26e0e424169ac2bffff1417b7a27cd0132d
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
The C and C++ standards say it's undefined whether the preprocessor
supports macros that expand to defined() will operate as an ifdef.
Clang 3.9 started complaining about that fact.
One solution was to change QT_SUPPORTS to check for zero or one, which
means we need to change the #defines QT_NO_xxx to #define QT_NO_xxx 1.
The C standard says we don't need to #define to 0, as an unknown token
is interpreted as zero. However, that might produce a warning (GCC with
-Wundef), so changing the macro this way is not recommended.
Instead, we deprecate the macro and replace the uses with #ifdef/ndef.
Change-Id: Id75834dab9ed466e94c7ffff1444874d5680b96a
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test should not depend on qWait explicitly
Change-Id: I13c01c47c9f7bae8b0c30afa2ac8550dc0fbf028
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
newer versions of qt creator understand QMAKE_EXTRA_COMPILERS and
INSTALLS, so there is no need to list the files twice.
Change-Id: Iccf3cc3248daf3422b8c366c2eb2d2f46c5f08d1
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
On some operating systems, tzdata files carry the Local Mean Time (LMT)
for the city in question, which better represents how time was tracked
before standard, hourly timezones were introduced in the early 20th
century. The test was asking for the data for 1653-02-09 and assumed
that it would find the first Central European Time (CET) rule, which
Germany didn't start using until 1893-04-01.
This fix allows us to remove the blacklist that had been applied to this
test without investigation. It wasn't related to OpenSUSE, aside from
the fact that OpenSUSE tzdata carries the LMT data.
Change-Id: Id5480807d25e49e78b79ffff1449bdaf46901367
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
The "path" of a mailto URL isn't a file, so we shouldn't try to do
glob-based matching. I was getting application/x-ms-dos-executable
for a .com domain and application/x-perl for a .pl domain...
Change-Id: Ifc346c3bba83ba1a8476db3202492f4c2e4d52bb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When the formatting parameter wasn't exactly QUrl::EncodeUnicode, it
wouldn't encode, despite having to.
Change-Id: Id75834dab9ed466e94c7ffff1444bacc08dd109b
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
The RFC does allow it. It even has examples showing them as valid. In
section 6.2.3, it shows:
http://example.comhttp://example.com/http://example.com:/http://example.com:80/
Change-Id: Id75834dab9ed466e94c7ffff1444b7195ad21cab
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Edward Welbourne <edward.welbourne@theqtcompany.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
The behavior was different in the variadic template code and in the C++98
code. The code without variadic template support was not copying the functor
object (e.g. a lambda) before calling it.
However, in the variadic template section, QtPrivate::FunctorCall::call
took the functor by value instead of by reference resulting in a copy.
QtPrivate::FunctorCall::call is a helper function for
QtPrivate::FunctionPointer::call which is only needed for variadic template
expension.
[ChangeLog][QtCore][QObject] If the compiler supports variadic templates,
no longer copy functor connected to a signal each time the signal is
emitted. Restoring the C++98 behavior.
Task-number: QTBUG-52542
Change-Id: I3ca20ef6910893b8a288e70af7de4c7b69502173
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Before this change QFile::errorString function was returning an
"Unknown error". Now it will return the typical ENOENT string.
Task-number: QTBUG-45259
Change-Id: Ib7634f1aa5d91f77151cf92c58d3956e20a4cc6b
Reviewed-by: hjk <hjk@theqtcompany.com>
(for instance any global object which writes out to a config file in the
destructor). If the global cache isn't available anymore, don't use it.
Change-Id: I851a6e394d0b073aebf3ffd88b1966d424bfb92e
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Add some extra checks to the parser to make sure that addresses
like "300-05" aren't interpreted as valid IPv4 addresses.
Change-Id: I12475eebc9452e060779bb05e2b4ad9512a28281
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The flags here are passed to a private QVariant constructor, and they
really represent a boolean - IsPointer or not.
Because the flag for the key_type was incorrectly populated with the
flag for the value_type, memory would be corrupted when using a mapping
type whose value_type is a pointer, but whose key type was not, such as
QMap<QString, int*>
This typo has been there since the concept was introduced in commit
v5.2.0-alpha1~807 (Add container access functionality for associative
containers in QVariant., 2013-04-05).
Task-number: QTBUG-52246
Change-Id: I9ecb13c603015eed2dc2ca43947fa0ecd6be8b5a
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
People use this, so make sure there's a test for it.
I don't expect this test to fail, but static and
dynamic checkers should be presented with this
use-case, so they have a chance of warning, because
certain implementation strategies of QPointer may
make this code undefined.
Change-Id: I334bd73204ba4e186c4098fc6b7188917407e020
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Removing blacklistings from tests that are now passing.
Change-Id: I00aa1ce286d3e7715fb4bee4a36d0d77049a29ae
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@theqtcompany.com>
The previous implementation overwrote multiple 'time' parts in the
qSetMessagePattern with the last setting in the pattern line.
%{time}%{time process}%{time boot} ended up to be output as if
%{time boot}%{time boot}%{time boot} was set.
This fix keeps the arguments of each individual 'time' part.
The same holds for multiple 'backtrace' parts. The previouse
implementation overwrote multiple 'backtrace' arguments with the
arguments of the last occurrence.
This fix keeps the individual arguments for the 'process' parts.
The individual arguments are applied in qFormatLogMessage.
A new test to verify the individual 'time' arguments application
is added, too.
Task-number: QTBUG-51944
Change-Id: Ib757614a482c5f31ed0a61b550daa2eea4b907b4
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Drop addSub() test. It executes exactly the union of fetchAndAdd()
and fetchAndSub(), which have already had their UBs fixed.
No need to do fixes in duplicated code.
Change-Id: Ib72caab0310fce3ff9a40c261d8a38518f91ecaf
Reviewed-by: David Faure <david.faure@kdab.com>
The spawn code was only used to make QProcess work on QNX 6.5.0. Fork
works on QNX 6.6.0. The QNX spawn implementation has a flaw that causes
a deadlock in certain situations. When a working directory is specified
for the process, the QNX spawn implementation stops all threads except
the one doing the spawn so that it can temporarily change the process'
working directory. This can lead to a deadlock if the thread does
anything that conficts with something being done in a stopped thread.
QNX 6.5.0 is no longer supported in Qt 5.6.0 so we can just switch QNX
to the fork implementation and get rid of the spawn implementation.
Made a QNX specific adjustment to the hardExit test. There's a bug
in the OS that the test can run into because it does something that
normal applications wouldn't.
Task-number: QTBUG-47250
Change-Id: Ib32567d2c15ce651815858000035ac5aa6f35224
Reviewed-by: Dan Cape <dcape@qnx.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Previously WinRT was using the UTC backend which fails on all platforms
for some QDateTime autotests related to timezone items. Hence switch to
the Windows implementation for WinRT as well.
However, the windows backend does query the registry heavily, which is
not supported on WinRT. Instead use the API version provided by the SDK.
Long-term we might want to switch to this version on desktop windows as
well, as direct registry access would not be required and we could
harmonize the codepaths for both platforms.
Change-Id: I620b614e9994aa77b531e5c34c9be1da7e272a30
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
