From 97f643faee876cadb36f110ef5a96abf1b68acff Mon Sep 17 00:00:00 2001 From: Marc Mutz Date: Mon, 31 Jan 2022 11:27:49 +0100 Subject: Long live QT_INLINE_SINCE! MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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__INLINE_SINCE - move the definition into the header file (outside the class), - wrap it in QT__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__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__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__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 Reviewed-by: Mårten Nordheim --- src/corelib/text/qlocale.cpp | 2 +- src/corelib/text/qlocale.h | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) (limited to 'src/corelib/text') diff --git a/src/corelib/text/qlocale.cpp b/src/corelib/text/qlocale.cpp index 7993c2139d..811df6dcdc 100644 --- a/src/corelib/text/qlocale.cpp +++ b/src/corelib/text/qlocale.cpp @@ -996,9 +996,9 @@ QLocale::QLocale(QStringView name) #if QT_STRINGVIEW_LEVEL < 2 /*! + \fn QLocale::QLocale(const QString &name) \overload */ -QLocale::QLocale(const QString &name) : QLocale(qToStringViewIgnoringNull(name)) {} #endif /*! diff --git a/src/corelib/text/qlocale.h b/src/corelib/text/qlocale.h index 5ba29f6093..b9880496f1 100644 --- a/src/corelib/text/qlocale.h +++ b/src/corelib/text/qlocale.h @@ -892,6 +892,7 @@ public: QLocale(); #if QT_STRINGVIEW_LEVEL < 2 + QT_CORE_INLINE_SINCE(6, 4) explicit QLocale(const QString &name); #endif explicit QLocale(QStringView name); @@ -1133,6 +1134,11 @@ Q_DECLARE_SHARED(QLocale) Q_DECLARE_OPERATORS_FOR_FLAGS(QLocale::NumberOptions) Q_DECLARE_OPERATORS_FOR_FLAGS(QLocale::LanguageCodeTypes) +#if QT_CORE_INLINE_IMPL_SINCE(6, 4) +QLocale::QLocale(const QString &name) + : QLocale(qToStringViewIgnoringNull(name)) {} +#endif + #ifndef QT_NO_DATASTREAM Q_CORE_EXPORT QDataStream &operator<<(QDataStream &, const QLocale &); Q_CORE_EXPORT QDataStream &operator>>(QDataStream &, QLocale &); -- cgit v1.2.3