[ChangeLog][QTestLib] Add QCOMPARE_{EQ,NE,LT,LE,GT,GE}()
macros. These new macros behave similarly to QVERIFY(a op b),
where 'op' is ==, !=, <, <=, >, >= respectively, but print
a formatted error message with argument values in case of failure.
The formatting is done lazily, which means that the strings will
be generated only when the comparison fails.
Also add a new test for tst_selftest and generate expected output
for it.
Fixes: QTBUG-98873
Task-number: QTBUG-98874
Change-Id: Ic8074798901d7a469b1f58d5cd28bbf49a3da1db
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The TAP test logger will now correctly print comparison types such
as QCOMPARE_NE or QCOMPARE_LT, and also provide a proper expected/wanted
value (by adding proper arithmetical operators in front of the value).
Sample output:
type: QCOMPARE_GE
message: Left value is expected to be greater than or equal to right value, but is not
wanted: >= 1 (rhs)
found: 0 (lhs)
expected: >= 1 (rhs)
actual: 0 (lhs)
at: tst_ExtendedCompare::compareUnregistereEnum() (tst_extendedcompare.cpp:232)
file: tst_extendedcompare.cpp
line: 232
As a drive-by: make some variables const.
Task-number: QTBUG-98873
Change-Id: Idb54eaabcb937b42d3fc844f30041aab82d73f69
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The compare() implementation made its actual and expected seem to have
different types (using a typedef name for one, when the other was of
the type that expands to) and the formatter it used was needlessly
clunky. Use modern string literals and package a repeated
null-or-quoted representation as a lambda, inline the resulting
simplified prettyElement() into prettyPair(), which can now just take
a pair rather than an iterator. Short-cut the empty list so that the
comma-joined accumulation could initialize with the first entry and
loop over the rest, always joining with a comma.
Undo commit f776595cc10aaafc7162f382a8fa11afffb0e708's mistaken update
to the copyright header and update correctly.
Change-Id: I99258dafa01e79f9ec384d9b375a59376eb7fb53
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We were querying the traitCollection property of the application's
keyWindow in order to determine the appearance mode (light/dark) of
the app.
However, the application may not have a keyWindow (visible window)
by the time the we set up the appearance mode, so get that information
from the last window in the application's windows array instead.
Change-Id: If7435d9f565b5c594a26027c971c16a1e3a9af26
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The old code allocated a stack buffer, but asked the runtime to
zero-initialize it. That's 1KiB of writes to the stack on every
QCOMPARE and QVERIFY before any actual work is done. Fixing this
little laissez-faire to just initialize the first character in the
buffer results in nice little speedups of up to or exceeding 2x.
Amends d946507727.
[ChangeLog][QtTestLib] Optimized successful QCOMPARE and QVERIFY for
an up to 2x speedup.
This has the potential to meaningfully reduce the load on the CI, so
picking all the way to 5.15.
Pick-to: 6.3 6.2 5.15
Change-Id: Ib93d69282ec87cbd26a60e4ac14413e8cef8ff78
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The crash was provoked by QThread::terminate() called
for QWindowsDialogThread from QWindowsDialogHelperBase destructor.
It's still not clear why terminating the thread here causes a crash,
but normally we should avoid terminating a thread anyway.
Current changes make several improvements to avoid terminating the
thread. The main problem was that QWindowsDialogThread::run() was never
returned. That's because QWindowsNativeFileDialogBase::close() was not
called on QWindowsDialogHelperBase destruction. The second problem
was that QWindowsNativeFileDialogBase::close() may still not close
native file dialog because it was not able to find HWND for IFileDialog
instance in some circumstances, so make this by more robust way.
Fixes: QTBUG-93298
Pick-to: 6.3
Change-Id: I55c8cf664ae2cf7c41c8cce43a6bb88a2680bf14
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Rather than default-constructing and later setting its .mds, just pass
the number of millis to the constructor.
Change-Id: I5e259ee99b1ba53c48d8d71f2b479001c26ab7a0
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Being able to distinguish which 60 is minutes-per-hour and which is
seconds-per-minute has some value in its own right, and doing it with
qint64 values (as usual for DateTimeConstants) takes care of two
Coverity warnings about multiplying before widening.
Use the new constant, and SECS_PER_MIN, in a few other places where
the result isn't an int (we don't want to provoke narrowing warnings).
Change-Id: Iadcb6956ac22a53029bf7b7518369520d2b1fd8b
Coverity-Id: CID 393112
Coverity-Id: CID 393113
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When testing, we need to query the state of the Qt application,
so change the scope of qtloader from inside the init function
to global scope.
Additionally, adjust the test script accordingly to query and use this
state to make good decisions on how to terminate.
Change-Id: I6264ba20843716eb87340b160680617b718f6bd9
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Added new function handleError which does the usual work whenever there
there is an error, including logging the error to console. Also make
the app exit when the emscripten module fails to load.
Additionally, make sure we correctly report it as crash
if the module fails to load.
Change-Id: I9d723373a34ccbb146959a2207ebded8bcbd4f18
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Add support for blocking sockets on secondary threads and on the main
thread with asyncify. This extends the support for websockify tunneled
TCP sockets, which was previously limited to async sockets on the main
thread.
Blocking sockets support is implemented by emulating select() on top
of emscripten's socket notification support. This is requires synchronization
between the blockee threads and the main thread, since we get socket
notification callbacks on the main thread. The synchronized state is held
in g_socketState where the main thread registers socket readiness state and
blocking threads register themselves.
Blocking using asyncify on the main thread is similar to blocking on
a secondary thread, with the exception that the main thread suspends
with qt_asyncify_suspend() instead of waiting on a wait condition.
Change-Id: Idb5a493644e1e6634057dc2f64f2e99e82e3c01e
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This requires a different computation of the mask since we can't shift
out of the storage type.
Change-Id: Ife85ca3e0c5ca47f06988a397cc2f8a7e28ad0fe
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since P0792r8, pointers to members are no longer supported, which
means we don't need to use std::invoke anymore.
Remove std::invoke in favor of traditional function call syntax, which
should be faster to compile, too.
Change-Id: I2ec3888795471f345ded36bb564d35ac0de29068
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is an implementation of function_ref, which has been proposed for
inclusion into C++23, but has not been accepted, yet, which is why we
place it in namespace qxp (for eXPerimental) instead of q23.
The implementation is based on wg21.link/P0792r9, which, at the time
of writing, is the latest revision of the paper. It will be used in
both QTestLib and qmldom.
Fixes: QTBUG-103739
Change-Id: I52723eca28f7ac02ce7ce51928361d81ae5c92b1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add an implementation of C++23's std::invoke_r. Will need it in our
implementation of function_ref.
Differences to std::invoke_r:
- only constexpr in C++20, not in C++17 (to fix, we'd need to
implement our own q20::invoke just to add the constexpr keyword;
let's first see whether we need this).
Task-number: QTBUG-103739
Change-Id: Id864f83f27ed499849b6bde0c34353127e37e7ed
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
As of Emscripten 3.1.3, the --embind compiler argment has been
depreciated for -lembind
Change-Id: Iac5bc21602f27fda7c1ea6814a1c9525b9a5afab
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We tried to "help" the user by passing the value from -o 'qt_host_path'
into CMake '-DQT_HOST_PATH=...' automatically. This involved updating
the 'cmake_args_qtbase' option by the recipe.
This did not work well with Conan lock files as the alteration of any
option caused:
ERROR: qtbase/6.3.1@qt/everywhere: qtserialport/6.3.1@qt/everywhere
tried to change qtbase/6.3.1@qt/everywhere option cmake_args_qtbase
to '...' but it was already assigned to '...'.
Remove the part where the 'cmake_args_qtbase' value is being altered
but keep it where it is being utilized when aggregating the virtualenv
attributes.
Pick-to: 6.3
Change-Id: Ib7fb1b7cf1b77ee4b5db5646d3be829bc3d1113f
Reviewed-by: Toni Saario <toni.saario@qt.io>
Replace it with floor and round. It appears the old behavior
was to work around combining ceil with inaccurate FP, but
it doesn't appear this hacky ceil is needed.
Change-Id: I5c16ec0fa4916e17198a733c46937fde53f2ddb5
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
C++20 constinit acts as a static_assertion that the initialiation of
the object doesn't incur runtime initialization overhead.
Task-number: QTBUG-100486
Change-Id: I818f5ca9703273cd41e44e5ce7085cb5c643ca8e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There's no reason it has to be done THAT early. It was added in commit
aec85a53df to have the selftests (which do
crash) not leave lots of core files around. I could replace it with a
QProcess::setChildProcessModifier() function, but the variable is now
documented in the QtTest manual, so it would be no gain.
Function renamed to reflect its implementation.
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16ebc25df97a98e3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Rename the property to _qt_resource_target_dependency and make sure we
also consider which scope we are getting the source file property from
if the CMake version is recent enough.
Pick-to: 6.3
Task-number: QTBUG-103470
Change-Id: I755413c91bc0bc9033760a888927b60c470c562b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
We will not do a copy+delete if the destination is on another mount
point (in fact, QFile uses QTemporaryFile for the latter). In my
opinion, that's a misfeature in QFile, because such an operation may
need to display a progress bar to the user so they won't think the
application has frozen. But it's too late to change now.
I don't know why QTemporaryFile is different. It might be because it was
used for the atomic materialization of a file before QSaveFile existed
(5.1) but I didn't research to confirm. It's still useful even in the
presence of that class if the file is really temporary (meant to be
removed when the QTemporaryFile is destroyed).
Pick-to: 5.15 6.2 6.3
Fixes: QTBUG-103740
Change-Id: Iba16e8ea451b444ab213fffd16f4461f3f972d8c
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This array has, in the past, silently failed this test
(cf. 5d8f815e10). Make sure it doesn't
happen again.
Change-Id: I26192749d43de4a7add9d14c7ca04391c1799525
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This is just the C++11 version with constexpr added, very useful to,
e.g., statically check sorted-ness of static arrays.
Task-number: QTBUG-103721
Change-Id: I60164e49db1cc3892280a19851e01193e3c1fb2a
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The QGenericPlugin and QGenericPluginFactory header files are mentioned
as the deprecated in sync.profile. The deprecation looks incorrect,
since the generated headers deprecate them selves. Also syncqt.pl
rewrites this deprecation because files are generated as aliases for
the existing kernel/qgenericplugin.h and kernel/qgenericpluginfactory.h
header files.
Change-Id: I469df56a7cd118dfb82cec0f347d5f2fb75cd9bb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The other getXxxF() functions will fill in values in the out
parameters even in case of Invalid cspec. So make getRgbF() behave
consistently, and return the same values as getRedF() etc. do in that
case.
Change-Id: Ibb8b0c9526b43ce61118c04b479328dbe88d0419
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Avoid a full data detach when only metadata changes. This paradigm was
already used one place, and made generic.
Fixes: QTBUG-81674
Change-Id: I605253babc6ad9fc130e19e8cef3812690933ac5
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
We support blocking the event dispatcher thread in two cases:
- secondary threads: wait on a wait condition
- main thread: asyncify suspend
Create abstraction which implements both cases under a common API:
bool QEventDispatcherWasm::wait(int timeout)
void QEventDispatcherWasm::wakeUpDispatcherThread()
Make QEventDispatcherWasm::wakeUp() use the new API.
Also refactor the runOnMainThread functionality to provide several variants
- runAsync(fn): makes an async call on the main thread, from the main thread.
- runOnMainThread(fn): runs fn on the main thread, synchronously if
called from the main thread.
- runOnMainThreadAsync(fn): runs a fn on the main thread, always asynchronously
Change-Id: Ia6ac21a162e6b8ea2d71bacf6085beb9567588b5
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Adding specialHTMLTargets to EXPORTED_RUNTIME_METHODS carries the
obligation to actually use it as well; failing to do so makes Emscripten
stop with a reference error on startup.
However, we can't guarantee that Qt will use it in all cases. The
current usage depends on QGuiApplication being used. Application code
could be using QCoreApplication, or no application object at all.
Detect if specialHTMLTargets is present instead, and then enable the code
paths which uses it if that's the case. This means that apps which want
to use e.g. multiple browser windows can opt into support by making sure
EXPORTED_RUNTIME_METHODS contains specialHTMLTargets.
Change-Id: I81105aa01946602fcf593f170e305d7dc9bad3be
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
These are needed for dynamic linking/ shared library
Change-Id: Ibd01d2b70ecf4afca273d07fafb2a5bd0650cf94
Reviewed-by: David Skoland <david.skoland@qt.io>
Problem detected while investigating a crash of a program using
QT, valgrind was used to detect errors and valgrind reported
"Conditional jump or move depends on uninitialised value(s)"
due to m_exclusive being uninitialized.
Not sure to what extent this fix matters in practice, the crash
turned out to be caused by something else outside QT. But anyway
it seems good to initialize m_exclusive like other things, in the
constructor, and it helps avoiding such warnings from valgrind,
that will make it easier to detect other problems using valgrind
or similar tools.
Amends ac8a1787eb where it looks
like initialization of this member was simply forgotten.
Pick-to: 6.3 6.2 5.15
Change-Id: I3d1637a00b7899eded61c2e4f5f9a1c5041e4f45
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Elias Rudberg <mail@eliasrudberg.se>
An enum variable can legally have values larger than the largest
enumerator, so GCC isn't wrong in warning about accesses out of
bounds. But we know that we don't OR enumerators of this enum
together, so tell GCC, too, by using a Q_ASSUME().
Pick-to: 6.3 6.2
Task-number: QTBUG-103923
Change-Id: I3472fdb19a73a22f04df53a13f809d899613adf5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are no pipelines here of course. That's only for Vulkan.
But the QRhi APIs provide a common interface for retrieving the
serialized blob and pre-seeding the cache with a blob. The OpenGL
backend already implements that interface via GL program binaries.
We can do something similar with D3D, but it's a lot simpler: we
just need to include the bytecode from HLSL->DXBC compilation (i.e.
the result of D3DCompile() calls) and pick up the already present
bytecode and skip the D3DCompile() call when applicable.
Thus the mechanism is now available for Vulkan, OpenGL, and D3D11
as well.
Has no effect whatsoever if EnablePipelineCacheLoadSave is not set at
QRhi create() time.
Also update the related docs.
Task-number: QTBUG-103802
Change-Id: I91f1fb1f471bc7c654e26886a37c283066e842a8
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Says GCC 12 with -sanitize address -sanitize undefined:
qfontengine.cpp: In member function ‘bool QFontEngine::processHheaTable() const’:
qfontengine.cpp:386:65: error: array subscript 4 is outside array bounds of ‘const char [1]’ [-Werror=array-bounds]
386 | qint16 ascent = qFromBigEndian<qint16>(hhea.constData() + 4);
| ~~~~~~~~~~~~~~~~~^~~
qbytearray.h:56:23: note: at offset 4 into object ‘QByteArray::_empty’ of size 1
56 | static const char _empty;
| ^~~~~~
(repeats several times)
The compiler apparently assumes that data() and size() are independent
of each other, and so finds that that constData() may return &_empty,
which is a const char[1].
For some reason, storing the result of constData() in a temporary and
indexing off of that fixes the issue.
Potentially adding Q_ASSUME(d.data()[d.size] == '\0'); in some
strategic place would fix it, too, but would incur runtime overhead.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348
Task-number: QTBUG-103923
Pick-to: 6.3 6.2
Change-Id: Ia6e24e01d1c2a6bd9d91d4d082df9fba0d5c668f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
An aliased line painted directly on top of the top edge of the clip
rect will work fine when there is no scaling, since the coordinates
will snap downwards. When a fractional scaling is applied however, the
main part of the line width will sometimes fall outside the clip rect,
and so the coordinates will snap it outside, and hence it will not be
painted.
Fix by shifting the y coordinate by .5, to place the center coordinate
of the line to the center of the intended pixel.
Fixes: QTBUG-88934
Task-number: QTBUG-96223
Pick-to: 6.3 6.2
Change-Id: I3ab042bc964eac6ce359d40428c4d79cde9cb78c
Reviewed-by: Nodir Temirkhodjaev <nodir.temir@gmail.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Add test of explicitly prepared qcolortransform, this is a state
a transform can get into if used for an image transform.
Also cleans up the test code.
Change-Id: I9445ed114bed0edc790e14024aaae6a42989220b
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
QTestEventLoop is used by QSignalSpy::wait. If tests want to verify
that a signal gets emitted within a second or less, we should use
a precise timer to reduce the chance of timer imprecision breaking
the test.
Change-Id: I2a2ca3bbdcaf032288f1fdc2aecc6afd05a6c76c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
[ChangeLog][QtGui][QPainter] In Qt 5, the predefined brush patterns
would always be transformed along with the object being painted. In Qt
6.0 onwards, they would or would not, depending on the
SmoothPixmapTransformation render hint. Instead of this somewhat
surprising behavior, make the default be untransformed
(i.e. cosmetic), which makes sense when it comes to dpr scaling. For
the cases where one wants scaling, a new render hint is introduced to
enable that: NonCosmeticPatternBrushes.
Change-Id: I2208c7a28af9056d7ab97a529b66bf2d502c3c4f
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QScopedValueRollback has a few users that apply it on QAtomicInt,
which happens to work as QAtomicInt is copy-constructible and its
ctors are implicit.
But that's of course nonsense. We don't need to store the oldValue in
an atomic, nor do we need to pass the new value into the ctor as an
atomic.
So, add a QAtomicScopedValueRollback which works on std::atomic as
well as the Qt atomics, but distinguishes between the reference (which
is atomic) and the value (which isn't), and use it in one of the
users, tst_QList.
Keep it private until we know whether there's an actual need for this.
The test is a copy of tst_qscopedvaluefallback, so the occasional
oddity (like atomic op*=) should be ignored.
Task-number: QTBUG-103835
Change-Id: I3c05b3e51f465698657a02ca5521ed465386e9a6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The \value command supports a [since ...] parameter. We might as well
use it, to standardize how we document when enum members were added.
Change-Id: I68a101e8101f780d0e6607a63723aa1bd837bb56
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
At least for my FreeBSD this makes sense. The default debugger search is
gdb first then lldb on Linux-not-Android and for QNX (qcc is GCC after
all), but lldb first everywhere else.
With LLVM14 from Ports, I get:
$ tests/auto/corelib/tools/qhashseed/tst_qhashseed | head -1
********* Start testing of tst_QHashSeed *********
Config: Using QtTest library 6.4.0, Qt 6.4.0 (x86_64-little_endian-lp64 shared (dynamic) debug build; by Clang 14.0.0), freebsd 13.0
=== Received signal at function time: 1ms, total time: 3ms, dumping stack ===
(lldb) process attach --pid 1782
Process 1782 stopped
Executable module set to "/usr/home/tjmaciei/obj/qt/qt6/qtbase/tests/auto/corelib/tools/qhashseed/tst_qhashseed".
Architecture set to: x86_64--freebsd13.0.
(lldb) bt all
* thread #1, name = 'tst_qhashseed'
* frame #0: 0x0000000800f227c8 libc.so.7`_wait4 at _wait4.S:4
frame #1: 0x00000008003243bc libthr.so.3`__thr_wait4(pid=<unavailable>, status=<unavailable>, options=<unavailable>, rusage=<unavailable>) at thr_syscalls.c:581:8
frame #2: 0x00000008002b9c73 libQt6Test.t.so.6`(anonymous namespace)::StackTraceHandler::generate() at qtestcase.cpp:393:9
[...]
=== End of stack trace ===
Received signal 13
Function time: 1ms Total time: 3ms
Support for Windows left as an exercise for later. The
WindowsFaultHandler code doesn't even call generateStackTrace().
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eba471f58ff3cb
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
So we can mark the bottom page as inaccessible, thus be able to catch a
stack overflow in the handler itself. Our code shouldn't cause
overflows, but it's possible that a chained handler does more work than
expected.
Pick-to: 6.3
Change-Id: I5ff8e16fcdcb4ffd9ab6fffd16eb83a294ab7958
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We don't need two or even three buffers for the current directory. In
the worst case, we had a 260-byte buffer on the stack, a larger one on
the heap (new[]/delete[]) and then a copy of it in QString.
Now, we shall have only one and it could be "gifted" to QFileSystemEntry
via std::move() (requires separate patch to take the QString by rvalue-
ref).
Pick-to: 6.3
Change-Id: Ibcde9b9795ad42ac9978fffd16f2bb2a443697d6
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We've just allocated a buffer of 'size' size, which is bigger than
PATH_MAX, but told GetCurrentDirectory() that its size is PATH_MAX.
Fixes: QTBUG-103852
Pick-to: 5.15 6.2 6.3
Change-Id: Ibcde9b9795ad42ac9978fffd16f2ba2cd8712cb7
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
