The errors attribute on the <testsuite> element represents the number of
<error> elements, but we do not produce any at the moment.
Pick-to: 6.2
Task-number: QTBUG-95424
Change-Id: I7196d622a9a6bbb7e79ed2c2886984d539abb1da
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
539553a572 renamed the LET_Error element
enum to LET_Message, without renaming the corresponding "error" element
name. This was not an issue in practice, since we never write the actual
element in QTestJUnitStreamer, but the two should be in sync to avoid
any confusion.
Pick-to: 6.2
Change-Id: I6c29f5303393b5f36b2f9877940bf3f6eaf3b7d2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The original Ant JUnit reporter produced test durations via Double.toString(),
supporting arbitrary precisions, and the de-facto schema declared them
as xs:decimal.
Sadly, the now popular Maven Surefire reporter limited the duration to
millisecond precision, and hard-coded this into its schema as SUREFIRE_TIME:
https://issues.apache.org/jira/browse/SUREFIRE-1533
Unfortunately this definition spread into tools such as the Jenkins xUnit
plugin, which relies on the schema provided by Maven Surefire:
https://issues.jenkins.io/browse/JENKINS-52152
As a result, anything that produces higher precision results will not
validate in the Jenkins xUnit plugin.
Other test frameworks have bitten the bullet and reduced their precision
correspondingly, e.g.:
https://github.com/catchorg/Catch2/issues/2221https://github.com/catchorg/Catch2/commit/581c46249acf8389e9
We follow suit, and our JUnit XML output now validates against both
the Jenkins JUnit and xUnit plugins, as well as the original Apache
Ant de-facto schema.
Pick-to: 6.2
Task-number: QTBUG-95424
Change-Id: I3097d10c03c2a29709960372301b29055d224e10
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The JUnit test framework did not initially have any XML reporting
facilities built in. Instead, the XML report was generated by the
Apache Ant JUnit task:
https://github.com/apache/ant/search?q=filename%3AXMLJUnitResultFormatter.java
Many users interacted with these reports via the Jenkins JUnit plugin,
which provided graphical visualization of the test results:
https://plugins.jenkins.io/junit/
Due to the lack of an official XML schema for the Apache Ant JUnit
report there was some confusion about what the actual format was.
People started documenting the de-facto format, both as produced
by Ant, and as consumed by Jenkins:
https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsdhttps://github.com/junit-team/junit5/search?q=filename%3Ajenkins-junit.xsd
The XML produced by the Qt Test JUnit reporter was far from these
schemas, causing issues when importing results into tools such
as Jenkins, Allure2, or Test Center.
The following changes have been made to improve conformance:
- The 'timestamp' attribute on <testsuite> is is now in ISO
8601 local time, without any time zone specified
- The 'hostname' attribute on <testsuite> is now included
- The 'classname' attribute on <testcase> is now included
- The non-standard 'result' attribute on <testcase> has
been removed
- The non-standard 'result' attribute on <failure> has
been renamed to 'type'
- The <system-out> element on <testsuite> is always included,
even when empty
- The non-standard 'tag' attribute on <failure> has been
removed. Data-driven tests are now represented as individual
<testcase> elements, e.g.:
<testcase name="someTest(someData X)" ...>
<testcase name="someTest(someData Y)" ...>
<testcase name="someTest(someData Z)" ...>
The resulting XML validates against both the de-facto Apache Ant
'JUnit 4' schema and the Jenkins JUnit plugin schema.
Task-number: QTBUG-95424
Change-Id: I6fc9abedbfb319f2545b99b37d059b18c16776ff
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
- Use the right name for the attribute (AI_Message),
rather than fixing it up in QTestJUnitStreamer.
- Don't pretend that we're adding line and file information,
only to discard it in QTestJUnitStreamer.
- Don't pretend to add benchmark information,
only to discard it in QTestJUnitStreamer.
Pick-to: 6.2
Change-Id: Ib6eadc12300157216fe9c6e8bcfebd7eb8a3ea68
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
... and use one variable definition per line.
Change-Id: Ie8e6d6fb9e570cf715ab0b39c78d677f1e5a19a7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The name coincided with one used in other functions for a different
meaning and its initialization was clumsy. Rename to a terser name
that communicates the relevant matter more clearly.
Change-Id: I6baf8e5ec695cbbb1cc10f6c4b4cc6512c1aefc4
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When checking whether a floating-point value is "inf" or "nan", the
code actually only checked they *started* with those. Check the
length first and thereby avoid the check when the string is longer in
any case. This incidentally avoids tripping over any string that
merely starts with "inf" or "nan" - such a string should not be able
to arise here; but we still shouldn't give it the special treatment
reserved for these two, were one to arise. Add an assertion to the one
remaining branch that wouldn't have caught such a malformed string.
Change-Id: I63828e3a99a33cf236e4d1a2e247ad832b7a00fd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The xpm_color_name() function returned a pointer to a function-static
buffer. This is infamously non-reentrant, and an actual problem,
because we explicitly allow QImage operations (incl. saving to an
.xpm) from non-GUI-threads.
Fix by using the CSS pattern (Caller-Supplied Storage; also used in
the QAnyStringView(char32_t) and QAnyStringView(QStringBuilder) ctors)
to force the caller to allocate storage in its own stack frame. As a
consequence, we re-gain re-entrancy, but the returned pointer is now
only valid until the end of the full-expression, which necessitated
simplifying one caller (sorry!).
To see why said simplification is valid, observe that xpm_color_name()
writes a (now-explicit) NUL into returnable[cpp] and the old code read
max(cpp, 4) characters from xpm_color_name()'s result.
NB: cpp can be 5, even though the code comments say otherwise! :(
[ChangeLog][QtGui][QImage] Fixed a race condition when concurrently
writing .xpm files.
Pick-to: 6.2 6.1 5.15 5.12
Change-Id: I36d7173d53839a52f5cdf58324474c1b32c71f33
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
It makes no sense for the event loop of a test to keep running after a
test has failed. This lets test code simply use the usual testlib
macros to compare and verify values in asynchronous tests that would
otherwise need to hand-test values and send a signal on failure (that
the main test can connect to an event-loops quit() or equivalent).
For example, QLocalSocket's benchmark simply uses the usual macros,
without doing anything to stop its event loop if they fail, with the
sad result that, when a test fails, it does so repeatedly and then
times out, causing the test program to be killed without running later
tests. With this change, that test code (once converted to use
QTestEventLoop) is able to exit gracefully on the first failure.
[ChangeLog][QtTest][QTestEventLoop] The QTestEventLoop new exits its
event loop as soon as the test is known to be failing.
Task-number: QTBUG-91713
Change-Id: If0d455741668722034906763025dda496d2afbb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Oliver Wolff reports that this test no longer hangs on Windows; and
the other plafroms for which it was skipped are no longer supported,
so remove the #if-ery that skips this test for platfroms on which
uncompressing corrupt data used to hang.
Change-Id: I94a3fd4b83338fe6e3a97ab055fe05e2f15b6b45
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Move out and share the test data from the QString::number_double() test
and re-use it for this one.
Task-number: QTBUG-88484
Change-Id: I6502d1d360657f6077e5c46636f537ddfdde3a83
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The comments in the declaration of the pair screamed "I want to be a
struct with properly-named member variables", and the code that read
it->first and it->second was really misleading to STL-aware readers.
Fix by defining a small struct with member names taken from unmap()'s
use of the pair's fields.
Change-Id: Ie18852a3147f65cf14cfc5a3bb633f7b3e78f5a2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
lupdate cannot parse .mm files. Therefore tr markup must be inside of
C++ files. This copies the same approach qtconnectivity uses, see
6b2fd04b7be4494767b6092a030607010d91310c
Pick-to: 6.2
Change-Id: I9853864b4b81b48da763a387c78c102857f23047
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Because there's no insertIfNotContains()-like functionality in QHash
(unlike std::unordered_map, where insert() doesn't overwrite an
existing entry), the code first called contains(k) and then insert(k,
~~~), causing two lookups in the case where the insertion actually
happens.
Fix by using the pattern QDuplicateTracker's QSet fall-back uses, too:
recording the size before and after the call to the indexing operator
and using a size increase as the criterion that an insertion should
happen. This reduces the number of lookups to one, at the cost of a
mapped_type default construction (which, given mapped_type is
std::function, should be cheap).
Change-Id: I24b31107b3e26f2eea2edce7b46f8cb5e7cb35bf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The test was producing a warning about the invalid test, for which
replace_regexp() had anticipated that warning; do the same in
remove_regexp(). The two tests shared a date() method, but the remove
test was a no-op on the tests with non-empty replacement text; move
the column set-up and data rows with empty replacement to remove's
data() function, from replace's, and reverse the direction of calling
each other between data() functions, so each test gets the cases that
are relevant to it and no spurious PASSes happen for no-op tests. In
the process, give moved test-cases informative names; relocate the
(entirely re-written) remove data function to beside its test; and
eliminate a pointless local variable from both tests (it used to be
needed when testing both QRegExp and QRegularExpression).
Pick-to: 6.2
Change-Id: I93dcfc444f984edf5c029f99306aff6bc95d554a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The code to work around setlocale() mis-describing en_US as C ensured
that we didn't accept the C test-cases when the locale was really
en_US; but neglected to accept the en_US test-cases when the locale
really was en_US but was misdescribed as C. This lead to no tests
being run when the locale was en_US.
Tweak the logic of the test filtering to compare the wanted locale
against the system locale both when C is wanted and when it isn't.
Make the skip-messages a little more informative.
Pick-to: 6.2 6.1
Change-Id: I4e072e12819144b2941b87a5f486534047d9a579
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To retain backwards compatibility with some QNetworkReply usage,
namely connecting solely to finished-signal and allocating a buffer to
read into, but without storing the entire decompressed file in memory
until read, we may decompress the file twice.
With this patch users can now avoid this double decompression if the
amount of buffered data stays below 10 MiB. This means any file smaller
than 10 MiB will never need to be decompressed twice to know the size of
it. On top of that, if the data is handled as it arrives (e.g. in
readyRead) and the buffer is kept below 10 MiB it won't need to
decompress twice either.
This is active as long as "countDecompressed" is true, though it
currently always is in QNetworkAccessManger, with a future goal to make
it possible to control with public API. Since it requires the user to
potentially adapt their usage of QNetworkReply.
In this patch we also stop tracking the amount of unhandled uncompressed
bytes (uncompressedBytes) in favor of tracking the total amount of bytes
which has been read() by the user of QDecompressHelper (totalBytesRead),
since we can more intuitively work out the total amount of unread bytes
using this value.
Change-Id: Ie3d8d6e39a18343fcf9b610f45c7fe7e4cd4e474
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We will not gain anything if we have to do multiple function calls to
obtain the thread id. Therefore we introduce a macro to signal that we
have a fast implementation of currentThreadId, and only use the function
if it is defined.
Pick-to: 6.2
Change-Id: I3347489ea91992896bb753b796ae26e391c2c99c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If we already have the bindingStatus, we can just pass it along.
Pick-to: 6.2
Change-Id: Iaaea4f4c34e6a786899561293016ece163c26d25
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- Provide an inline version of evaluateRecursive which does not fetch the
status.
- Provide an unsafe variant of setBindingToNotify which does not set the
tag. This can be used in allocateDependencyObserver, as newly
allocated observers already have the correct tag (this is checked via
an assert).
Pick-to: 6.2
Change-Id: I31aec6af4aef244efc6d0777e5bfaaa8f82f2046
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The method is only called in two places: observerProperty (which only
takes care of calling unlink, too, if necessary) and in
registerWithCurrentlyEvaluatingBinding_helper. In the first case, the
method most likely gets inlined anyway. In the latter case, we really
want to avoid the overhead of an additional function call to speed up
registration of the property with the binding. Considering that it is an
internal method, there is no need to worry about code explosion.
Pick-to: 6.2
Change-Id: I3f0f0e37108f3859321d3b432e37fc8da3c15dc0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This avoids another round of TLS lookups in evaluateRecursive when we
construct the BindingEvaluationState.
Pick-to: 6.2
Change-Id: Icfa9fd81fc6f54623d384c4d3fce33f4d4d549b9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
- Ensure that the allocateDependencyObserver fast path is inlined.
- Use addObserver instead of observerProperty; we know that a freshly
allocated observer does not have its prev pointer set. If prev weren't
a private member, we could simply use Q_ASSUME(ptr->prev == nullptr),
but making it public or befriending the class seems like a bad idea,
as it grants too much access to the internals.
Pick-to: 6.2
Change-Id: Ia845f2807c70512563f7b9e1ecb85fe82b66208c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If we have no currentBinding, then registerWithCurrentlyEvaluatingBinding
will not do anything. Thus we can completely avoid fetching the storage.
Pick-to: 6.2
Change-Id: Ic20142e4c4e09752b5c41b959f66080e6885e6c3
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
By putting the groupUpdateData pointer into the same thread local as the
binding status, we avoid having to fetch two thread_local variables.
Moreover, we can reuse the caching mechanism which we have in place for
QBindingStatus to avoid costly TLS lookups.
Pick-to: 6.2
Change-Id: Iaea515763510daab83f89b8e74f35a80965d6965
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If the QBindingStatus we receive from the QObject is from the thread
which is currently running, we do not need to refetch the thread local;
the reason we refetched the thread_local was after all only to guard
against the case where a QObject's property gets read in a different
thread.
To determine whether we are in the same thread, we can store the thread
id in the thread_local structure. Currently, it only gets initialized
for the main thread in QCoreApplication (as bindings are mostly used
there).
At a later point, we could either expose initBindingStatusThreadId, or
call the function when a QThread gets started.
Pick-to: 6.2
Change-Id: Id8eb803973bb083abfab83a62bfccc9e88a4e542
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We try our best to pass on the file location of a failure, including for
fatal errors, but the reporting or logging machinery should not assume
there is one.
By passing on nullptr for the file location we allow the logging backends
to decide how to handle the situation, e.g. by not emitting extra fields
for failure location.
This effectively reverts c25687fa0b,
in favor of relying on the backends to cope with null filename,
which they already did.
As qFatal uses QMessageLogger, which by default disables file/line
information in release builds, we need to explicitly enable this in
our self-tests, to get uniform test results. Similarly, we disable
file/line info from testlib itself, as reporting Qt internal file
and line information for user diagnostics is less useful. The odd
one out there is qtestdata.cpp, which still ends up in test output
due to using QTEST_ASSERT instead of qFatal for its diagnostics.
Cleaning up that, and unifying how we report testlib issues to the
user, is left for another day.
Pick-to: 6.2
Change-Id: Ib9451b8eed86fe3ade4a4dcaf0037e1a3450321c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QtTest best practices documentations recommends using output
mechanisms such as qDebug() and qWarning() for diagnostic messages,
and this is also what most of our own tests do.
The QWARN() macro and corresponding internal QTest::qWarn() function
was added when QtTest was first implemented, but was likely meant as
an internal implementation detail, like its cousin QTestLog::info(),
which does not have any corresponding macro.
This theory is backed by our own QtTest self-test (tst_silent)
describing the output from QWARN() as "an internal testlib warning".
The only difference between QWARN() and qWarning(), besides the much
richer feature set of the latter, is that qWarning() will not pass
on file and line number information in release mode, but QWARN() will.
This is an acceptable loss of functionality, considering that the user
can override this behavior by defining QT_MESSAGELOGCONTEXT.
[ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning()
Pick-to: 6.2
Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This function is called by qt_add_executable. There is no need to
expose it as public function.
Fixes: QTBUG-95172
Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change introduces new behavior to error out when configuring user
projects if the CMake version used is too old for Qt to work with.
The main motivator is the requirement of new CMake features to ensure
object libraries are placed in the proper place on the link line in
static builds.
The minimum CMake version is computed based on whether Qt was
configured as shared or static libraries.
At the moment the required versions for building and using Qt are the
same.
The minimum versions are defined in qtbase/.cmake.conf in the
following variables
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED
QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC
Qt Packagers can disable the version check when configuring Qt
by setting
QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and
QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT.
In this case it is the packagers responsibility to ensure such a Qt
works correctly with the specified CMake version.
User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT
to disable the version check. Then it's the project's developer
responsibility to ensure such a Qt works correctly.
No official support is provided for these cases.
Implementation notes.
The versions required to build Qt are stored in
QtBuildInternalsExtra.cmake
whereas the versions required to use Qt are stored in a new
QtConfigExtras.cmake.
Also the policy range variables stored in
QtBuildInternalsExtra.cmake are now regular variables instead of cache
variables, to properly allow overrides per-repository.
Some renaming of functions and variables was done for a bit more
clarity and easier grep-ability.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Building a static library Qt configuration will now require a
minimum CMake version of 3.20.
Qt builders and packagers can still opt out of the mentioned minimum
required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION.
Such a Qt configuration is /NOT SUPPORTED/.
To facilitate these changes, the minimum version check has been moved
to happen after the BUILD_SHARED_LIBS option is computed by either
QtAutoDetect.cmake or set by a user provided cmake toolchain file.
Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable
in .cmake.conf to mark the minimum version for a static Qt build.
Pick-to: 6.2
Task-number: QTBUG-95018
Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Craig Scott <craig.scott@qt.io>
In order to filter out file names based on the user's settings,
QFileSystemModel used to have a loop that tested if a given file
name matched one of the filters. The problem is that each filter
(a wildcard) was converted to a QRegularExpression _inside_ the loop.
This causes a quadratic behavior (number of files * number of filters).
Instead, build the regexps once when the filters are set (or the case
sensitivity is changed, as that affects the filtering), and simply
_use_ them in the loop.
Simplify and correct some related code as a drive by.
Done-with: Jean-Michaël Celerier
Fixes: QTBUG-95383
Pick-to: 6.2 6.1 5.15
Change-Id: I6bc336364c145bb05793a8f867545d7715d35832
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The port from hand-rolled function storage to std::function
inadvertently removed the helper variable of static storage duration
whose dtor would unregister the conversion function. This caused
QTBUG-94831, where the cleanup of conversion functions attempts to
call code (via std::function) from a library that has already been
unloaded.
Restore the 5.15 behavior by adding a static-storage-duration scope
guard to unregister the conversion and view functions from Qt upon
library unload (when static objects are destroyed). Unlike 5.15, only
install the scope guard upon successful registration, ensuring that
only the DLL which successfully registered its conversion function
unregisters it again.
Amends 0e4ae4fbf8.
Add some strategic std::move()s as a drive-by.
Pick-to: 6.2
Task-number: QTBUG-94831
Change-Id: I391ca667420cf0d98a166676b9bb363d6e190306
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of contains(), 1-2x operator[](), and remove(), equalling 3-4
separate lookups, use find() + erase(), which does just one
lookup.
Since our erase() function is C++11-compliant these days and takes
const_iterator instead of (mutable) iterator, we can use the const
find() overload to delay a detach (attempt) until we actually erase().
Change-Id: I8e67a48e221e548528049fa093ab7ef2f1802f7e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move the documentation of the format and precision parameters to
QLocale::toString(double, char, int), reference it from various
QString methods (instead of repeating there and referencing one of
those from QLocale). Add brief first lines for various documentation
comments.
Mention the special handling of negative precision in the moved
documentation. Mention QLocale::FloatingPointShortest, add its type to
\sa lines of methods it affects. Change a comment on some code
implementing its special treatment to make clear that it does apply to
'e' and 'f' formats, not only to 'g', even though it has no overt
special handling in that code; and update docs to report the
undocumented behavior the comment previously described.
Document how infinity and NaN are represented. Be somewhat more
consistent about single-quoting the format names where referred to and
applying \c to character constants.
Make clear what things are different between different methods using
these parameters. Reference QString::number() from QByteArray's
relevant methods, since they share its quirks.
In the process, rename the format and precision parameters of relevant
functions so they're consistently named, replacing a mixture of
abbreviated forms.
Pick-to: 6.2
Change-Id: I077521b30346000e4b4f6968a8e750e934f72937
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Because we're using a thread-specific global static, we need to recreate
the QCollator type every time setDefault() is called. Since one is
stored per-thread, we simply increment a generational counter and check
that the next time that QString::localeAwareCompare is called in each
thread.
The issue was introduced on f6425da424
(5.12) even though we were supposed to be using QCollator since commit
5279134935 (5.3).
Fixes: QTBUG-95050
Pick-to: 6.2
Change-Id: I7e0b82c2d2fe464082d8fffd1696a8c9f74e5b30
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
USE_COMPARESTRINGEX is not defined anywhere. Its definition was removed
by commit 45b0f1be68 ("Remove winrt").
Change-Id: I7e0b82c2d2fe464082d8fffd1696a931fa301986
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This follows up on commit 98666c8afc,
which did the same for QString. If someone wants to get formatting
suitable to an unsigned value, they can cast the value to that
unsigned type and the correct overload shall pick it up.
[ChangeLog][Important Behavior Changes] QByteArray's formatting of
negative whole numbers to bases other than ten now, like QString's
(since Qt 6.0), formats the absolute value and prepends a minus sign.
Task-number: QTBUG-53706
Pick-to: 6.2
Change-Id: I91fee23d25ac0d5d5bcfcbeccbac1386627c004a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use _qt_internal_set_up_static_runtime_library() to set correct MSVC
runtime library for targets created by qt_add_executable(),
qt_add_library(), qt_add_plugin() and qt_add_big_resources(), to bring
convenience to user projects.
Pick-to: 6.2
Change-Id: Ia49f1e90989c464820824be3e1eef3df1351cdcf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends 3224c6d7d1 to account for the
case when the dockwidget is already floating.
Task-number: QTBUG-70137
Pick-to: 6.2 6.1 5.15
Change-Id: If8b345565b11b44beb3fb4b697cfe812c29c6396
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
One is a bad application or library in this case, but nonetheless
we should handle this more gracefully then just crashing due to
the QRhi already having been destroyed. Mainly because in Qt 5 one
could get away with the same: releasing OpenGL objects underneath,
for example, a QSGPlainTexture with no (or wrong) GL context did
not generate any user visible fatal errors. So we should not crash
in Qt 6 either with these code bases.
In debug builds or when QT_RHI_LEAK_CHECK is set, one will get the
unreleased resources warning printed in Qt 6, which is a step
forward compared to Qt 5. So there is still some indication that
something is badly designed, even if the application survives.
Task-number: QTBUG-95394
Pick-to: 6.2
Change-Id: I944f4f425ff126e7363a82aff926b280ccf1dfc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
The value returned from shouldHaveNonClientDpiScaling()
controls two related behaviors:
1) Should Qt call user32dll.enableNonClientDpiScaling()
2) Should Qt code treat NonClientAreaScaling as enabled.
Commit c35643db updated shouldHaveNonClientDpiScaling()
to account for the fact that PerMonitorV2 always enables
NonCLientAreaScaling, with the intent to disable 1)
However this also disables 2), which was not intended.
Instead, make shouldHaveNonClientDpiScaling() always
return true when PerMonitorV2 is enabled, and then also
omit calling the user32dll API in this case.
Change-Id: I1d06f36a3d06becc667351fadcb00ab28af6ec4b
Pick-to: 6.2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We were using CGDisplay callbacks to determine when a screen reconfiguration
had happened, and when it had propagated to changes in NSScreen.screens,
so that we could update our QScreen view of the world.
Unfortunately the CGDisplay callbacks were not deterministic enough to
use as a signal for when a reconfigure had completed.
Since we can't rely on NSApplicationDidChangeScreenParametersNotification
either (it comes in too late), we're now resorting to updating our QScreens
at every chance we get:
- On every CGDisplay reconfiguration ending
- On QCocoaWindow::windowDidChangeScreen() as a result of AppKit
moving the window.
- On NSApplicationDidChangeScreenParametersNotification
- On QCocoaScreen::get() as a last resort
Since the result of these updates are only reflected as QScreen property
updates or QGuiApplication signals if a change actually occurred, it should
be safe to update early and often.
Task-number: QTBUG-77656
Fixes: QTBUG-80193
Pick-to: 6.2 6.1 5.15
Change-Id: I98334a66767736d94ad2fcb169e65f0d8bc71a30
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
