std::function as a type is rather unfortunate for us, as its SSO buffer
makes it rather large, and we can ensure that the function is never
empty.
Considering that we do need to allocate memory for
QPropertyBindingPrivate anyway, we can get rid of the SSO buffer and
instead coalesce the allocations (similar to how std::make_shared works).
The memory looks then like
[--QPropertyBindingPrivate--][Functor]
and QPropertyBindingPrivate can get a pointer to the functor via
reinterpret_cast<std::byte>(this)+sizeof(QPropertyBindingPrivate).
To actually do anything with the functor, we do however need a "vtable"
which describes how we can call, destroy and move the functor. This is
done by creating a constexpr struct of function pointers, and storing a
pointer to it in QPropertyBindingPrivate.
As a consequence of those changes, we cannot use QESDP anymore, as we
now have to carefully deallocate the buffer we used for both the
QPropertyBindingPrivate and the functor. We introduce a custom
refcounting pointer for that. While we're at it, we make the refcount
non-atomic, as bindings do not work across threads to begin with.
Moreover, we can now make the class non-virtual, as that was only needed
to hack around limitations of QESDP in the context of exported symbols.
Change-Id: Idc5507e4c120e28df5bd5aea717fe69f15e540dc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
dlsym() should be taking a Handle that is created by dlopen() instead of
pHnd.
* https://linux.die.net/man/3/dlsym
Fixes: QTBUG-84849
Pick-to: 5.15
Change-Id: Ic192736268ef9cbfdb86cf66d20082b14070ba00
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
In 3558704ed5 we changed the font
weights to use the OpenType weights rather than our own
non-standard scale.
This can cause difficulty for people who have legacy font
weights stored as ints and no way to convert them. Therefore,
we add accessors for the legacy font weights to ease the
transition.
Change-Id: I2a591c62895dfa1a2310d9a2d0cdcf08de08f3a4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We must write config.opt in the same directory we're reading it from.
We must not write the -top-level argument to config.opt.
This amends commit 2a29426e39.
Change-Id: I96da9094579fec29c290411677d6b538878399f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a new function that returns the minimum CMake version required to
build Qt. Pass that value to cmake_minimum_required() when building
qtbase and its standalone tests.
The minimum supported CMake version is read from qtbase/.cmake.conf
and its value should be updated when the need arises. It's the main
source of truth for all repos.
Provide a way to lower the minimum CMake version at configure time by
passing a value via QT_FORCE_MIN_CMAKE_VERSION.
This is not an officially supported way of building Qt. If the
specified version is lower than Qt's supported minimum, show a
warning.
Nevertheless the option is useful for testing how Qt builds with a
different minimum CMake version due to different policies being
enabled by default.
Issue warnings for CMake versions that are higher than the minimum
version but are known to cause issues when building Qt.
A counterpart change is needed in qt5 to ensure the minimum CMake
version is set at the proper time for top-level builds.
Ideally we would use the same 'check the CMake minimum version` code
in all our repositories, but that will cause lots of duplication because
we can't really find_package() the code and doing something like
include(../qtbase/foo.cmake) hardcodes assumptions about repo
locations.
So for now we don't bump the minimum version in child repo
cmake_minimum_required calls (qtsvg, qtdeclarative, etc).
Instead we record both the minimum supported version and the computed
minimum version (in case a different version was forced) in
QtBuildInternalsExtra.cmake.
Then we require qtbase's computed min version in
qt_build_repo_begin().
This won't set policies as cmake_minimum_required would, but at least
it propagates what minimum CMake version should be used for child
repos.
We might still have to bump the versions in child repos at some point.
Task-number: QTBUG-88086
Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
We'll need QContainerTraits as a class for changing properties
of our containers, so free up that name. This is not a problem,
as the namespace is new in Qt 6 and has only been used internally
so far.
Change-Id: I6d6b9d9c32b92b77e66323f1fc29b3ddd8baa98f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Few breaking changes. Some things moved header, but as they didn't
change namespace, naming or signature, and the old headers now include
the 'new' headers, it is SC anyway.
Change-Id: I6b0556049f6d9203dcf7420317a14992fbe85a80
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The enum value of that property changed. Use the same mapping trick
as with two other properties to ensure backwards compatibility
in QDataStream.
Change-Id: I01b36f9ecbcaf40e7c8523da33ea4c8f12821a63
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
The flags go before the library in the final linker line, as opposed
to the dependencies declared in LIBS.
This allows us to declare the flags for the entrypoint
in the project file of the entrypoint, instead of in
a standalone prf.
Change-Id: I35c054fe9fdaa6add7cd0e8ba3f7304f975ff80f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Partial revert of 5866b82e24.
The function is still in the QTest namespace.
Change-Id: I5e25b405baf07e61781ca4a527601ef0bf8ce6a4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
On the qmake-side we had exports, but they were quoted.
Change-Id: I95af4b927079691cab6403fec850f345ba181a00
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
People that insist on qmake builds of Qt can configure with -qmake
Task-number: QTBUG-87049
Change-Id: I5729b654d4c8b9c6b526234ba5563aff8fd750e1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It was ported to qsizetype after the cast was introduced
Change-Id: I00caff1d960f403990f93fcec6a7969e62b4cc99
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The arguments -platform, -xplatform and -device determine the mkspec
that's used for the qmake companion files.
If the user specifies a mkspec that indicates usage of clang or icc,
set the respective CMake variables to use one of those compilers.
Fixes: QTBUG-87836
Change-Id: I2b10d819b0eb92a97d7f79672547b1e2d821cf33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's illegal. [macro.names]/2:
"A translation unit shall not #define or #undef names lexically
identical to keywords"
If someone tries to use dynamic_cast in a no-rtti scenario, let's
just have the compiler yell at them for that.
Change-Id: I70a7b55a93d34c433e874d379acae8b256620f80
Pick-to: 5.15
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
If the mime data includes text/markdown, display it decoded in the QLabel,
and also display the raw markdown in the table below. QLabel supports
markdown since 51cbd5288c.
Ideally we should add proper support for markdown to QMimeData, but
it's too late to do that for Qt 5.
Pick-to: 5.15
Change-Id: I2a9998e4b239658fe49f39786e7c4fdd0c08b21a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In commit 68866b1a7b we introduced a bug:
At a point where the first output of an extra compiler is extracted, we
try to evaluate the first output as qmake variable. This is as
nonsensical as it sounds and leads to malformed extra compiler output in
vcxproj files.
Pick-to: 5.15
Task-number: QTBUG-87601
Change-Id: Ib9aaf8a6eed8c69243f364554325c240d0bfc7f4
Reviewed-by: Miguel Costa <miguel.costa@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
No action taken at Qt 6, suggesting it shall never happen.
Four removed, one converted to Qt 7, others converted to unversioned TODOs.
Filed Jira tasks, and referenced in comments, for those retained.
There remain two "once bootstrap builds are obsolete" comments and
one other on which pending action may yet happen.
Fixes: QTBUG-85700
Change-Id: Ib140a6a21c63370e51e4734cc591f67573a29d9a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Show a deprecation warning if a non shared container is used within
Q_FOREACH, because it would make an expensive copy of the container
Change-Id: I70cfd789b5b8d9f5b1bd6e0a57e5e968e1c6a0ca
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Drive-by, make QLayout constructor explicit, as it should have
always been.
[ChangeLog][QtWidgets][QLayout] The QLayout constructor taking
a QWidget pointer is now explicit.
Change-Id: If6accfb2e7e810fa08adacea9e674c99121f6bc6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Document the source compatibility breaks introduced by the recent
changes (ff0ba7e2d7 and
30a1683f65) in the porting guide.
Task-number: QTBUG-87096
Change-Id: I5b725c863b1077d59074d4bd17a4456e3d87918c
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
ANDROID_ABIS should be used instead of ANDROID_TARGET_ARCH.
Fixes: QTBUG-81866
Pick-to: 5.15
Change-Id: I6dc9e0cd2a19bea8864e3ab4174bd609c0aad4dc
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Let the new created embedded QLineEdit use the palette from QCombobox,
when calling [setEditable(true)]
Fixes: QTBUG-81533
Pick-to: 5.15
Change-Id: Ia406dd8122a348e185f0e94d027646b95eeaa76e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
It's per framebuffer and the color target for the default fbo
is never altered. So no need for this call. This is useful because
it avoids having to deal with the controversy around GL_BACK (where
the GL, but not the ES, spec claims some quite nonsensical things
about GL_BACK not being accepted by glDrawBuffers (in the name of
stereo support?), nevermind GL_BACK being the default value...),
and while what we have in place now seems to be ok with many
implementations, it may generate a GL error with others - so
just remove the call in order not have to think about this
legacy nonsense)
Task-number: QTBUG-88070
Change-Id: I051c60a3041865a3434801b57da2b7acb518b8fe
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
At the moment our examples require a minimum of 3.14 due to changes
in upstream CMake's Autogen functionatlity to support Qt 6. Anything
lower would simply not work with Qt 6.
It's not clear yet if we actually want to require 3.14, or something
higher. At the very least there were many significant changes to
support iOS in CMake 3.15.
But for now just bump the version checked by Qt6Config.cmake to be
consistent with what's in our examples.
Task-number: QTBUG-88086
Change-Id: I119c2ad05a18c357fe7c659b30685af87475fc84
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
1. clang-cl doesn't support "-fno-exceptions", it uses msvc's parameter.
2. some parameters supported by msvc are not supported by clang-cl
and they are causing huge warning message flood, don't add them.
3. use correct optimize parameter for clang-cl.
Change-Id: Idbadf139127143c5fa6c49068588cb26f47da7a2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The non-versioned one's do miss some properties. It's therefore best
to not advocate using them.
Change-Id: I53645e65ed4de4e0100e59905c024cdfe40be0c5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When linking static libraries, MSVC's link.exe complains about
the unknown parameter "/INCREMENTAL:NO" and output a lot of warning
messages about this. This doesn't happen when it's linking exes
or dlls.
The situation is a lot more worse when we are using clang-cl.
clang-cl will print some error message like it can't find a
file named "/INCREMENTAL:NO" and just stop compiling. It seems
clang-cl treat unknown parameters as input files.
Fixes: QTBUG-87875
Change-Id: I37ed29de082b0258e81494db54f275417ab42708
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The tst_qtimer::zeroTimer unit test was relying on
QCoreApplication::processEvents processing all pending
events. However, for the glib backend, this is not the case.
For the glib backend, if there is an event of high
priority pending, low priority events are not processed.
This patch changes the test to use the overload with
timeout of processEvents, which does process events
until there are no more events or the timeout is reached.
Fixes: QTBUG-84291
Change-Id: I429141507b8603b57a191efa21f154493d75cc9e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This change allows the user to use -Wextra-semi-stmt without a warning.
A macro should never include a ; by it's own. Macro Q_UNUSED already
adds semicolon.
Fixes: QTBUG-82978
Pick-to: 5.15
Change-Id: I6d8d009cf89f0c8bbb6a9fee986e81302ebd7459
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The compiler can generate better code when the base is known
in integer to string conversion. This patch creates separate branches
for known bases and leaves generic code as a fallback.
Saved about 12ns per conversion of 12345678 in one measurement.
Task-number: QTBUG-87330
Change-Id: I44c9bb467cf211f7e617ed55104476062296bba6
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Adds SIMD acceleration for the blend_pixel, and raw interpolate methods,
and cleans up other SIMD code.
Gives minor speedups in text rendering and various fallbacks.
Change-Id: Ib0ad8b408450e4e73f3c1d50e9caaed0098acb94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QT.<module>.DEFINES assignment in pri files needs to take into
account the module name when computing the define name. This is the
MODULE value that qmake specifies.
In CMake that would be the value of CONFIG_MODULE_NAME.
Previously the value of the define was computed in
qt_internal_module_info() without taking into account the module name.
While qt_internal_module_info() ended being used also for plugins and
other target types, the defines computed by it were meant to be used
only for Qt modules.
Thus remove the <result>_define assignment from
qt_internal_module_info and move its computation directly into
qt_internal_add_module, taking into account the value of
CONFIG_MODULE_NAME.
The only other use of module_define was in qt_internal_add_plugin but
that was merely a long overdue copy-paste error, qmake doesn't
propagate QT_FOO_LIB defines for plugins.
As result, a define special case in testlib is not needed anymore,
because the define is now computed properly.
Finally, QT_FOO_LIB should not be used while building the Qt module
itself, so instead of using PUBLIC_DEFINES option of
qt_internal_extend_target, use target_compile_definitions(INTERFACE)
directly.
Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Since QPA plugins own the input device objects that they create, they
can also subclass to add arbitrary extra data (as was done with
QWinTabPointingDevice in abb5f0d376);
so this pointer seems unnecessary. It's unused so far AFAIK.
Retaining it also brings up the possibility of a memory leak:
~QInputDevice() doesn't delete it, and whatever code stores something
there would need to make sure it gets deleted.
Change-Id: I7ec264c23c74b83db1f37f64f31857caf551fdae
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Since the QVariant types are deprecated in Qt6, use QMetaType instead
Change-Id: I7bddea15a3f1a534d3c6f6b9e7ddf9585a8423bf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Makes the diff between Qt 5.15 and 6.0 easier to read, to see what's
missing.
Change-Id: Idf8aa17b3ab8494f6855c172665423a53ca8a024
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CONFIG_MODULE_NAME option to qt_internal_add_module is used to
specify what the name of a Qt module's pri file should, as well as
some of the key names assigned in that file, as well as what should be
passed to QT += in qmake projects.
When it is not specified, the computed value is the lower case of the
CMake target name. E.g. for qt_internal_add_module(Core), the computed
CONFIG_MODULE_NAME is 'core'.
The qmake variable that determines the above value is the MODULE
variable.
If it is not explicitly assigned, it's computed from the .pro file
name, rather than from the TARGET variable value.
Thus there is an inconsistency in how the value is auto-computed in
CMake compared to qmake.
We had a few special cases in projects that assign a correct
CONFIG_MODULE_NAME when the auto-computed value was wrong.
Teach pro2cmake to detect these inconsistencies and pass a correct
CONFIG_MODULE_NAME value based on the .pro file name. This way
we get rid of the special cases as well.
Aka if there is no explicit MODULE assignment in the .pro file, and the
auto-computed value by CMake is different from the one computed by
qmake, explicitly write out a CONFIG_MODULE_NAME value with what qmake
would have computed.
Task-number: QTBUG-88025
Change-Id: I166b29767e87cd6b0c681fa53238098355a177f9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
