Avoid duplicated code paths for GrowsForward vs
GrowsBackward. Special case emplaceing at the
beginning or end of the awrray where we can
avoid creating a temporary copy.
Change-Id: I2218ffd8d38cfa22e8faca75ebeadb79a682d3cf
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Trivial methods that don't modify any data for the most
part.
Also mark removeFirst/Last() as noexcept. Those methods
can't throw exceptions as we require ~T() to be noexcept.
Change-Id: I8698705c6113909aa8f7ae021a932df48a224d5d
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Avoid ever having to call a destructor and unify the code for
insertion at the front or at the end.
Change-Id: Ie50ae2d4a75477cfdae9d5bd4bddf268426d95b5
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QList::insert() should never need to call a destructor. This
requires that we construct the new items in the list in order
and increment the size each time we constructed a new item.
Not having a code path that potentially calls destructors should
avoid the generation of lots of additional code for those
operations. In addition, the forward and backwards code paths
are now unified and only require somewhat different setup of
some variables at the start.
This gives us strong exception safety when appending one item,
weak exception safety in all other cases (in line with std::vector).
Change-Id: I6bf88365a34ea9e55ed1236be01a65499275d150
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
When appending multiple items, we are fine with providing
weak exception safety only. This implies that we can simplify
the moveAppend() code and avoid having to potentiall
call destructors in there.
Change-Id: I31cef0e8589e28f3d3521c54db3f7910628e686f
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We've been expanding to a lot more code than we need to, and
the code was slower than it needed to.
Change-Id: I79e49fefd8b3fedb26a32a8d4c80e71b2c0c4041
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Remove methods that were just calling the base implementation.
Change-Id: I4011e1b7f4f2baad98bc2af2d4ddb134a66e1be2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Move the implementation into the different specializations, and
simplify the implementation. This can be done since we know
that destructors will not throw exceptions for types stored in
our containers.
Change-Id: I9556cd384ef99a623b5b8723b65f16eb9e1df767
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Types that throw in their destructors are strongly discouraged in C++,
and even the STL doesn't define what happens if such types are stored
in their containers.
Make this more explicit for Qt and disallow storing those types in our
containers. This will hopefully preempty any potential future bug
reports about us not handling such a case. It also helps simplify
some code in QList and other cases and makes it possible to explicitly
mark more methods as noexcept.
Some care needs to be taken where to add the static asserts, so that
we don't disallow forward declarations of types stored in containers.
Place the static assert into the destructor of the container where
possible or otherwise into the templated d-pointer.
Change-Id: If3aa40888f668d0f1b6c6b3ad4862b169d31280e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Get rid of the createInPlace() method. It was just a wraper around
a placement new call.
Change-Id: I672cd41896c8531b474531aad656be79a1a63e6b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
QExceptionSafetyPrimitives::Destructor doesn't need an additional
template argument, and the freeze() method was unused.
Some methods of the Constructor class could also be simplified.
Change-Id: Iacf35bc8634f402519a8bd875b5efea7841f9db5
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This simplifies and clean up the code.
Change-Id: I4cbfa69bda95187f97daf814eb3d44d90c502d92
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Unify it with the code in QArrayDataOps and only have one
emplace method there that handles it all.
Adjust autotests to API changes in QArrayDataOps and fix a
wrong test case (that just happened to pass by chance before).
Change-Id: Ia08cadebe2f74b82c31f856b1ff8a3d8dc400a3c
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When a foreign event loop that does not enter an alertable wait state
is running (which is also the case when a native dialog window is
modal), pipe handlers would freeze temporarily due to their APC
callbacks not being invoked.
We address this problem by moving the I/O callbacks to the Windows
thread pool, and only posting completion events to the main loop
from there. That makes the actual I/O completely independent from
any main loop, while the signal delivery works also with foreign
loops (because Qt event delivery uses Windows messages, which foreign
loops typically handle correctly).
As a nice side effect, performance (and in particular scalability)
is improved.
Several other approaches have been tried:
1) Using QWinEventNotifier was about a quarter slower and scaled much
worse. Additionally, it also required a rather egregious hack to
handle the (pathological) case of a single thread talking to both
ends of a QLocalSocket synchronously.
2) Queuing APCs from the thread pool to the main thread and also
posting wake-up events to its event loop, and handling I/O on the
main thread; this performed roughly like this solution , but scaled
half as well, and the separate wake-up path was still deemed hacky.
3) Only posting wake-up events to the main thread from the thread pool,
and still handling I/O on the main thread; this still performed
comparably to 2), and the pathological case was not handled at all.
4) Using this approach for reads and that of 3) for writes was slightly
faster with big amounts of data, but scaled slightly worse, and the
diverging implementations were deemed not desirable.
Fixes: QTBUG-64443
Change-Id: I1cd87c07db39f3b46a2683ce236d7eb67b5be549
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Have one generic method for detaching and reallocations.
Use that method throughout QList to avoid duplicated
instantiations of code paths that are rarely used.
Change-Id: I5b9add3be5f17b387e2d34028b72c8f52db68444
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Some cosmetics, but also some optimizations where we avoid a
temporary copy, or calling detach() twice.
Change-Id: I26803fdecf943ed9fab9baf58124091c7cebe1f3
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The method can simply forward to the append overload taking
iterators. That method is safe against the iterators being
part of the list itself.
Change-Id: I4bebd6c1118cd4a428fa9248235029b997ef60b2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Since QMutableSinglePointEvent is just an access-helper to QSinglePointEvent,
we can safely create one from the other. This covers QMouseEvent as well
with the right casting in place.
And by making QMSPE default constructable, we can use it in code that
needs to frequently copy event data, for example in QtQuick.
This allows us to make the copy c'tor and assignment operators for QEvent
classes protected, which prevents potentially dangerous (ie. slicing)
implicit copies.
Change-Id: I815774847cca63896f46c43df683053b3d952b61
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We have use cases for cloning of events, e.g. in the state machine and
for event propagation.
Provide the means to do so through a virtual method.
Adapt QFutureCallOutEvent::clone, which is now an override. No code
seems to be using that method.
Change-Id: I6864d6597f6de800343c4dc458a7994e84dc6fb4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Without breaking currently generated CMakeLists
Fixes: QTBUG-88549
Change-Id: Ibda643e1374d9024bf693c12de8ec0ac46e09b7b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When doing static builds any project which uses same
libraries as qtbase 3rd party libraries will most likely
end up in broken binaries, since symbols will be
included twice. Moreover, libraries can have different
versions. Install 3rd party headers and meta data for:
* qtlibpng
* qtfreetype
* qtharbuzz
Pick-to: 5.15
Task-number: QTBUG-87154
Change-Id: I243dff9a12a95af20dee414f55bb762b8d579c81
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
That breaks configuration with CMake version 3.18.x (but not 3.19 for
some reason).
Specifically configure ends up passing -DCMAKE_CXX_COMPILER=clang++
which overrides the compiler set by the CMake Android toolchain file,
and at the very end of CMake's configuration it complains about
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= clang++
Which suddenly starts another configuration with the modified
compilers, ends up detecting host compilers and libraries and
basically everything breaks apart.
Fix QtProcessConfigureArgs.cmake not to pass the compiler options if
the mkspec contains 'android'.
Who knows, we might need this for other platforms too at some point.
Task-number: QTBUG-88460
Change-Id: Idd57870a7cb1009a4e7802e5b3d5ac735f2dacf6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Although many executable files were generated by qt_internal_add_tool().
Some executable files like designer and androiddeployqt were generated
by qt_internal_add_app(). Some executable files like windeployqt were
generated by qt_internal_add_executable(). For these executable files,
their PDB files won't be installed on MSVC platform, and their separate
debug info won't be generated and installed on other platforms.
To fix this, qt_enable_separate_debug_info() and
qt_internal_install_pdb_files() should also be called in
qt_internal_add_executable().
Fixes: QTBUG-88268
Change-Id: Id6a3b5842dba325166e3d696701c82ad942bca74
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Android packages the test instead of qapplication folder, thus the
BLACKLIST file for Android tests needs to be in "test" folder
instead.
Task-number: QTBUG-87666
Task-number: QTBUG-87025
Change-Id: I065072fa8a030cf9d15e057869e74a8c736c80ab
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Tests in tst_qhighdpi are crashing on Android.
Task-number: QTBUG-88505
Task-number: QTBUG-87025
Change-Id: Ie1350e06fb30d90f20c550f91555f4023eee56b6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These tests are failing with "java.lang.UnsatisfiedLinkError: dlopen
failed: invalid ELF file" at the start, excluding them now to enable
Android testing until they're fixed later.
Task-number: QTBUG-87671
Task-number: QTBUG-87025
Change-Id: Ida7d7158fccdc31df1f9689f77fde832964d732f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
MSVC does in some case full instantiation of the template. Make sure
all of it expands to valid C++, even in the case where those methods
are supposed to be disabled.
Fixes: QTBUG-86289
Change-Id: Iaae39ef60fc5cf5fee273b0934a5a52b6ae4ec17
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
These variants produce the same code as if std::round was compiled
with -ffast-math.
Change-Id: I8e0d7601928a511b9bc8b8f969cfd94df47c3784
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Use atomic ref counting and make type movable.
Make a moved-from QEventPoint valid but undefined. Given that the
d pointer is anyway loaded into the register, the additional check
doesn't cost much, and makes the class more compliant with our
guide for value types in Qt.
Add a free swap overload via Q_DECLARED_SHARED, which also declares
the type as movable.
As a drive-by, remove superfluous inline.
This also silences some static analyser warnings.
Change-Id: I7c4a436fce44556aa37026ac26dc2061e1f01de9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This allows for potential optimizations in widgets, e.g. no need to for the
input method to query all data when only the cursor position changed.
Change-Id: Idd1e554acd776ed4d225197ce80915d651ede904
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Qt 6.0.0 is new major version for Qt and so on we don't need to
list changes to the previous Qt release but quide readers to check
porting quide.
Change-Id: Ib083c5e839aedee879291fe0174a8751970eebc1
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
We don't use it yet in qtbase, but will need it in various other sub-modules,
so it's arguably better to maintain it here.
Change-Id: I5c10c9b34cafd435251918280ad0405189900337
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
this implements a suggestion made by a comment that got lost in
028ddf363: as explained in 97645478's commit message, we were forcing
use of fork() because we couldn't be sure that the code in a custom
setupChildProcess() did not rely on pthread_atfork() callbacks being
called.
however, that in turn was inconsistent with the default behavior, and
made customizing QProcess mutually exclusive with benefitting from
forkfd().
use the opportunity presented by changing the method of modifying child
process behavior to also change this.
this also amends 4e2f4670, as most of the now deleted comment in fact
related to the use of vfork semantics, which we don't do anymore.
[ChangeLog][Important Behavior Changes][QtCore][QProcess][Unix]
pthread_atfork() callbacks are consistently not invoked on reasonably
recent Linux and FreeBSD systems any more. This was already the case in
later Qt 5 releases, unless setupChildProcess() was overridden.
Change-Id: Icb239e4d2c705bf4665589469022a521267f7db5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These look like leftovers (API flaws).
Construction of QFileInfo from QString (or similar) should be not
implicit, as QFileInfo construction is expensive (might hit the file
system), and this may have users overlook APIs (for instance build a
QFileInfo out of QDirIterator::next(), instead of using ::fileInfo();
using QDir::entryList instead of entryInfoList; etc.).
Leave an opt-out mechanism to ease porting.
Fix a handful of usages around qtbase, with at least a couple of them
likely to be actual "sloppy" code.
[ChangeLog][Potentially Source-Incompatible Changes][QFileInfo] Most
QFileInfo constructors are now explicit. The
QT_IMPLICIT_QFILEINFO_CONSTRUCTION macro is provided to keep old code
working.
Change-Id: Ic580e6316e67edbc840aa0c60d98c7aaabaf1af6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QChar should not be convertible from any integral type except from
char16_t, short and possibly char (since it's a direct superset).
David provided the perfect example:
if (str == 123) { ~~~ }
compiles, with 123 implicitly converted to QChar (str == "123"
was meant instead). But similarly one can construct other
scenarios where QString(123) gets accidentally used (instead of
QString::number(123)), like QString s; s += 123;.
Add a macro to revert to the implicit constructors, for backwards
compatibility.
The breaks are mostly in tests that "abuse" of integers (arithmetic,
etc.). Maybe it's time for user-defined literals for QChar/QString,
but that is left for another commit.
[ChangeLog][Potentially Source-Incompatible Changes][QChar] QChar
constructors from integral types are now by default explicit.
It is recommended to use explicit conversions, QLatin1Char,
QChar::fromUcs4 instead of implicit conversions. The old behavior
can be restored by defining the QT_IMPLICIT_QCHAR_CONSTRUCTION
macro.
Change-Id: I6175f6ab9bcf1956f6f97ab0c9d9d5aaf777296d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
