These methods show up in QML-exposed types. They should be revisioned in
order to keep those types backwards-compatible.
Pick-to: 6.4
Change-Id: I8e826dc2e7db49d8abe69f67605dfb1991855b96
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Found by codespell
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I75f4b14f3eded035a0c904d8a7174cb6f5b7d9ef
Reviewed-by: Wang Bo <wangbo@uniontech.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use __has_cpp_attribute mechanism to check availability of
[[noreturn]]. For MSVC 2019 and 2022, this is always
the case, so we can also remove the (now dead)
__declpsec(noreturn) definition.
Pick-to: 6.4
Change-Id: Ie7b39bd93bc5e1a173e245a3a5d5ff7e9067a59f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Later on we redefine them to
[[deprecated]], [[deprecated("")]], if the attribute
is available.
Since both MSVC 2019 and 2022 support the attribute,
the __declspec() definition was never used.
https://docs.microsoft.com/en-us/cpp/cpp/attributes
Pick-to: 6.4
Fixes: QTBUG-93748
Change-Id: I3e12f2ace414e316a811f2ceb44e6f312803439a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The macro was added to Qt 6.4, so we define it in each moc output to
empty if it wasn't previously defined. Thus, moc retains compatibility
with older Qt versions.
Pick-to: 6.4
Change-Id: Id0fb9ab0089845ee8843fffd16f9c1539fa0368f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Milian Wolff <milian.wolff@kdab.com>
It's the same thing since we have exactly one field in this structure
before stringdata0. But there's a far smaller chance of producing a
warning in user code.
Pick-to: 6.2 6.3 6.4
Change-Id: Id0fb9ab0089845ee8843fffd16f9cdceec33017d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We had the code to calculate the length, but were improperly using it
only for the offset, not the length of the string or its containing
array. That resulted in the generated moc output containing:
QT_MOC_LITERAL(111, 5), // "\xffz"
QT_MOC_LITERAL(114, 5), // "\0012"
QT_MOC_LITERAL(117, 23), // "slotWithAReallyLongName"
The two strings are described as occupying 5 bytes (length 4 + null
terminator), which is incorrect. The offset was correct: 114 - 111 = 3
and 117 - 114 = 3. The new output is:
QT_MOC_LITERAL(111, 2), // "\xffz"
QT_MOC_LITERAL(114, 2), // "\0012"
QT_MOC_LITERAL(117, 23), // "slotWithAReallyLongName"
The effect of the array size calculation would only be felt if moc
decided it needed a second string array (for strings over 65535 bytes),
which would cause the offsets in the second array to be all wrong. There
was no such test until now.
Drive-by fixing of the newline, indentation, and the stale comment
referring to QByteArrayData (Qt 5).
Pick-to: 6.2 6.3 6.4
Change-Id: Id0fb9ab0089845ee8843fffd16f9cd01b3e0709a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
I don't know if they've just added the libs and therefore the GSSAPI
content wasn't enabled before, but libgssapi_krb5.so does not have the
symbols we need.
ld: error: undefined symbol: gss_acquire_cred
>>> referenced by qauthenticator.cpp:1803 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1803)
>>> src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView))
ld: error: undefined symbol: gss_release_name
>>> referenced by qauthenticator.cpp:1808 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1808)
>>> src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView))
[...]
Pick-to: 6.2 6.3 6.4
Change-Id: I6d3880c7d99d4fc494c8fffd16fabf70bbd272f5
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Make sure to convert absolute paths generated using the
$<TARGET_LINKER_FILE> generator expressions into relative paths.
Because prl files are generated for both modules and plugins, we need
to pass both a list of qt module locations and qt plugin locations
to QtFinishPrl.cmake, and then try to make the absolute path relative
to each passed directory.
A warning assertion is shown if we no relative path could be made,
which will cause an absolute path to be embedded. This should not
happen though.
Amends f4e9981259
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104396
Change-Id: Id68395c0dbb20aad5c510d77835cc931b9396556
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
QDom's internalSubset() always returned empty because nothing
actually set the internal data member it returns. When parsing
the DECLTYPE, extract the internal subset and save it to the
doctype()'s member when present.
Pick-to: 5.15 6.2 6.3 6.4
Fixes: QTBUG-53661
Change-Id: I6e41ff8b914381168246073b3289d82205b1c255
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
If the user does not pass:
-o qtbase:qt_host_path=/foo
then log a warning but allow to continue. For example Boot2Qt
integration resolves the 'QT_HOST_PATH' by other means thus making it
a mandatory option to be passed by the user should not be needed.
Pick-to: 6.3 6.4
Change-Id: I4c1d8b5253e33466ccdf463f89473966e90c0e0c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Toni Saario <toni.saario@qt.io>
The behavior is similar to MEMBER: If the READ accessor is "default",
synthesize it using the bindable.
[ChangeLog][QtCore] You can now specify "READ default" in a Q_PROPERTY
if you also specify a BINDABLE. moc will synthesize a READ accessor in
that case.
Task-number: QTBUG-97249
Change-Id: I4a275adabaed12df95dac505095f847c4be65dfe
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The default setting for "Full Path of Source Code File in Diagnostics"
changed with VS 2017: it's now turned on by default. It can also be
enabled with the compiler flag /FC, but there is no flag for turning it
off.
Users might want to disable /FC to obtain reproducable binaries.
Change qmake's default from "use Visual Studio's default" to "off" for
this feature. Users can enable it manually by putting the following
into their project files:
QMAKE_CXXFLAGS += /FC
CMake faced the same problem. See CMake upstream issue #18261 for
comparison.
Pick-to: 5.15 6.2 6.3 6.4
Task-number: QTBUG-104450
Change-Id: Ibe636a0ac5d18aefb44f2b7179b59fcec2ad8353
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
/LTCG:OFF now turns off LTCG.
/LTCG:INCREMENTAL maps to UseFastLinkTimeCodeGeneration.
Unknown /LTCG:xxx values are passed to AdditionalOptions.
Pick-to: 5.15 6.2 6.3 6.4
Task-number: QTBUG-104450
Change-Id: If85942dbeec204dc2571a861a43201cb3d5993ae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This method isn't used anymore, but we can't remove it entirely for BC
reasons, because it was called from inline code.
Pick-to: 6.4
Change-Id: I9183c666c466030787ac7c2386706b50abf23eaa
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is a repeat of commit de6ced6692
"QCborValue: fix incorrect to{Array,Map} when the value is empty" (6.4),
which fixed the same thing for QCborValue. I've just copied the exact
same implementation onto the QJsonValue functions.
Pick-to: 6.2 6.3 6.4 5.15
Fixes: QTBUG-104085
Change-Id: I175efddd75f24ae59057fffd16f6b257bf7ed36d
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
It can actually be undefined, so test for that before checking
the object type.
This fixes the asyncify build.
Pick-to: 6.4
Change-Id: I5a6a0bc60c153290c35c20242400c59cd1312403
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
We don't need QByteArrayData any more (since 6.0).
[ChangeLog][Potentially Source-Incompatible Changes] moc no longer emits
an #include for QByteArray in the output file. None of the content that
moc generates needed that header, so this should not cause changes for
most people. However, codebases that #include'd the moc output
(something that is recommended) could be depending on this indirect
include.
Pick-to: 6.4
Change-Id: Id0fb9ab0089845ee8843fffd16f9cf13dc8d61b5
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
It contains more than one size.
Drive-by drop the const from the structure, so it becomes properly
trivial (though there's disagreement, see[1]).
[1] https://conformance.godbolt.org/z/rK1xW669K
Pick-to: 6.2 6.3 6.4
Change-Id: Id0fb9ab0089845ee8843fffd16f9cc69ffd90aa4
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
- USE_WEBGL2 is depreciated, Emscripten now uses MAX_WEBGL_VERSION
- Optimize and remove use of emulated ES2 and ES3, which means
only use WebGL friendly subset.
Users can add USE_ES3=1 and USE_ES2=1 to the final linker arguments
for those respective versions in order to enable using
glDrawArrays and glDrawElements with unbound buffers.
See https://emscripten.org/docs/porting/multimedia_and_graphics/OpenGL-support.html
Pick-to: 6.4
Change-Id: I11ae359966964b3e7aa6e61ccc714c2bfbf61f96
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The documentation for both gui and widgets defines members of the
"helpsystem" group, which definition is given in qthelp.
Due to recent changes in QDoc that automatically link a class page to
its owning group, it is now required for those project to be dependent
on qthelp, so that it is possible to retrieve the necessary linking
information for the group definition.
Hence, such a dependency was added.
Change-Id: Id9399e76bbe10fb9ae0c05d637006b5cdc0b742b
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There's currently no statistically-significant difference between the
two, due to a huge pessimistion in QTestLib where every QCOMPARE* and
QVERIFY writes 1KiB of data onto the stack before doing anything else,
so I'm not reporting numbers in this commit message.
Pick-to: 6.4
Task-number: QTBUG-98873
Task-number: QTBUG-98874
Change-Id: I233878596f0a8fe6b96360adb839fecd72c398a2
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The variable was misspelt, so we obviously don't need these
exceptions.
Pick-to: 6.4 6.3 6.2
Change-Id: I691c9315bcde3aad72410ce01ae6dc6a013ee6fd
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We have now had several requests for inlining previously-exported
member functions, but no standard mechanism to effect it.
As QT_REMOVED_SINCE has shown, there is great value in having such a
standard mechanism, so here is one.
With this change, to inline a previously exported (member) function,
simply
- mark the declaration with QT_<MODULE>_INLINE_SINCE
- move the definition into the header file (outside the class),
- wrap it in QT_<MODULE>_INLINE_IMPL_SINCE
- #include the header into the module's removed_api.cpp
Just including the header into removed_api.cpp is enough, so you may
want to add a comment:
#include "header.h" // uses QT_<MODULE>_INLINE_SINCE
The effect is as follows:
- A TU in a _different_ library will see an inline declaration,
followed by the definition, and so it will see a normal inline
function.
- A TU in the same library will, however, see a non-inline
declaration, to avoid the ODR violation that at least GCC/ld are
able to detect.
- When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also
see the definition, which is the same setup as before the change,
except in a different TU, and therefore export the member.
- When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the
TU will see no declaration, assuming (correctly), that the
definition will be supplied by a different TU.
This is, of course, an ODR violation, but not worse than what we do
elsewhere, as the definitions differ only between library and user.
The function is inline only for the users of the library, not the
library itself, which will still see the function as non-inline. If
inlining is critical within the library, too, the existing function
should call a new inline function, and calls in the same library should
be changed to call the new inline function instead.
Use the new mechanism to inline the QLocale ctor we intended to inline
for 6.3, but couldn't, because we hadn't found the magic incantation,
yet. Thiago found it a few weeks later, and this is what this patch is
based on.
Fixes: QTBUG-100452
Pick-to: 6.4
Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
While in a private header, it did manage to place QList<QPostEvent>
operations near the top spots of all Qt template instantiations in a
QtWidgets build.
Task-number: QTBUG-97601
Pick-to: 6.4
Change-Id: I4fa1972b8764b71ad0559633131e7e44b3d4ae6a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If, for whatever reason, BOOST_NO_EXCEPTIONS is defined, the user of
the Boost libraries is supposed to provide a definition of
boost::throw_exception, which we didn't.
We used to run into this only on ubsan builds, but it seems we now
have the problem on a regular Ubuntu 22.04 build, too (cf. bugreport).
Fix by adding the necessary definitions.
Fixes: QTBUG-104083
Pick-to: 6.4 6.3
Change-Id: I9b061a158a5b77e8d286bd7b40312e5bc63ee8de
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If the QFuture is canceled because the associated QPromise has been
destroyed, we still need to run its continuations (i.e. onCanceled
handler, if it's attached), so replaced the cleanContinuation() call
inside ~QPromise() with runContinuation(), which will also take care of
cleaning the continuation.
[ChangeLog][QtCore][Important Behavior Changes] QFuture now runs its
continuations when its associated QPromise has been destroyed.
Previously, if a QFuture was canceled because the associated QPromise
has been destroyed, its continuations were skipped.
Fixes: QTBUG-103992
Pick-to: 6.4 6.3 6.2
Change-Id: Ie05bc760c96c349aade8adb8d2fe5263aff8efac
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
http2protocol_p.h is not supposed to be used without the http feature
is enabled. Move its include under QT_CONFIG(http) guard.
Change-Id: I374dd84d3330de2b4c340b9803d0c3d2c13bc8e3
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This makes header files self-contained and reduces the number of
'sources of truth' for syncqt procedure.
Change-Id: I7f5865abc69934603139d23e1b5452da46ccb110
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move public ssl headers to the general QtNetwork sources since they
supposed to be used across the project without corresponding checks
for the FEATURE_ssl presence. The content in these header files has
a conditional implementation guarded by corresponding macros.
Change-Id: I43168469da27321c2d8064ec2e5d7fe31126ebec
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Threads header files are used across the project without the check for
FEATURE_thread enabled. So moving them out of the FEATURE_thread
condition in CMake file to make them part of the CMake source tree
even if FEATURE_thread is disabled.
Change-Id: I8ee4ee5ffa16054b9af0df0aa5704b0f87678e1a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Also add support to expandable/expanded states to QAccessibleComboBox
in widgets. QtDeclarative will still require updates so that QML combo
boxes report the expanded/collapsed state and react to UIA actions.
Task-number: QTBUG-103591
Pick-to: 6.4 6.3
Change-Id: Iff8ba5e3143778ce17998dbe7f5f76cae658dc19
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The useless-cast gcc warning is disabled in the files generated by
the moc. A typical warning is like
using_t = void(Counter::*)(int );
if (*reinterpret_cast<_t*>(_a[1]) ==
static_cast<_t>(&Counter::valueChanged)) {
*result = 0;
return;
}
Removing the static cast results in a compilation error
"address of overloaded function with no contextual type-of
information" in moc_myobject.cpp files.
Checking whether we have an overload set or a single function
might be too much effort for too little benefit and may not worth
it.
Fixes: QTBUG-71938
Change-Id: I6f67e163a3493b51fb95f54218ce6bf9a302f824
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
qt-module-defaults-online.qdocconf includes online-specific overrides
for some of the documentation macros. This needs to happen also in
the commercial template to have equivalent behavior.
Pick-to: 6.4 6.3
Change-Id: I2ca3246fbf16cef502e8eada056df6e8db573d5d
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
The API is deprecated, but the documentation does not state that.
Fixes: PYSIDE-1750
Pick-to: 6.4 6.3 6.2 6.1 6.0
Change-Id: I038ffeb958312d7648690743e06598a15dfb4cbc
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
'androiddeployqt' supposed to copy artifacts that may not have
abi-specific identifies. One example is Qt6Android.jar file. We need
to prevent execution of multiple androiddeployqt instances in
parallel. External projects now are divided into two steps. The
first runs the build and can be executed in parallel to the build
steps from the other external projects. The second one triggers
androiddeployqt and can only be run exclusively in relation
to the similar steps from other ABI-specific external projects.
To solve the issue we build the dependency chain between the all
ABI-pecific qt_internal_${target}_copy_apk_dependencies targets to
execute androiddeployqt sequentially. This is non-optimal, but
guarantees that androiddeployqt is not running simultaneously with
another instance in external projects.
Pick-to: 6.3 6.4
Fixes: QTBUG-104013
Change-Id: I39a25dd5f38ed988e0ca74b185024bc602ab81a1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
- Make it explicit that each chapter can be run as a stand-alone test
application
- Add a CMake section on how to build the executable
Task-number: QTBUG-103730
Pick-to: 6.4 6.3
Change-Id: Id4c87c454521f698dcf16cfdc176318dd3e16786
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
QXcbConnection::sync is a full equivalent of calling XSync with false,
they both are sending GetInputFocus request and getting its reply
Pick-to: 6.4
Change-Id: I4f91b9447a02def41a8693a54312856b56e74811
Reviewed-by: Liang Qi <liang.qi@qt.io>
For example, when having virtual monitor which includes two real
monitors, the primary information in xcb_randr_monitor_info_t
is normally false, because user can only set it for output.
Kudos to Jiang Wu for his first patch and details of the issue.
Done-with: Jiang Wu <wujiang@kylinos.cn>
Pick-to: 6.4 6.3
Change-Id: I6af443ff69d347a6d86efc9c8ea7a5d18f4c3e24
Reviewed-by: JiDe Zhang <zhangjide@uniontech.com>
Reviewed-by: Jiang Wu <wujiang@kylinos.cn>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Regression introduced in 9a4c98e556:
m_cursor is not initialized and never set when monitorInfo is not
available in QXcbScreen::setMonitor. This seems to happen when running
in VNC, e.g. on a Raspberry Pi.
This usually results in crashing the application pretty soon.
Using a unique_ptr solves both the initialization and a possible leak
when setMonitor is called multiple times.
[ChangeLog][Linux/XCB] Fixed crash when no monitorInfo is available (e.g. VNC).
Fixes: QTBUG-104443
Pick-to: 6.3 6.4
Change-Id: If13493c177121a1994b5d00dfbd64f1da694df2e
Reviewed-by: Liang Qi <liang.qi@qt.io>
...instead of next to the import library.
If separate_debug_info is enabled then we would create an install rule
that puts the .dll.debug file next to the .a file. GDB however expects
the file to be next to the .dll.
Fix the installation rule in separate_debug_info.prf accordingly. This
affects the MinGW packages of Qt 5.15 and user projects targeting MinGW.
Pick-to: 5.15 6.2 6.3 6.4
Fixes: QTBUG-86790
Change-Id: If91c356e7e7f7f4330ebc43691e414929f9beb4b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
