summaryrefslogtreecommitdiffstats
path: root/src/corelib/kernel/qmetatype.h
Commit message (Collapse)AuthorAgeFilesLines
* Bootstrap: remove QVariantThiago Macieira2024-03-131-4/+25
| | | | | | | | | I added QT_NO_VARIANT to qconfig-bootstrapped.h to be clearer on what the #ifs are, but there's no testing of that feature outside of QT_BOOTSTRAPPED. Change-Id: I01ec3c774d9943adb903fffd17b7e8ac4340fb89 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Bootstrap: remove QDataStreamThiago Macieira2024-03-131-7/+9
| | | | | | | | | | | It was only used by the cmake_automoc_parser so it would write a 64-bit in big-endian format. So bypass QDataStream and write it native endianness. Change-Id: I01ec3c774d9943adb903fffd17b79c78e56db4cf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* QMetaType: fix typenameHelper() for types in the QtPrivate namespaceThiago Macieira2023-12-081-5/+8
| | | | | | | | | | | | | | | | | | GCC at some point decided that it wouldn't include the full namespace expansion in __PRETTY_FUNCTION__ for any type that is in the same namespace as the template function being expanded (that is, the QtPrivate) namespace. I don't know how long this behavior has been in place, but it can be seen with GCC 13, where the expansion of that macro inside QtPrivate::typenameHelper<QtPrivate::ModelIndex>() is: constexpr auto QtPrivate::typenameHelper() [with T = ModelIndex] This can be easily worked around by using a different namespace. Fixes: QTBUG-119650 Pick-to: 6.6 6.5 6.2 Change-Id: Ica7a43f6147b49c187ccfffd179df309e43a70cb Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QVariant: Fix support for metatypes created by Qt < 6.5Fabian Kosmale2023-04-281-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | In Qt >= 6.1, < 6.5, a trivially constructible type would have the NeedsDestruction flag set, but it's dtor pointer would have been null. In Qt 6.5, the meaning of the NeedsDestruction flag was changed to be more aligned with what the name suggests, and thus would only be set for non-trivially destructible types. For QMetaType this was fine, but QVariant has a check for acceptable metatypes which attempts to verify whether a QMetaType is usable for QVariant. The check assumes the semantics of Qt 6.5, and thus fails for metatypes created by older Qt versions. To fix this issue, we increment the QMetaType revision field, and only check the metatype's destruction support if the revision is high enough. In theory, that allows passing unsuitable metatypes from older Qt versions to QVariant; however, such code would have been broken in prior Qt releases already (which didn't attempt the check), and no code that used to work in any released Qt version will break (as we simply skip a check that was passing before). Fixes: QTBUG-113227 Pick-to: 6.5 Change-Id: I12e02bd97d2c410ea1a36efb0ce2389f21d50a30 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QMetaType: Provide underlyingType for enumsFabian Kosmale2023-03-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | Currently, Qt assumes that enums always have int as their underlying type (both in QMetaEnum::keyToValue and in the QML engine). This change makes it possible to to retrieve the underlying type from an enum's metaype - or rather, a metatype of an integral type with the same size and signedness. The use cases aobve don't really rely on the exact same type. In most cases, we wouldn't even need the signedness, however that is already available anyway, and it will come in handy once QML supports bigint, and we need to decide whether we should return While it would be possible for individual users of this function to manually query the size and signedness, having a function returning a metatype offers additional convenience - especially in QML, where the conversion APIs generally operate on metatypes. Task-number: QTBUG-27451 Task-number: QTBUG-84055 Task-number: QTBUG-112180 Change-Id: Icf733b42df0ea64017d69f4d94cb7c855d9e3201 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Apply q20::remove_cvref_t around the codeMarc Mutz2023-03-011-3/+2
| | | | | | | | | Found in API review. It's not BC-critical, but let's get this into 6.5 to minimize the diff to our future LTS. Pick-to: 6.5 Change-Id: Iaa63afad1d31f6edef29e1185897d925f47a094d Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: fix value-initialization in a corner caseGiuseppe D'Angelo2022-12-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a type is trivially default constructible, QMetaType (and QVariant) think that it can be built and value-initialized by zero-filling a region of storage and then "blessing" that storage as an actual instance of the type to build. This is done as an optimization. This doesn't work for all trivially constructible types. For instance, on the Itanium C++ ABI, pointers to data members are actually value-initialized (= zero-initialized, = initialized to null) with the value -1: https://itanium-cxx-abi.github.io/cxx-abi/abi.html#data-member-pointers This means that a type like struct A { int A::*ptr; }; is trivially constructible, but its value initialization is not equivalent to zero-filling its storage. Since C++ does not offer a type trait we can use for the detection that we want to do here, and since we have also decided that Q_PRIMITIVE_TYPE isn't that trait (it just means trivially copyable / destructible), I'm rolling out a custom type trait for the purpose. This type trait is private for the moment being (there's no Q_DECLARE_TYPEINFO for it), and limited to the subset of scalar types that we know can be value-initialized by memset(0) into their storage (basically, all of them, except for pointers to data members). The fix tries to keep the pre-existing semantics of `QMetaType::NeedsConstruction`. Before, the flag was set for types which were not trivially default constructible. That included types that aren't default constructible, or types that cannot do so trivially. I've left that meaning unchanged, and simply amended the "trivial" part with the custom trait. A fix there (to clarify the semantics) can be done as a separate change. Change-Id: Id8da6acb913df83fc87e5d37e2349a4628e72e91 Pick-to: 6.5 Fixes: QTBUG-109594 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QTypeInfo: start moving away from isIntegral / isPointerGiuseppe D'Angelo2022-12-271-1/+1
| | | | | | | | | They offer no value over the traits in the standard library (in fact, they're implemented precisely in terms of those traits). This commit is done in preparation for their removal. Change-Id: I3fb67e03e1c476f6ac0b369dfbbcf46b291270c8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qfloat16: make it a built-in metatypeThiago Macieira2022-11-281-3/+6
| | | | | | | | | | | I've reserved the IDs for int128, uint128, bfloat16, and float128, because the mask in qvariant.cpp's qIsNumericType() requires primitives to be less than 64 to operate properly. Added a QMetaType/QDataStream test to confirm it is indeed built-in. Change-Id: I3d74c753055744deb8acfffd17247f7f57bada02 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Replace usages of Q_CLANG_QDOC with Q_QDOCLuca Di Sera2022-10-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | To allow the user to customize the C++ code that QDoc sees, so as to be able to work-around some limitations on QDoc itself, QDoc defines two symbols: Q_QDOC and Q_CLANG_QDOC, both of which are "true" during an entire execution of QDoc. At a certain point in time, QDoc allowed the user the choice between a custom C++ parser and a Clang based one. The Q_QDOC symbol would always be defined while the Q_CLANG_QDOC symbol would be defined only when the Clang based parser was chosen. In more recent times, QDoc always uses a Clang based parser, such that both Q_CLANG_QDOC and Q_QDOC are always defined, making them equivalent. To avoid using different symbols, and the possible confusion and fragmentation that derives from it, all usages of Q_CLANG_QDOC are now replaced by the equivalent usages of Q_QDOC. Change-Id: I5810abb9ad1016a4c5bbea99acd03381b8514b3f Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* QMetaType: Support custom unary converters with optional<To> return typeArno Rehn2022-09-271-1/+11
| | | | | | | | | | | | | | | To indicate success of a conversion, the public API has previously only supported registering member functions of the form To (From::*)(bool *). When adding custom converters for types that cannot be modified, this is usually not a possibility. As an alternative, this patch adds support for std::optional in the UnaryFunction overload of QMetaType::registerConverter. If the returned optional has no value, the conversion is considered failed. Task-number: QTBUG-92902 Change-Id: Ibac52d2cb9b5a2457081b4bebb0def1f03e3c55d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Include QVariantPair in documentation of QMetaType::TypeEdward Welbourne2022-09-261-1/+1
| | | | | | | | | | | | | | | When it was added, along with the type it describes, it wasn't added to the QDoc-only fake version of Type's declaration, or to the \enum's list of \value entries. There being no clear reason for those omissions, I'm presuming to guess they were just an oversight. This amends commit c7ce1bc05c1ec2f63dd2531f23a3e9f6fe866556 which was included in Qt 6.0.0. Pick-to: 6.2 6.4 Change-Id: I1bf9fe0f0a31219a888666550a197e479d8eadc1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Clear two pointless entries from the QDoc-only QMetaType::TypeEdward Welbourne2022-09-261-2/+2
| | | | | | | | | | | The real Type has several "administrative" members beside LastCoreType and LastGuiType, but only these two appear in the qdoc-only fake version of Type, only to be \omitvalue'd out in the docs. Save the perpetual "need" to keep updating them with each new addition (they weren't even in sync with the real versions anyway) by removing them. Change-Id: If7c5da87655a2da5c7f29f394c9dd9921ff0c1a7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMetaType of non-const ref: play nice with template instantiationsFabian Kosmale2022-09-221-1/+6
| | | | | | | | | | | | | ...by making QMetaTypeId2 contain all expected members. While we don't allow QMetaType from non-const references, we want to get to the static_assert telling us as much, instead of running into more or less incomprehensible error messages in the depths of qmetatype.h. Pick-to: 6.4 Task-number: QTBUG-106672 Change-Id: Ica9b13fee95eda97cafab2cccdc5249dfc3dcdf2 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* moc: Do not fail to compile meta-methods containing non-const ref typesFabian Kosmale2022-09-211-1/+8
| | | | | | | | | | | | | | | | Amends 2d0c31e7d92a3e9df4ce2b9c1d41b94fb12735fc. We were using MetaTypeDecay in qTryMetaTypeInterfaceForType; but that is not used by moc when complete types are enforced. Change qt_metaTypeArray to also use qTryMetaTypeInterfaceForType, so that the code path for "force complete types"[0] and the normal one do not diverge. [0] Most easily enabled by using one of the QML type registration macros. Fixes: QTBUG-106672 Pick-to: 6.4 6.4.0 Change-Id: I9bf14873d1d0c4127a676643f7e8eb77f6e42dc8 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QMetaType: don't use global relocations to the lambdas and structuresThiago Macieira2022-08-121-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | The way the Qt 6.0 QMetaTypeInterface was designed, using a static inline variable in a template, would normally require the linker and dynamic linker to merge all copies and choose a single copy as the official one. But because of hidden visibility and of Windows DLLs, QMetaType already copes with multiple copies NOT getting merged. So we may as well ask the linkers not to bother and use simpler, local relocations to find those symbols. They are all supposed to still be equivalent and it's an ODR violation if they're not. The Apple ld64 linker complains if you use this type of global relocation: ld: warning: direct access in function [...] to global weak symbol 'QtPrivate::QMetaTypeInterfaceWrapper<int>::metaType' Fixes: QTBUG-93471 Pick-to: 6.3 6.4 Change-Id: Id0fb9ab0089845ee8843fffd16f98a10aa719434 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: fix void* parametersThiago Macieira2022-08-011-2/+2
| | | | | | | | | | | | | Commit 3695b35dfc427f274e55f8e2a6a9876deb52f1b4 accounted for pointer to other incomplete types, but pointer-to-void was missed. This caused an inconsistency in the stored metatype for void*, which is a built-in type (QMetaType::VoidStar) but no pointer was recorded. The test in tst_moc hadn't been enabled because the functions in questions weren't extracted by moc. That is fixed in this commit. Change-Id: I6f936da6f6e84d649f70fffd1706f613517a75fb Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: re-fix them for pointersThiago Macieira2022-07-271-7/+37
| | | | | | | | | | | | | | | | | | | | | | Instead of placing the error deep into IsPointerToTypeDerivedFromQObject with a message about weird the sizes, move them closer to the front-end so we get a proper error message like: <stdin>:1:56: required from here qmetatype.h:1131:45: error: static assertion failed: Meta Types must be fully defined <stdin>:1:50: required from here qmetatype.h:1132:29: error: static assertion failed: Meta Types cannot be non-const references or rvalue references. <stdin>:1:56: required from here qmetatype.h:1136:55: error: static assertion failed: Pointer Meta Types must either point to fully-defined types or be declared with Q_DECLARE_OPAQUE_POINTER(T *) This does not apply to the meta type list stored in a meta object, as meta method parameters may be opaque pointers or even forward-declared only. Change-Id: I36b24183fbd041179f2ffffd17025f10f38e04e6 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: fix QMetaTypes for non-const referencesThiago Macieira2022-07-271-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Namely, they shouldn't be supported. Even trying to create such a type (as in QMetaType::fromType<int &>()) should fail, because for the purposes of the meta type, they are not the same. However, they were being registered in the meta objects' meta type list as a mistake since commit cb43aaca112c864a201b87037692cb8ae2e93b6d ("Introduce QMetaObject::metaType"), including for output parameters in D-Bus remote objects' meta objects. despite the comment saying "type id not available". [ChangeLog][Potentially Source-incompatible Changes] Made meta types for non-const references fail to compile. Previously, QMetaType::fromType allowed this to compile, but returned the meta type for the base type, which was incorrect. Const references are understood to be the same as the base type. [ChangeLog][Important Behavior Changes] The meta type for non-const reference parameters in extracted methods (signals, slots, etc.) is no longer available in QMetaMethod. This used to be the case in Qt 4.x and 5.x, but due to a mistake in Qt 6.0-6.3, QMetaMethod would incorrectly report the base (non-reference) type. Additionally, both the reference and the non-reference types may have been reported in different APIs. Pick-to: 6.4 Change-Id: I36b24183fbd041179f2ffffd1702384d2b64a5f9 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QMetaType: move is_complete template further upThiago Macieira2022-07-271-15/+14
| | | | | | | | | Alongside the rest, makes the code better organized. Pick-to: 6.4 Change-Id: I36b24183fbd041179f2ffffd17025ca7fe988a5a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: don't record trivial construction function pointersThiago Macieira2022-07-271-6/+12
| | | | | | | | | | | | We can implement the trivial {default,copy,move} construction outselves inside qmetatype.cpp and qvariant.cpp, simplifying the QMetaType interface object, removing up to three relocations per QMTI. This adds the testing for QMetaType::isXxxConstructible and isDestructible that couldn't be added before. Change-Id: Ic44396b31ba04712aab3fffd16ff0a28f541d507 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: add is{Default,Copy,Move}Constructible and isDestructibleThiago Macieira2022-07-261-0/+9
| | | | | | | | | | | Unit tests will come after I've fixed the flags themselves. At this point, they are wrong. [ChangeLog][QtCore][QMetaType] Added isDefaultConstructible(), isCopyConstructible(), isMoveConstructible() and isDestructible(). Change-Id: I3859764fed084846bcb0fffd170353109378e34c Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: add registerType() and qRegisterMetaType(QMetaType)Thiago Macieira2022-07-261-6/+30
| | | | | | | | | | | | | | | | | | | | | | | This also rewrites QMetaType::id() on top of the helper, with the benefit of calling a member static function, so QMetaType doesn't need to be spilled onto the stack. In some upcoming changes I need to ensure that QMetaTypes are registered so they can be found by name and I'd like to have a dedicated function name for that, instead of calling .id(). Since I needed to add docs for the new function, I've updated for the old one too. [ChangeLog][QMetaType] Added QMetaType::registerType() and an overload of qRegisterMetaType() taking QMetaType (the two functions do the same thing). These two functions ensure a given QMetaType is registered with the Qt global registry, so they can be found by name later. Using qRegisterMetaType<T>() also accomplishes the same thing, but is slightly better for completely generic code because it will avoid emitting the registration for built-in types. Change-Id: I3859764fed084846bcb0fffd170351d606034c22 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Introduce new traits constant for determining if type is a gadgetMikolaj Boc2022-07-161-1/+4
| | | | | | | | Do it in preparation for other changes around gadget type traits, for porting qtdeclarative to the new API. Change-Id: I91cd5aff81a678565cdf1b7e0b57f52bae8a1a80 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Specialize MetaObjectForType for non-pointer QObject-derived typesMikolaj Boc2022-07-121-1/+6
| | | | | | | | | | | | | | | | | | QMetaTypeInterfaceWrapper tries to find the metaObjectFunction using the MetaObjectForType template. Using SFINAE, for a QObject, it should resolve to a suitable specialization. Such a specialization doesn't yet exist. It had to be created. The following path returns nullptr for registered meta types: auto metatype = QMetaType(typeId); requestedTestType.metaObject() -> returns nullptr since a bad template argument is fed to MetaObjectForType<T> in QMetaTypeInterfaceWrapper<IneritingFromQObject>::metaType's static initializer. Change-Id: I8b31c51e12cb19c333e00480b0177354b910ce1e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live QDebug op<< QMetaType!Marc Mutz2022-07-091-0/+3
| | | | | | | | | | | It's needed in QtHttpServer. [ChangeLog][QtCore][QDebug] Can now stream QMetaType. [ChangeLog][QtCore][QMetaType] Can now be streamed through QDebug. Change-Id: I974d77d678137715472a3907ab1e50ba2dbaa087 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMetaType: remove useless public: access specifierMarc Mutz2022-07-061-2/+0
| | | | | | | | | We're already in the public section. Change-Id: I0d3a04f71574110b7f68edf978ccde9586b18759 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
* qmetatype.h: remove unnecessary specializationThiago Macieira2022-06-281-7/+0
| | | | | | | | | Commit 5db3fd29b42ec06ccb15fdd7f274bb20c326ffb6 removed the expansions that likely needed this. Pick-to: 6.3 6.4 Change-Id: I6d3880c7d99d4fc494c8fffd16fbbe8dcde4a1b1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: move the built-in QMetaTypeInterfaces to read-only segmentsThiago Macieira2022-06-281-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The presence of the mutable causes the const object to lose its constness, so declaring as const wasn't helpful. But we can't drop the const wholesale for MSVC right now because it mangles the variable's type in the external name. For all other compilers, we drop it for user-defined types, which is a no-op but is semantically correct because QMetaType needs to modify those objects. Aside from a few const_cast (marked with comments), nothing else changes. For types with built-in type IDs, however, the QMetaTypeInterface is now fully const... or would be if it weren't full of relocations. It does move the lot from the .data section to the .data.rel.ro section. After this change, QtCore and QtGui have: QtCore QtGui .data.rel.ro 57 23 .data, exported 17 39 .data, private 94 193 sizeof(QtPrivate::QMetaTypeInterface) = 112 on 64-bit platforms (but GCC issues ".align 32", so they effectively occupy 128 bytes) Change-Id: Id0fb9ab0089845ee8843fffd16f9a35bfafebf77 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: extern-template the built-in Core types' QMetaTypeInterfaceThiago Macieira2022-06-281-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This *should* make no difference in behavior, it just prevents the instantiation of the QMetaTypeInterface and all the lambdas used in it in every compilation unit, with a copy in every library. Now, a simple function like: QMetaType f() { return QMetaType::fromType<int>(); } produces only a single function, with a reference into QtCore: _Z1fv: movq _ZN9QtPrivate25QMetaTypeInterfaceWrapperIiE8metaTypeE@GOTPCREL(%rip),%rax ret The code above *does* work on Windows, producing: _Z1fv: movq __imp__ZN9QtPrivate25QMetaTypeInterfaceWrapperIiE8metaTypeE(%rip), %rax ret However, it breaks the staticMetaObjects' metatype listing, because getting the address of a __declspec(dllimport) variable is not a constant expression (it lacks data relocations). So this is disabled on Windows. This change also broke the INTEGRITY build. I've simply disabled the optimization there without attempting to understand why it fails. Task-number: QTBUG-93471 Pick-to: 6.4 Change-Id: Id0fb9ab0089845ee8843fffd16f97748a00b4d64 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qmetatype.h: add QT_FOR_EACH_STATIC_PRIMITIVE_NON_VOID_TYPEThiago Macieira2022-06-241-7/+7
| | | | | | | | | | This allows us to simplify the explicit specialization of the QMetaTypeInterface<void> explicit specialization, dropping the warning push/pop, and remove an unnecessary explicit instantiation. Pick-to: 6.3 6.4 Change-Id: Id0fb9ab0089845ee8843fffd16f9bdccf1965b95 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qmetatype.h: remove unnecessary EXPORT macroThiago Macieira2022-06-241-9/+2
| | | | | | | | | | | | | | | | | | | It was introduced in commit d9f9bc9bada91e3ec2b6c496d3b2242506ca56bc for Qt 6.0 to avoid extern __declspec(dllexport), which MSVC doesn't like, but was made obsolete by commit 77b99e8111cdd06b4fe12f2e18950a1e40ee2b76 that removed the extern templates altogether for MSVC. This change is NOT a no-op because Q_CORE_EXPORT expands to Q_DECL_IMPORT which is __attribute__((visibility("default"))) on ELF platforms. That's actually a good thing, because the symbol is not defined in any library that is not called QtCore anyway. GCC and Linux are also going towards properly requiring imported symbols to be explicitly marked, which this is. Task-number: QTBUG-93471 Pick-to: 6.3 6.4 Change-Id: Id0fb9ab0089845ee8843fffd16f99616883281e3 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* qmetatype.h: remove #undef for something that was never #define'dThiago Macieira2022-06-181-1/+0
| | | | | | Pick-to: 6.3 6.4 Change-Id: Id0fb9ab0089845ee8843fffd16f976868e3ab448 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaType: disable conversion from smart pointer<const QObject>Giuseppe D'Angelo2022-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | QMetaType can register a converter from a smart pointer class to QObject *. The code tries to do so even if the smart pointer is actually holding a pointer to a _const_ QObject (e.g. shared_ptr<const QObject>), causing a compile error: ../src/qt5/qtbase/build/include/QtCore/../../../src/corelib/kernel/qmetatype.h:1208:32: error: invalid conversion from ‘const QObject*’ to ‘QObject*’ [-fpermissive] 1208 | return p.operator->(); | ~~~~~~~~~~~~^~ | | | const QObject* Disable the conversion if indeed the source is const qualified. Change-Id: I9e9bc5992f74131e5cfd6ece9b83d4f26d370e92 Fixes: QTBUG-103741 Pick-to: 6.2 6.3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use SPDX license identifiersLucie Gérard2022-05-161-40/+4
| | | | | | | | | | | | | 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>
* QMetaType: Fix normalization on MSVC if name contains enumFabian Kosmale2022-05-121-1/+1
| | | | | | | | | | | | | | | During type normalization, we remove the struct, class and enum keywords (see the skipStructClassOrEnum function). However, we only want to do that for actual keywords, not for a name that happens to start with e.g. "enum", as in "enumerationNameSpacce". Adjust the MSVC check to still require no identifier character after the keyword, while still allowing for some remaining characters. Fixes: QTBUG-97813 Pick-to: 6.3 6.2 Change-Id: I82b873d02ff454cce4b75f2814a52a66f2268208 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use Q_CC_{GNU,MSVC}_ONLY when comparing to particular versionsMarc Mutz2022-05-061-1/+1
| | | | | | | | | | | | | | | | | This prevents false-negatives and false-positives, as e.g. Clang 10.0.0 masks as GCC 4.2, so Q_CC_GNU is 402 on that compiler. Depending on the test (Q_CC_GNU > NNN or Q_CC_GNU < NNN), the result of the test is almost random. Q_CC_<comp>_ONLY makes sure we match only GCC or MSVC, not bycatch such as Clang or ICC. Pick-to: 6.3 6.2 5.15 Change-Id: I4c550a11ecf85fc9a2216b330b69bd03d45b47e0 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* QMetaType: Add qHash() overloadMårten Nordheim2022-04-051-0/+8
| | | | | | | | | This is needed for use in QHash and similar. It's essentially the same as using the integer id, but typesafe Change-Id: I9515b8e178c8f9828934cb0bb099cce5553ec393 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Apply Q_CONSTINIT across the codebaseMarc Mutz2022-03-291-8/+8
| | | | | | | | | Still not complete. Just grepping for static and thread_local. Task-number: QTBUG-100486 Change-Id: I90ca14e8db3a95590ecde5f89924cf6fcc9755a3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix QMetaType::typeName returning wrong result for clang-clAlexander Neumann2022-02-201-2/+4
| | | | | | Pick-to: 6.2 6.3 Change-Id: I94fa1d56d98b8caae514b37fbf6432985195d827 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qmetatype.h: remove unused includesFabian Kosmale2022-02-091-2/+0
| | | | | | | | | | | [ChangeLog][Potentially Source-Incompatible Changes] The qmetatype.h header no longer includes qvarlengtharray. It might be necessary to include the header explicitly if code previously relied on it being implicitly included. Change-Id: If58245836715ec8a323ec8cbadc67d73a742b15f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Make one QT_REMOVED_SINCE/QT_BUILD_REMOVED_API per moduleMarc Mutz2022-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Prevent repeated instantiations of some qRegisterNormalizedMetaType<>s [1/N] ↵Marc Mutz2022-01-211-7/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (QtGui) Create macros that wrap the magic developed in 7d63efc16f65f98c657caa90e0d7e9b72a879ade and apply it to all Q_DECLARE_METATYPE invocations that show up in Clang -ftime-trace for a PCH'ed QtGui build. Effects on compile times: Clang 10 -ftme-trace: $ ClangBuildAnalyzer --analyze qtgui-before.trace | head -n6 Analyzing build trace from 'qtgui-before.trace'... **** Time summary: Compilation (523 times): Parsing (frontend): 628.3 s Codegen & opts (backend): 304.5 s $ ClangBuildAnalyzer --analyze qtgui-after.trace | head -n6 Analyzing build trace from 'qtgui-after.trace'... **** Time summary: Compilation (523 times): Parsing (frontend): 546.0 s Codegen & opts (backend): 304.4 s GCC 11 time (bash builtin): before: $ time for ((i=0; i < 3; ++i)) do touch src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done real 4m13,539s user 49m24,416s sys 3m18,177s after: $ time for ((i=0; i < 3; ++i)) do touch src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done real 3m55,697s user 45m19,941s sys 3m7,370s Task-number: QTBUG-97601 Pick-to: 6.3 Change-Id: Ia8e37a58937568a7ed21cfeb4b27274deca4d53b Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Prevent repeated instantiations of ↵Marc Mutz2022-01-151-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qRegisterNormalizedMetaType<QList<QModelIndex>>() This, finally, shows some expected results: Clang -ftime-trace: $ ClangBuildAnalyzer --analyze qtgui-spec-before.trace | head -n6 Analyzing build trace from 'qtgui-spec-before.trace'... **** Time summary: Compilation (523 times): Parsing (frontend): 665.7 s Codegen & opts (backend): 298.9 s $ ClangBuildAnalyzer --analyze qtgui-spec-after.trace | head -n6 Analyzing build trace from 'qtgui-spec-after.trace'... **** Time summary: Compilation (525 times): Parsing (frontend): 628.3 s Codegen & opts (backend): 301.0 s GCC 11 time (bash builtin): $ time for ((i=0; i < 3; ++i)) do touch ../qt5/qtbase/src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done [268/268] Creating library symlink qtbase/lib/libQt6Gui.so.6 qtbase/lib/libQt6Gui.so [268/268] Creating library symlink qtbase/lib/libQt6Gui.so.6 qtbase/lib/libQt6Gui.so [268/268] Creating library symlink qtbase/lib/libQt6Gui.so.6 qtbase/lib/libQt6Gui.so real 4m10,918s user 49m10,099s sys 3m11,719s $ git revert --no-commit HEAD $ time for ((i=0; i < 3; ++i)) do touch ../qt5/qtbase/src/gui/painting/qpolygon.h ; ninja libQt6Gui.so; done [268/268] Creating library symlink qtbase/lib/libQt6Gui.so.6 qtbase/lib/libQt6Gui.so [268/268] Creating library symlink qtbase/lib/libQt6Gui.so.6 qtbase/lib/libQt6Gui.so [268/268] Creating library symlink qtbase/lib/libQt6Gui.so.6 qtbase/lib/libQt6Gui.so real 4m18,630s user 51m11,491s sys 3m16,479s The technique in the comment in qmetatype.h doesn't work on Clang - it runs into -Winstantiation-after-specialization. The whole extern template stuff so miserably fails to meet the goals set out in N1448, not only for MSVC and class templates, but, it seems, on all compilers, and for function templates, too, that I'm giving up on it for now. Unfortunately, I'm not really seeing a way to hide this stuff behind a macro, yet. Task-number: QTBUG-97601 Pick-to: 6.3 Change-Id: I500fd04555e0bd76ac021f75582bd8d8cf339378 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add a few explicit conversions back from intThiago Macieira2022-01-121-1/+1
| | | | | | | | | | Suppresses GCC's -Wconversion, which is not enabled by default. error: conversion from ‘int’ to ‘quint8’ {aka ‘unsigned char’} may change value [-Werror=conversion] Change-Id: I0e5f6bec596a4a78bd3bfffd16c998102bd51f7c Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Fix INTEGRITY runtime qobject issueTatiana Borisova2021-12-161-1/+1
| | | | | | | | | | | | | | | | - There is no space symbol in the expression evaluation by GHS compiler. Because of space in prefix constant, begin pointer is moved too far and skips 1 letter in the class name. In result, on testing stage we see: I/O: FAIL! : tst_QObject::property() Compared strings are not the same I/O: Actual (property.typeName()) : ropertyObject::Alpha I/O: Expected ("PropertyObject::Alpha"): PropertyObject::Alpha Pick-to: 6.2 6.3 Change-Id: I52759860fd26b8d50df96dcc4ab0a6b005329a9f Reviewed-by: Kimmo Ollila <kimmo.ollila@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Add a const overload for QMetaType::iface()Ulf Hermann2021-12-061-0/+4
| | | | | | | Change-Id: I865dc51d466d90636e177556d95558ba66f466de Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMetaType: port the BC fix for id() to new QT_REMOVED_SINCEMarc Mutz2021-12-061-1/+2
| | | | | | | The allows qmetatype.cpp compilation to enjoy PCH again. Change-Id: I47c5af33a5dbc930ee4c120b254e732c52bc2369 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Remove unneeded int conversions in qmetatype.hKai Köhne2021-11-191-9/+9
| | | | | | | | | | | | | | | They were added in Qt 5, where QByteArray::reserve() was an int argument, and qstrlen() was returning an int. In Qt 6, both accept and return qsizetype/size_t. As a side effect, this fixes various informational messages when loading a Qt project into Visual Studio 2022: lnt-arithmetic-overflow: A sub-expression may overflow before being assigned to a wider type. Pick-to: 6.2 Change-Id: Ifc9a1f7046a78bcfb97fe241d697c1bf91c6ba4f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMetaType: Avoid superfluous template instantiationsFabian Kosmale2021-10-291-2/+6
| | | | | | | | | | | | Apparently msvc still parses the template and generates code for it when it encounters an extern template declaration. Thus, instead of speeding up compilation, it gets slowed down significantly as the instantiation would happen in every compilation unit that (transitively) included qmetatype.h. Task-number: QTBUG-97601 Change-Id: Id5e934afb14ad8973df1b9197aef336b22220111 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-05 06:39:39 +0000