Binary search is notoriously hard to implement, and, while I didn't
spend time to prove it, this implementation was probably buggy, too
(any implementation which is missing a ±1 in the loop body is
suspicious).
Replace with a call to std::lower_bound(), which has precise semantics
and no bugs.
Task-number: QTBUG-103721
Change-Id: Ibe12c7d20b8c01e19a6f294f6c1b564b6b484b07
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Consequently, remove the corresponding comment.
Need to mark the array as constexpr in order to run q20::is_sorted on
it.
Instead of overloading op< (which would be wrong, because there's no
one natural ordering of these entries), write the idiomatic manual
mixed-mode comparator By<FieldName> and use that. A follow-up commit
will use the same function object to replace the hand-written binary
search with a call to lower_bound().
Task-number: QTBUG-103721
Change-Id: I47743b5620dc3cece73b2e5bae658d5a636554dd
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Weirdly, the generator script already has these arrays all as
constexpr...
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-100485
Change-Id: I66d54e097cac1fb6399adfeac155f1e46ff525de
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's the same as locale_data, so use that directly. Saves one
relocation.
Pick-to: 6.4
Task-number: QTBUG-100536
Change-Id: Ic731ad0acfebf10cdf848fc351c08c6536438c62
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
While it's true that the typical user of the function won't expect
more than half a dozen repeats, this function is fed with
user-supplied input, so it could be asked to return in excess of
INT_MAX matches. The truncation then means we're misreporting the
number mod INT_MAX, which is as good as a random number and leads to
false positive matches in users of the function.
Just return the true result instead of a truncated one.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-103531
Change-Id: I5e3aa23dec873c6f9af255e90748fb38619d2f5d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Avoids repetition of if (d->dirty) d->init() all over the place.
Pick-to: 6.4
Change-Id: Ifc819151b7c694e6cc1f48bbb837b37d108ca49a
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Less impedance mismatch with the other Qt containers.
As a drive-by, fix code style in the touched lines, and remove
superfluous inline keywords.
Pick-to: 6.4 6.3
Change-Id: I2c9444a8f956e58c361104a19f55fcc783cd1a1d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Cpp.ignoretokens, Cpp.ignoredirectives, falsehoods are not
used anymore by clang based qdoc.
Most defines are not needed, either, because clang based qdoc
will get these defined by scanning the normal headers. And QDOC,
Q_CLANG_QDOC is actually set by qdoc itself.
What's left is Q_GUI_LIB, Q_WIDGETS_LIB, which is used in headers
modules to make some API conditionally available. Finally, there's
QT_KEYPAD_NAVIGATION, which seems to be a Qt 3 thing, but still
some documentation depending on it ;)
Pick-to: 6.4
Change-Id: Ib9cf0debac8d569cc21271087168a46c0f8635ca
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
We truncated the qsizetype result of countCharHelper() to int.
Fix by removing the int cast.
Fixes: QTBUG-105027
Pick-to: 6.4 6.3 6.2
Change-Id: I5ef35a6f36b0957d31036f70b5286db034e89a28
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
- add move special member functions (docs copied from QHostInfo)
- add member swap
- use move-and-swap, not pure-swap, because these objects hold
resources (handles) other than just memory
- Q_DECLARE_SHARED (it's not implicitly shared, but explicitly)
- adds ADL swap and Q_DECLARE_TYPEINFO
[ChangeLog][QtOpenGL][QOpenGLBuffer] Added member-swap(), move
constructor, move assignment operator.
Change-Id: I22dc92108bdd393fff4361db23e94eaf3d7ea9cc
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
While the function is inline, the class is exported wholesale, so the
function forms part of the ABI on Windows (but not Unix), so we must
overload, can't replace.
To avoid ambiguities where users pass different integer types as the
lengths of the LHS and RHS strings, QT_REMOVED_SINCE the old overload.
Since the removed function has an inline definition, it suffices to
just include the header into the corresponding QT_REMOVED_SINCE
section of the removed_api.cpp file, to elegantly solve the BiC
problem only for those platforms (MSVC) where it matters.
Pick-to: 6.4
Task-number: QTBUG-103531
Change-Id: I74d446f08fcd6247a2ec44575b8afef8d014c3b5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's not used and not useful.
The macro itself has to stay, for now, because Qt5Compat uses it, too.
Task-number: QTBUG-100861
Pick-to: 6.4 6.3 6.2
Change-Id: I5d0557a6c959d6facf6e47f26786a9d365339e95
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We have in the past found ourselves in need of disambiguating new
overloads from older, QT_REMOVED_SINCE'ed ones, which we usually did
by adding a defaulted int argument, cf. e.g. QMetaType::id().
The problem with a defaulted int argument is twofold: First, an int is
a valid argument type, and users may get confused as to its meaning
when presented with the signature in the IDEs auto-completion popup,
and a lot of things implicitly convert to an int, so any errornous
parameter passing may stay unnoticed until we remove these fake
arguments come Qt 7.
Second, this way of doing things requires a lot of ifdef'ery to keep
the additional argument out of both the docs and future Qt 7 builds.
The solution presented in this patch is to create a tag type,
QDisambiguated_t, which a) more clearly communicates its purpose and
b) doesn't implicitly convert from anything.
To help with the invariably ugly ifdef'ery, provide a set of macros
that hide this stuff from qdoc and Qt 7 builds.
Use the macros to replace the fake int arguments that were added for
6.4.
Pick-to: 6.4
Change-Id: I6916f38c8eb9793ad6dea5f61e7e5fff7e75e273
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They're self-contained; callers passing ints will not cause warnings.
Pick-to: 6.4
Task-number: QTBUG-104820
Change-Id: I1dcc1b178b7d72d23dd0596835ab2868c0c6f8c1
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The tst_QByteArray test redefines the QCOMPARE macro to check the LHS
to be NUL-terminated. Because the code was never ported from int to
qsizetype, it fails for QByteArrays of size > 2GiB.
Fix by porting to qsizetype.
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-104985
Change-Id: Ib3951b0efed5f734ae1324ea2d455bb7762fb9c4
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They must be outside the Qt namespace.
Pick-to: 6.4
Change-Id: I3859764fed084846bcb0fffd17030ebc62812e09
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It's required by that misguided QT_DECL_METATYPE_EXTERN_TAGGED that uses
QList. I don't know why it is there in the first place, and will not
investigate.
qmetatype.h:1137:9: error: static_assert failed due to requirement 'is_complete<QList<Qt::DayOfWeek>, void>::value || std::is_void_v<QList<Qt::DayOfWeek>>' "Meta Types must be fully defined"
Change-Id: I36b24183fbd041179f2ffffd17026e01888f5e9a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Happens when we switch to protected visibility.
qjnihelpers.cpp:398:1: error: visibility does not match previous declaration
jni.h:1112:1: note: previous attribute is here
Change-Id: I3859764fed084846bcb0fffd17036098322e6b8d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Or the previous limit, 10.
The test has a flaky and failing history, esp on macOS. Trying to
provoke race conditions with more threads than we have cores has little
value.
Pick-to: 6.4
Change-Id: I99dd2b5a6f64faa83963c279c84fc547416f914f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Make the hack less hacky by letting the style polish the widget (it does
already for the font) to set a dynamic property that the button can
test. Use the available palette entires ButtonText and BrightText to set
the dark blue and bright blue colors, rather than hardcoding them in the
widget code.
Pick-to: 6.4
Change-Id: Idfb3b7d18e456a9d14af4962cf723e12ff1c3370
Reviewed-by: Doris Verria <doris.verria@qt.io>
QColorTransformPrivate::simpleGammaCorrection is not implemented
anywhere, so remove the declaration.
Pick-to: 6.4
Change-Id: I07debd84e49389a0f1ef1b3798f809447a342f3a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
43ef22045c turned dark mode support on for
both styling and window frames. However, the default palette and style
support in Qt is too incomplete, resulting in unreadable UIs when using
certain styles (e.g. fusion). Also the vista style is not supporting
dark mode.
If we don't turn on dark style support, then dark frame support doesn't
look good either. However, many application developers have implement a
dark theme themselves, and we should have a dark frame for those
applications.
So partially revert 43ef22045c so that
dark style support is disabled by default, and leave dark frame support
on. However, only activate dark frames if the palette is dark, i.e. if
the window background color in the default palette is darker than the
text color (or if DarkModeStyle is explicitly turned on by running the
application with -platform windows:darkmode=2).
This way, dark-themed applications get a dark frame on dark Windows, and
a light frame on light Windows; and light-themed applications (including
default Qt applications) get a light frame all the time.
Fixes: QTBUG-72028
Pick-to: 6.4
Change-Id: I61f1b1e43b2a4ba69848d5d8bec921c0790fe511
Reviewed-by: Marius Kittler <mariuskittler@gmx.de>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
When a Qt component or dependency is not found, we will now show a
message that the user can reconfigure the project with
-DQT_DEBUG_FIND_PACKAGE=ON.
If the option is enabled, various variables that find_package uses to
find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be
recorded before each find_package / find_dependency call that is
executed in any of the Qt package files.
If any find_package call fails (a package has its _FOUND variable set
to 0), the values of all those recorded variables will be shown.
This is useful to troubleshoot issues, especially when
cross-compiling, without having to manually modify the various
Config files.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Depending on CMake version suggest usage of either
--debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot
why dependent packages are not found.
To achieve that, append the hint message to the _NOT_FOUND_MESSAGE.
To ensure it works for qt dependencies, and not only tool and 3rd
party dependencies, _qt_internal_find_qt_dependencies
is modified to set variable names infixed by the target name, so the
name is consistent with the other dependency lookup functions.
The check and message are also added when a Qt6 component is not
found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
So far we always recommended that developers set CMAKE_PREFIX_PATH to
point to the location of the Qt installation so that Qt packages are
found by CMake.
In Qt5 one could also set the Qt5_DIR variable to $qt/lib/cmake/Qt5
to allow the following signature to work:
find_package(Qt5 COMPONENTS Core)
This was not sufficient in Qt6 because the CoreTools dependency would
not be found.
Fix this by also looking into the parent folder of
CMAKE_CURRENT_LIST_DIR as well as _qt_cmake_dir, like we already do
for regular non-Tools packages in _qt_internal_find_dependencies.
Note that setting Qt6_DIR is not sufficient for cross-compilation if
the qt.toolchain.cmake file is not used.
Aside from platform specific options that would have to be passed
manually to CMake (like -DCMAKE_SYSTEM_NAME=iOS for iOS) and
passing a QT_HOST_PATH value, the code would also need to be
adapted to do the necessary CMAKE_FIND_ROOT_PATH manipulations
to ensure that dependent packages are found.
Pick-to: 6.4
Task-number: QTBUG-97615
Change-Id: I10c419632d43bb929e184bab3b9d3d27a35ea87a
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When a package's tools dependency is not found (e.g. Core's CoreTools)
set the _NOT_FOUND_MESSAGE variable the same way that find_dependency
does.
We can't use find_dependency directly because that returns immediately
without allowing us to reset the prefix paths vars.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I81e9817de8f30214fafbefe3d98ef7bc8848e715
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If find_package(Qt6 REQUIRED COMPONENTS Core) is called, don't
propagate the REQUIRED option to all the dependencies of Core,
regardless if it's a 3rd party library, tool or another Qt package
dependency.
Propagating REQUIRED causes the find_dependency -> find_package call
to exit the calling file immediately when the package is not found,
not giving an opportunity for find_dependency to set the
_NOT_FOUND_MESSAGE variable.
Instead force all find_dependency / find_package calls
to be optional, set the calling _FOUND variable to FALSE if the
dependency is not found, also set the _NOT_FOUND_MESSAGE variable.
Then the find_package call that loaded FooModuleConfig.cmake file
will show that message as the reason for the package not being
found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Idcf0b6ed6f6bb38dc082110bbd817b05e287c052
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If a project calls find_package(Qt6 COMPONENTS Gui Network) and Gui is
not found, there's no reason to look for Network, because the
COMPONENTS option implies that it is a required component. Failing to
find a component sets Qt6_FOUND to false, so we can break early.
If a project calls find_package(Qt6 OPTIONAL_COMPONENTS Gui Network)
then Network will still be looked for if Gui is not found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I5c5edd27729635e6b7ade059656b49320364ad13
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use _qt_internal_find_third_party_dependencies instead.
We rely on the inner find_dependency call to set the
Qt6_NOT_FOUND_MESSAGE message when a dependency is not found.
This implies removing the custom FATAL_ERROR handling
and relying on the parent find_package to display the
Qt6_NOT_FOUND_MESSAGE message.
We also clear Qt6_FIND_COMPONENTS if a dependency is not found.
No need to look for Qt packages if the Qt6 dependency was not met.
This reduces the amount of recursive error messages.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I5c611aaededfa63eb507ec5385b37a2fb6fcc698
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Aside from moving the code to reduce duplication, the only changes in
the code are the replacement of @target@ to ${target}, using IN LISTS
with variable names to avoid macro expansion issues and replacing
the if(var) conditions with double variable evaluation
+ NOT STREQUAL "".
The function implementations are now in the same order as they
are used in the Dependencies.cmake files.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Iaae926414fd2a7cc09c2f5716376caaa0aade74b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
It was accidentally left when changes were made from patchset 1
to patchset 2 in 825cb50c27
Amends 825cb50c27
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I04dd50cfb93655f0c224bb226695e7771e9bc5d1
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
And update the default version number to 1.0, which more closely matches
the Xcode default.
Pick-to: 6.4
Change-Id: I2cd785fffe8b960e5fa5db4803eaeee10791b7aa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This provides a better user-experience, as the two settings have
dedicated fields in the project UI, and matches how new projects
are generated by Xcode itself.
Pick-to: 6.4
Change-Id: I23acc7c6506f1818ef4a90f6f595bc449f83c57b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A UI in dark mode will have a dark background. Pick a light color to
draw the notches. Since in the mac style, the dark mode's 'dark' color
is lighter than the 'light' color, pick whichever is lighter.
Pick-to: 6.4
Change-Id: I333ea95b80d7a19504000877337b28839b4a8b9f
Reviewed-by: Doris Verria <doris.verria@qt.io>
That test has a very flaky history on Windows 11, presumably because
there are even more fade-in/out effects. Wait longer for those to
finish.
Fixes: QTBUG-102239
Pick-to: 6.4 6.3 6.2
Change-Id: I1d59f4422469e60a8c4dc5a52c48f0344e954491
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Holding on to the memory we've just allocated could only make sense if
we supported resuming parsing, but I haven't implemented that feature
yet.
Pick-to: 6.2 6.3 6.4
Change-Id: I36b24183fbd041179f2ffffd1700cf7e3558040f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
We don't promise we're very good at handling exceptions.
Pick-to: 6.4
Task-number: QTBUG-104718
Change-Id: I89c4eb48af38408daa7cfffd16fdcc171db437bd
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We were allowing up to 1 million elements for each array, which meant 16
MB (32 for maps), and we considered that sufficient. However, because we
do allow up to 1024 levels of recursion, the memory consumption was
actually limited to 16 GB (32 for maps), which is a bit too high for
64-bit applications, and definitely too high for 32-bit ones.
So further clamp down, to a mere 16k elements on 32-bit and 64k on 64-
bit, which limits the memory use to 256 MB on 32-bit and 1 GB on 64-bit.
And additionally apply this exact limit to maps, instead of allowing
them to double the size.
As before, this does not limit the size of non-corrupt streams. This
only limits the initial memory pre-allocation.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104718
Change-Id: I89c4eb48af38408daa7cfffd16fdcb34f08c1949
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Amends 8932e80d0c to make implementation
match docs: the ! went missing during repeated patch rebasing, apparently.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-101932
Change-Id: I3fe910774f5bdf4ab0342a9cf1994bb489f20e87
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
fork() works by implementing Copy-On-Write for all pages that either the
parent or the child process write to. So if the parent process continues
running while the child is between fork(2) and execve(2), then it will
keep causing page faults and requiring the OS to duplicate those pages,
which may be expensive (page table updates, TLB flushes, etc.). This
problem is aggravated if the parent process is multithreaded, as the
simple act of running in the parent will cause those threads' stacks to
cause page faults.
The BSD solution for that was vfork(), which has two differences in
behavior: (1) it blocks the parent from running and (2) it shares memory
with it. But it's always been tricky, so POSIX.1-2001 deprecated it and
2008 removed its definition completely. Still, it is available somewhat
widely, and on Linux that can be achieved with clone(2) and the
CLONE_VFORK and CLONE_VM flags, for those two behaviors respectively.
Because of (2), we can't return from the forkfd() function in the child
(as that would trash the stack in the parent process), so to implement
this functionality vforkfd() adds a callback of the same signature as
glibc's clone(2) wrapper (something that hadn't occurred to me when we
attempted to use CLONE_VFORK last time).
On Linux, (1) is no problem, as clone(2) has native forkfd support. But
on other OSes, forkfd() requires the parent to run before the child
execve()s, in order to save the child PID in the list of children we're
going to handle SIGCHLD for in a non-racy way. Investigating if it is
possible to use vfork() anyway is left as an exercise for the reader.
Matching OpenDCDiag pull request:
https://github.com/opendcdiag/opendcdiag/pull/94
Pick-to: 6.4
Fixes: QTBUG-104493
Change-Id: Id0fb9ab0089845ee8843fffd16fa63c7c6f7dd1c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When a window is being dragged, we should not check for the target
window's resizability in QWasmCompositor::processMouse as:
1) the target window under the cursor might be different from the
dragged window when the pointer is moving quickly
2) we have checked that already when qualifying the window for dragging
when handling EMSCRIPTEN_EVENT_MOUSEDOWN at line 1022
Therefore, the condition for target window's resizability has been
removed.
Change-Id: Ib999d213f1e0a770fa76324fc7bf44c6d4ab806a
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Do it in preparation for other changes around gadget type traits, for
porting qtdeclarative to the new API.
Change-Id: I91cd5aff81a678565cdf1b7e0b57f52bae8a1a80
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
OpenSSL v3 fails to set server's certificate, complaining that
"md is too weak".
Pick-to: 6.4 6.3 6.2 5.15
Fixes: QTBUG-49205
Change-Id: Ib21b10ff13bc2621ae2aaaab962efaaf77a854bc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
