E.g. a group separator, a -/+ sign, or 'e' (exponent). Input ending with
one of these characters now returns Intermediate, as it can become
Acceptable if the user types more characters.
Remove a check from initialResultCheck(), as it's now covered by
QLocaleData::validateChars() checking that the last character in the
buffer is -/+, this works the same if buffer's size is 1.
Extended unittests based on the linked bug report; the other cases for
"last" are already covered by existing unittests.
Task-number: QTBUG-111371
Change-Id: I9b6979c29f07a5f57b040004cd3dbf4e27147c21
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add an option to disable handling of positional binding so jsonb
operators are not screwed up
[ChangeLog][QtSql][QSqlQuery] Add setEnablePositionalBinding() to be
able to disable positional binding.
Fixes: QTBUG-96636
Change-Id: I428a9d3b10274b97292ab86a74d9b3971d6f10e9
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Drive-by change: use \code, better formatting especially for longer
lines of code.
Change-Id: I90dbde17a5bea276c86304bff64027dd9d248a21
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It actually takes one parameter, because in this overload the connection
type can't be specified, for example:
QTimer timer;
timer.callOnTimeout([]() { qDebug() << "slot"; });
The call chain is:
QObject::connect(timer, &QTimer::timeout, functor);
connect(const typename QtPrivate::FunctionPointer<Func1>::Object *sender, Func1 signal, Func2 &&slot)
connect(sender, signal, sender, std::forward<Func2>(slot), Qt::DirectConnection);
the connection type is always DirectConnection.
Spotted by Giuseppe in code review.
Pick-to: 6.6 6.5 5.15
Change-Id: Ia8bbd91e98a357244cbfae4e3ed63d4c73038fa2
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
It was defined in qlocale_tools_p.h which already includes qlocale_p.h.
Change-Id: I43464a27ec15266ce8632ca30dcd1c57d94b1f25
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of returning just bool, return a result struct {State,
CharBuff}, a State is useful as it can have an Intermediate state
where the input isn't Acceptable yet, but not Invalid as such. The
example from the linked bug is in tst_QIntValidator::validateFrench(), a
string "1 ", which can be interpretted as a number with a group
separator, but the input shouldn't end with a group separator (changing
the unittest will be done as part of a separate commit).
CharBuff (QVarLengthArray<char, 256>) replaces the QByteArray input
parameter; a QVarLengthArray means no heap allocation in typical
use-cases with input text < 256 characters to validate. This required
minimum changes (QVLA doesn't have startsWith, replaced by comparing
with buff[0]; and for converting to double, wrapped it in a QBAV).
Task-number: QTBUG-111371
Change-Id: I4e0eb612d470ef03faf52031ddfe9c4bdb31e1e1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QDoubleValidator didn't return Intermediate if the buffer only had one
character, - or +, but it makes sense to check that there too.
In a later commit that check will be moved to QLocaleData::validateChars
(which will return "Intermediate" if the last character in the result
buffer is -/+, in this case it's the last and only character in the
buffer).
Change-Id: I2f9f5b92880b7e9cc1a3ab36b5ec322f57291ee9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Take by const Str&, trimming a container/view of characters means
removing whitespace from the beginning and end, so the two args were
always cbegin() and cend().
Change-Id: Iac0eda59341f1981204d11013d591013eae3c4e0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The same _data() will be re-used with trim().
Change-Id: Ie9b794b7e8d40552d9cacb71df0f8a151d4348a5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use [&] instead and remove overparenthefication as a drive-by.
Amends c888e3922d.
Pick-to: 6.6 6.5 6.2
Change-Id: Ic7930d5011c247122a1b3396ea0d6a9a2d6107de
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
They aren't used because the C++11 atomics are the only atomics we've
supported since commit 9d1fab424e (5.6).
Pick-to: 6.6
Change-Id: I53335f845a1345299031fffd176f84ccd054b804
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
By the time QObject::destroyed() is emitted from ~QObject(), sender no
longer is-a SenderObject, only a QObject, so calling a SenderObject
member function on it is UB.
Says UBSan:
tst_qfuture.cpp:3854:84: runtime error: member call on address 0x60200000e550 which does not point to an object of type 'SenderObject'
0x60200000e550: note: object is of type 'QObject'
00 00 00 00 e8 3f 96 c9 51 7f 00 00 80 3e 00 00 c0 60 00 00 02 11 00 00 08 00 00 00 16 00 00 72
^~~~~~~~~~~~~~~~~~~~~~~
vptr for 'QObject'
Fix by removing the QObject::connect().
This, of course, breaks the test's WHEN, but I don't see how to keep
that WHEN without the UB. At least the THEN part is not invalidated,
and there doesn't appear to be another test that tests that destroying
objects before signal emission results in a cancelled future.
Amends 612f6999c8.
Pick-to: 6.6 6.5 6.2
Change-Id: I38ca4611c071e8fd200393b600210e36d4030bc6
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
QSpan is Qt's version of std::span. While we usually try not to
reimplement std functionality anymore, the situation is different with
QSpan. Spans are non-owning containers, so the usual impedance
mismatch between owning STL and Qt containers doesn't apply here:
QSpan implicitly converts to std::span and vice versa, making STL and
Qt APIs using spans completely interoperable.
We add QSpan mainly for two reasons: First, we don't want to wait
until we require C++20 in Qt and can use std::span. Second, in the
view of this author, some design decisions in std::span hurt the
primary use-case of spans: type-erasure for containers. This results
in two major deviations of QSpan from std::span: First, any rvalue
container is convertible to QSpan, allowing seamless passing of owning
containers to functions taking spans:
void sspan(std::span<T>);
void qspan(QSpan<T>);
std::vector<T> v();
sspan(v()); // ERROR: rvalue owning container
auto tmp = v();
sspan(tmp); // OK, lvalue
qspan(v()); // OK
This author believes that it's more helpful to have compilers and
static checkers warn about a particular wrong usage than to make
perfectly valid use-cases impossible or needlessly verbose to code.
The second deviation from std::span is that fixed-size span
constructors are also implicit. This isn't as clear-cut, because an
explicit QSpan{arg} isn't per-se bad. However, it means you can't
transparently change from a function taking decltype(arg) to one
taking QSpan and back. Since that's exactly what we intend to do in Qt
going forward, in the interest of source-compatibility, the ctors are
all implicit.
Otherwise, the API of QSpan follows the std::span API very
closely. Like std::span, QSpan isn't equality_comparable, because it's
not clear what equality means for spans (element-wise equal, or (ptr,
size)-wise equal?). The major API additions are Qt-ish versions of std
API functions: isEmpty() on top of empty() and sliced() instead of
subspan(). The (nullary) first()/last() functions (Qt speak for
front()/back()) clash with the std::span function templates of the
same name, so are not provided.
This patch adds QSpan as private API. We intend to make it public API
in the future.
Pick-to: 6.6
Fixes: QTBUG-108124
Change-Id: I3f660be90eb408b9e66ff9eacf5da4cba17212a6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Dennis Oberst <dennis.oberst@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
When parsing a string whose time-zone part matches local time's name,
use local time in preference to the QTimeZone with that name. The case
is ambiguous, and the bug was already fixed (by something else) in
dev, but this caused a failure in 6.2 through 6.5; and using local
time is more natural to QDateTime in any case. The fix incidentally
makes the the logic of the zone-resolution code more straightforward
and a closer match to how findTimeZone() found the match.
The issue was hidden from 6.6 by a change [*] to the handling of POSIX
rules, that lead to plain abbreviations such as CEST and BST - for
which the IANA DB has no entry - no longer being considered "valid"
zones, despite being technically valid POSIX zone descriptors
(effectively as aliases for UTC).
[*] commit 41c561ddde
Pick-to: 6.6 6.5 6.2
Fixes: QTBUG-114575
Change-Id: I4369901afd26961d038e382f4c4a7beb83659ad7
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since QDateTime uses some fall-backs if qTzName() doesn't give it
something useful (as happens on MS-Win when local time is UTC),
QDateTimeParser should check the result of those fall-backs as well as
the qTzName()s when checking for local-time as zone.
Pick-to: 6.6 6.5 6.2
Change-Id: Ic809b7e44cd0c83fb076b24c27547268345fa379
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's actually testing that the system locale (which it obtains via the
default constructor, relying on setDefault() not being called first in
the helper program - which I'll soon change) behaves as expected.
Change-Id: Iedd2c1bb549288661c910dfbaac509ede9506d04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
Although QSystemLocale is (to make its query enum usable) defined
despite the QT_NO_SYSTEMLOCALE define, it's not used in that case, so
tests based on it won't work. So extend the reach of the #if-ery to
include the test using a custom class based on it. Also rename the
test from systemLocale(), as that's the name the emptyCtor() test
really should have.
Change-Id: Ief69bf161251cde47ee45014cc2627d42cfcc526
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Konrad Kujawa <konrad.kujawa@qt.io>
The other Roman-based calendars share the same month names as
Gregorian, so it makes sense for them to use the same system fallbacks
as it when available.
Change-Id: Idf2f2901032c7a02d641f00a3993cc95b6bb8067
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Amends commit 94de5f9b25 so that every
change to the default locale is reflected in an update to the default
collator used by QString::localeAwareCompare().
Although the change to the system locale does update the QLocaleData
object shared by all system locale objects, the possible change to its
collator() may imply the default collator needs an update; and the
collator backend's init() may use the language, script and territory
that's changed in setting up the revised collator, even if the QLocale
instance referenced has the same QLocaleData.
Pick-to: 6.6 6.5 6.2
Change-Id: I957486c03c3d779fc9a2f0b889346ec13b1af868
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is for consistency with QObject::connectImpl() and
QObjectPrivate::connectImpl(), if nothing else.
See the commit message of the QObject::connectImpl() porting patch for
why we leave the function signature unchanged (key-word:
tail-callability).
Pick-to: 6.6 6.5
Change-Id: I515d3be4a5126f9f4738dd7bde5174377faf2343
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... removing the custom scope-guard which was .dismiss()ed too early
(the allocation of 'c' could theoretically fail, and the old code
would leak the slot object in that case; nothing we're generally
guarding against in Qt, but it's a nice drive-by gain, probably shuts
up static checkers, and makes readers wonder less about the lifetime
of the slot object).
As mentioned in the patch porting QObject::connectImpl(), leave the
unique_ptr out of the function's signature, see there for rationale
(key-word: tail-callability).
Pick-to: 6.6 6.5
Change-Id: Ib90371b9768a72fd62d080b71eef2c82f851db81
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This gets rid of the smell that one destroyIfLastRef() call guarded
against nullptr while the other one did not.
Don't change the function signatures, as passing by unique_ptr, while
making the transfer of ownership clear, makes it impossible to call
the function as a tail-call: Non-trivially-copyable arguments live in
the caller's stack frame and the caller has no idea whether the object
was moved from in the callee or not, so it needs to run the dtor,
which prevents this from being tail-callable.
Passing .release(), OTOH, makes it obvious that the unique_ptr is
nullptr afterwards, so leaves the door open for tail-calling.
However, the QObjectPrivate::connectImpl() wasn't, and continues to
not be, a tail-call. Investigating why, while intriguing, is for
another patch (and much more important for the template wrappers of
these functions than then one out-of-line function we're dealing with
here).
Pick-to: 6.6 6.5
Change-Id: Ib951ed2a2b622d70cb12ddbf01c83ec56b1ce70d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... so it can use the new QMetaCallEvent() ctors taking that type.
As a consequence, the slot object ref-count is now no longer touched
on the way into the meta-call event (was: upped in QMetaCallEvent
ctor, then downed in QScopeGuard).
Pick-to: 6.6 6.5
Change-Id: Id9bd157792458a3834809c23e94ca5f504f7abd1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This makes it clear who is responsible for obtaining additional strong
reference to the slot objects, because these functions no longer do.
Pick-to: 6.6 6.5
Change-Id: I39187e3c441d8f82d50d907731f1cbdfb2a95b9d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When, like in tst_QFactoryLoader::extraSearchPath(), where asan caught
it, or, presumably, on re-creation of a QGuiApplication with a
different QT_QPA_PLATFORM_PLUGIN_PATH, setExtraSearchPath() is called
with a different path than before, then it would leak QLibaryPrivate
objects in the call to libraryList.clear().
Fix by adding QLibraryPrivate::Deleter and holding the objects in
unique_ptr<QLibraryPrivate, Deleter> instead of as raw pointers. This
statically guarantees we're not leaking these objects anywhere else in
QFactoryLoader.
Change the name of the container from libraryList to libraries to catch
any unported users, incl. in older branches.
Since libraryList is now a std::vector (QList cannot hold move-only
types), statically assert that it was never attempted to be copied or
moved, even in older branches, with Q_DISABLE_COPY_MOVE().
Amends ddba24535f.
Not picking to 6.4 and 6.3, as they are closed at this point.
Pick-to: 6.6 6.5
Fixes: QTBUG-115286
Change-Id: I6d1272622b12c505975cc72f9aba0d126d2817e2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It doesn't make sense to disturb users with the policy warning if they
don't specify Android paths. Suppress the policy check if Android
paths are not set for the target.
Fixes: QTBUG-115119
Pick-to: 6.6
Change-Id: Ice9d0459c01feb505857133bb942b1b6e775e55a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QtSystemMsg has been an alias to QtCriticalMsg since Qt 4 times,
probably because of the misleading name. Let's formally deprecate
the enum now, so that it at one point (Qt 7?) can be finally removed.
Change-Id: I385b62a77ceb66f75f318a00a73ea5e7333bf4f1
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
These pages are designed as tutorials, so
they can be \page instead of \example.
Also, reorganized the tutorials, moving them out
of the testlib manual, into several qdoc files.
Task-number: QTBUG-115248
Pick-to: 6.5 6.6
Change-Id: I2cbd66ecc1082ecc9d3d1742b621ee009daf1031
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Exclude TUs that cause problems in a build where all of QtWidgets's .cpp
files end up in a single unity_0_cxx.cxx. This should ensure that the
build will forthwith not fail because someone added a new .cpp file in
the "wrong" position.
Of course, this is just a snapshot, with my configuration: GCC 13,
Ubuntu 20.04, -developer-build, C++23, -sctp.
Task-number: QTBUG-115352
Pick-to: 6.6 6.5
Change-Id: I6a445701e2ac41d67a3ec69715b7bf6ed5ec65f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Exclude TUs that cause problems in a build where all of QtCore's .cpp
files end up in a single unity_0_cxx.cxx. This should ensure that the
build will forthwith not fail because someone added a new .cpp file in
the "wrong" position.
Of course, this is just a snapshot, with my configuration: GCC 13,
Ubuntu 20.04, -developer-build, C++23, -sctp.
Task-number: QTBUG-115352
Pick-to: 6.6 6.5
Change-Id: If33a485b697f60a2f4d6198f0798c953fa47af51
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As a drive-by, re-use the result from the first QFile::exists
check.
Pick-to: 6.6
Change-Id: I6b36b165ba3d1f82c9b4be18d44a671f71e8507e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When we reset the theme so that icons should be provided by the
system theme, then reset the search paths to the system-provided
paths as well. Otherwise we'll keep looking for the system theme
in user-provided search paths, which can't work.
Pick-to: 6.6
Change-Id: I10bcb404db9924e038f6fdc8970e53bbb69ac7d1
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Amends a452e22546. No new tests, existing
tests fails when QPlatformTheme returns a QIconEngine implementation
that provides the tested icons. However, the existing test fails when
the platform icon engine provides and address-book-new icon, and depends
on the order of test functions, as the name() test function modifies the
global theme name and search path. Fix those issues in the test.
Pick-to: 6.6
Change-Id: Ie1c1d14f08fad5e906296bab662df5cfacdbbf07
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
perror does not support string formatting. The problematic code is in VxWorks ifdef so this error was not breaking the other targets compilation.
Change-Id: I44e5d247bfa76815c81f0d122f0e34b75538dfa9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Looping over the entries had a typo in it and was quite unnecessary,
as it just made a fresh copy of a list we already had.
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: I0f3023b06163e5854d425d816e465785cda5fc91
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
If the path where Qt sources are located has 3rdparty in it we skip
headers processing since all headers are treated as 3rdparty.
Use path relative to the source directory when indentifying the 3rdparty
header files using regex.
Fixes: QTBUG-115324
Pick-to: 6.5 6.6
Change-Id: If97328cb9a9ece01d43c56022f4613da9b29c03f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use QT_NO_CONTEXTLESS_CONNECT to disable 3-arg connects which are
considered dangerous.
Change-Id: I0ac711491de60e0eeaca9edb60715eafe9da841a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
- Add a constructor
- Initialize members in-class
- Reorder the data members so as not to waste space between them, now
all the padding is at the end
Change-Id: Ic88200fbff049615a6a43e322e724cf619fc3cdb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead use composition by using a container member; inheriting from
containers has a couple of issues:
- containers (STL and Qt) don't have virtual destructors, which means
that deleting via a pointer to the base-class would be troublesome
- as it turns out, inheriting from containers, QList in this case,
in an exported derived-class could lead to binary-incompatibility
issues (see linked bug report)
Drive-by change:
- group all private members in one place
- make timerInsert() private, nothing should use it from outside the
class anyway
Change-Id: I69843835d8c854fa4b13e8b4ba3fb69f1484f6a6
Fixes: QTBUG-111959
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- Use removeIf(), easier to reason about than removing from the list
during iteration
- Return true only if any timers were actually unregistered
- Assert in QObject::event() that if the list returned by
eventDispatcher->registeredTimers() isn't empty, then
eventDispatcher->unregisteredTimers() returns true
Change-Id: I739a3865b7524a7aab3ff0227e6a060ed98d6191
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
