Static Qt builds are not covered by BC guarantees, but since all
'libraries' are linked into a single executable, we face in all users
of the library the same ODR violation that we faced within the
implementation DLL: we can't define the same symbol as inline in some
TUs and out-of-line in others.
In the past, we decided to always inline in static builds, but that
breaks users which, by Hyrum's Law, have come to depend on the
non-existent BC guarantees for static Qt builds.
By switching to never inline¹ in static builds, we restore BC for such
users. The performance issues should be minimal, since LTO will anyway
inline whatever it wants, independent on how it was declared.
¹ except when the deprecation point has passed over the Qt version the
API was inlined (-disable-deprecated-up-to configure switch).
[ChangeLog][QtCore] Restored binary compatibility for static Qt
builds broken by the QT_INLINE_SINCE mechanism. Qt still does not
guarantee BC for static build configurations otherwise.
Fixes: QTBUG-109449
Pick-to: 6.5 6.4
Change-Id: Ie3fa62621b74dc5e9dac301b9882c0e3c3999eaf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Several new headers were extracted from qglobal.h in scope of
QTBUG-99313. This commit makes sure that none of them actually includes
qglobal.h.
As those files are new, it should be safe to introduce this change, as
it shouldn't have any impact on the user code.
This patch also modifies the autogenerated module exports header to
include qglobal.h before the include guard. This is needed to prevent
circular dependencies which result in Q_<MODULE>_EXPORT being
undefined.
Task-number: QTBUG-107046
Change-Id: I8d998792fd8129173d9ec811557e7d7604282813
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This patch improves the QT_INLINE_SINCE(maj, min) macro to take
deprecation version into account.
If the specified (maj, min) version is less than or equal to the
version defined by QT_DISABLE_DEPRECATED_BEFORE, the macro will expand
to "inline", and the out-of-line fallback will be removed from the
library.
This is achieved by introducing the helper
QT_IF_DEPRECATED_SINCE(major, minor, whenTrue, whenFalse) macro.
Fixes: QTBUG-104131
Pick-to: 6.4
Change-Id: I285029dad7b71126072b024a3be6d7b11341996d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@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>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
A single global QT_REMOVED_SINCE will start hurting us once more
modules downstream of QtCore start using the mechanism.
With every use of feature, the set of code that needs to compile under
QT_BUILD_REMOVED_API increases. Since we use QT_REMOVED_SINCE in
situations where overloading the new and the old function don't work
in general, this means all code included by any removed_api.cpp needs
to be very carefully written to ensure that any calls to the overload
set formed by the combination of old and new function(s) don't create
ambiguities.
Likewise, the set of APIs that change semantics under
QT_BUILD_REMOVED_API also increases. At some point, the combination of
removed_api.cpp including almost every module header and almost every
header exposing source-incompatibilities when included in
removed_api.cpp will make maintenance a headache.
By making QT_REMOVED_SINCE and QT_BUILD_REMOVED_API per-module
(QT_CORE_REMOVED_SINCE, ...), easy now that we generate the export
macros using CMake, we limit the scope of this problem to the module
using the feature. Downstream modules (say, QtWidgets) will now see
the QtCore API like every other user, even in the
widgets/compat/removed_api.cpp TU.
Pick-to: 6.3
Change-Id: I177bc7bd5aa8791639f97946c98e4592d2c7f9d9
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add the generating of private cpp exports for Qt modules.
Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module
that is the manual switch for private exports generator. Existing
modules in qtbase doesn't follow any strict convention of using
private cpp export. So there is no clue how to detect if generating of
the private exports is required or not for the module.
Use autogenerated private cpp exports in QtNetwork module.
CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function
is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different
meaning. The provided name is used as a base name for the private and
non-private headers that contains cpp exports. Header files suffixes
are constant: .h and _p.h for the non-private and private header files
accordingly.
Pick-to: 6.2
Task-number: QTBUG-90492
Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add an option that automatically generates an export header for a Qt
module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related
content, so it's not a full replacement of 'global' header files.
Task-number: QTBUG-90492
Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
