summaryrefslogtreecommitdiffstats
path: root/src/corelib/global
Commit message (Collapse)AuthorAgeFilesLines
* Remove Windows 7, 8, and 8.1 codepathsOliver Wolff2021-07-301-14/+2
| | | | | | | Pick-to: 6.2 Task-number: QTBUG-84432 Change-Id: I970d7d7e9ebdcf246a5be32d60066b4e5e948c27 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* tests: fix some -WvolatileMarc Mutz2021-07-281-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | C++20 deprecated compound volatile statements such as pre- and post-increments, to stress that they're not atomic. So instead of volatile i; ~~~~; ++i; you're now supposed to write volatile i; ~~~~; int j = i; // volatile load ++j; i = j; // volatile store which matches more closely what hardware does. Instead of fixing every use of volatile pre- or post-increment in this fashion individually, and realising that probably a few more Qt modules will have the same kind of code patterns in them, write QtPrivate functions to do the job centrally. Change-Id: I838097bd484ef2118c071726963f103c080d2ba5 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QSysInfo: Delete pre-windows 10 codeMårten Nordheim2021-07-281-28/+4
| | | | | | | It's not supported. Change-Id: Id8c6ca7e7ad152620c76b5479ca495e9f64cc354 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QtWidgets: clean up API removalsMarc Mutz2021-07-271-0/+36
| | | | | | | | | | | As suggested by Peppe and Lars, use one file per module to hold the removed functions, not one per major version and subdir. Also, make the remove macro more like QT_DEPRECATED_SINCE. Change-Id: I2ade51ccc8cb8720ece493936775dfd3b5d438d7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Doc: Ensure deprecated APIs in Qt Core are documented as suchNico Vertriest2021-07-231-2/+1
| | | | | | | | | | Added \deprecated [version_since] when needed Remove references to deprecated functions in \sa statements Fixes: QTBUG-94534 Pick-to: 6.2 Change-Id: I3b3d4277d63fc5d6d207c28ff2484aed30b83247 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Use member function instead of template function to resolve native interfaceTor Arne Vestbø2021-07-171-29/+23
| | | | | | | | | | | | | | The use of a freestanding function is not needed now that the name doesn't alias the nativeInterface accessor function, and was just adding complexity to the machinery. People not familiar with the code will have an easier time following the flow through the helper member function, and we no longer need to declare our own export macros. Pick-to: 6.2 Change-Id: I17530b7e89939cfc19ab8ffaa076b7129ae02dcf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Improve error reporting when requesting unsupported native interfaceTor Arne Vestbø2021-07-151-17/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By switching out the static_assert for an enable_if we end up producing a clearer error, at the call site: /qt/qtbase/examples/gui/rasterwindow/main.cpp:69:9: error: no matching member function for call to 'nativeInterface' app.nativeInterface<QNativeInterface::QCocoaGLContext>(); ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /qt/qtbase/src/gui/kernel/qguiapplication.h:176:5: note: candidate template ignored: requirement 'NativeInterface<QNativeInterface::QCocoaGLContext>::isCompatibleWith<QGuiApplication>' was not satisfied [with NativeInterface = QNativeInterface::QCocoaGLContext, TypeInfo = QNativeInterface::Private::NativeInterface<QNativeInterface::QCocoaGLContext>, BaseType = QGuiApplication] QT_DECLARE_NATIVE_INTERFACE_ACCESSOR(QGuiApplication) ^ By using SFINAE for the TypeInfo we can also ensure that it works for types that are not native interfaces, such as if the user tries to call nativeInterface<QString>(). Since we can no longer use decltype(*this) to resolve the base type we need to change QT_DECLARE_NATIVE_INTERFACE_ACCESSOR to take the type as an argument, as we do for other QT_DECLARE_FOO macros. Pick-to: 6.2 Change-Id: Ie3f7e01ab7c3eb3dcc2ef730834f268bb9e81e0c Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Rename QNativeGestureEvent::deltas() to delta(); clarify docsShawn Rutledge2021-07-141-4/+3
| | | | | | | | | | | | | | | | | In QPanGesture this is called delta(). OTOH we have QWheelEvent::pixelDeltas(). Delta is a vector, and there's only one (with two components). Native gestures hold incremental values: e.g. the pinch gesture event provides an incremental amount of either zooming or rotation (so most events have QNativeGestureEvent::value() very close to 0). It's the same with the pan gesture's delta(). Add better docs for swipe and pan gestures. Change-Id: Ia147c7c9a22e084c3700b1620dec46427d792bd1 Reviewed-by: Povilas Kanapickas <povilas@radix.lt> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* qSwap: make it constexprGiuseppe D'Angelo2021-07-071-1/+1
| | | | | | | | | | | C++20 gave us constexpr std::swap, but it makes no sense for qSwap not to be constexpr anyways. [ChangeLog][QtCore][QtGlobal] qSwap is now constexpr. Change-Id: I13f3cbf2870adf5770c62dc00e15004978fc85d9 Pick-to: 6.2 Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Core: `QRandomGenerator` - silence msvc warningTim Blechmann2021-07-011-1/+1
| | | | | | | | silence msvc warning C4244 (possible loss of data) Change-Id: I1f0be8abc5337e05d3fe6d25b9afd9991f498e01 Pick-to: 6.1 6.2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QGlobalStatic: fix warning when using cv-qualified typesMarc Mutz2021-06-301-1/+3
| | | | | | | | | | | | | | | | | | | | | Says GCC: tst_qglobalstatic.cpp: In function ‘{anonymous}::Q_QGS_constInt::Type* {anonymous}::Q_QGS_constInt::innerFunction()’: tst_qglobalstatic.cpp:71:51: warning: type qualifiers ignored on cast result type [-Wignored-qualifiers] 71 | Q_GLOBAL_STATIC_WITH_ARGS(const int, constInt, (42)) | ^ qglobalstatic.h:80:40: note: in definition of macro ‘Q_GLOBAL_STATIC_INTERNAL’ 80 | noexcept(noexcept(Type ARGS)) | ^~~~ tst_qglobalstatic.cpp:71:1: note: in expansion of macro ‘Q_GLOBAL_STATIC_WITH_ARGS’ 71 | Q_GLOBAL_STATIC_WITH_ARGS(const int, constInt, (42)) | ^~~~~~~~~~~~~~~~~~~~~~~~~ Fix by a strategic std::remove_cv_t. Pick-to: 6.2 5.15 Change-Id: If2d81b7965cefdcf3ec115bafb78aabc78d4256c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix usage of logging category on AndroidAssam Boudjelthia2021-06-281-1/+7
| | | | | | | | | | | | | | | Android logs have a tag/category field in each log entry, which currently if defined by Qt, it's being included as part of the message and not used as a tag as it's supposed to be. This patch fixes that behavior. If a non-default category is defined, it will be used as a tag, otherwise the application name is used as before. Pick-to: 6.2 Fixes: QTBUG-94708 Change-Id: Ie56187f23a47cda6d82e14fdec7c8903d3ee40b6 Reviewed-by: BogDan Vatra <bogdan@kdab.com>
* Long live QT_TYPESAFE_FLAGS!Giuseppe D'Angelo2021-06-233-16/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds an opt-in mechanism to kill type-unsafe functions and implicit conversions of QFlags, therefore removing an entire category of bugs that QFlags itself is supposed to protect against: QFlags<E> f; f == 3.14; // OK; f->int, int->double, then operator==(double,double) f & UnrelatedEnum; // OK if of unscoped enum, calls operator&(int) f &= 123; // calls QFlags::operator&=(int) int i = f * 42; // f->int, then operator*(int, int) Thankfully, operator+ and operator- had already been deleted. By defining QT_TYPESAFE_FLAGS one: * disables operators taking (u)int, forcing the usage of an enumeration or another QFlags object; * turns the implicit conversions towards integers/bool in explicit (one can always use fromInt/toInt instead); * adds a convenience set of (in)equality operators against literal 0, in order to keep code like `(flag & bit) == 0` compile. This set can't be added normally otherwise it would add ambiguity; * adds the unary operator~(Enum), turning it into a flag. This is a source incompatible change, in general, so it's opt-in. This is a Qt-internal macro at this point. It can't be offered to users yet because we need to fix some public API flaws first: in some places (e.g. QPainter::drawText) we ask users to do type-unsafe manipulation of flags. A user enabling the macro wouldn't be able to properly use the functions in question. This macro will be enabled in a follow-up commit. Change-Id: I796f2256b446bafc12cdcbaf7de417d12bd3619e Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qsimd: Don't force RDRND on if __AVX2__Thiago Macieira2021-06-221-5/+4
| | | | | | | | | | | | Like AESNI, RDRAND is an optional extra feature that is not always enabled in all parts. Probably something to do with export restrictions, but I've only seen that in low-end parts. Drive-by removal of "AES" where it was no longer relevant. Pick-to: 6.2 Change-Id: I7246c3e7bb894e0d9521fffd168af3fc0fb638a1 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Doc: Add note to Qt::MatchFlags about implementation dependent behaviorPaul Wicking2021-06-211-0/+5
| | | | | | | Pick-to: 6.2 6.1 5.15 Fixes: QTBUG-94374 Change-Id: I7f426c92bf0434998d0793eedd405c1a682a28d9 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
* Fix SSE4.1, RDSEED requirement for clang-cl buildsAllan Sandfeld Jensen2021-06-171-1/+5
| | | | | | | | | | | | | | A misunderstanding seems to have caused several files to be compiled with extra runtime arch options. We need to disable multi-target functions though, because it doesn't work with clang-cl headers. Task-number: QTBUG-88081 Task-number: QTBUG-88434 Pick-to: 6.2 Change-Id: Ic5829540f9007428c80f9a7bd46af35540745ccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Document that WA_TranslucentBackground will not have an effectLaszlo Agocs2021-06-141-3/+6
| | | | | | | | | | | | ...if changed after the widget is shown. Just documents the current state of things. Task-number: QTBUG-60822 Task-number: QTBUG-59126 Pick-to: 6.2 6.1 Change-Id: If8281dce4457707a1673aca7a50744d8b231b030 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QLatin1String: optimize indexOfMårten Nordheim2021-06-111-0/+1
| | | | | | | | | | Some time ago I wanted to use QStringTokenizer with a QL1S haystack and needle to optimize a particular bottleneck. Only to realize the new bottleneck was more expensive (continuously converting both the strings to QString). Change-Id: Ica86db0043c839c2336a3c3886ffbe3875659b5b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Doc: QtCore: Fix more documentation warningsTopi Reinio2021-06-071-1/+1
| | | | | | | | | | | | | | * Omit 'Bluetooth' enum value in QPermission::PermisionType (sic) as that seems to be unimplemented. * Comment out \sa links to internal/undocumented functions. * Fix incomplete template parameters in \fn commands for QProperty methods. Task-number: QTBUG-93995 Change-Id: Ic8e63fca22c9c72325c76f90f537b221f56ebace Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* macOS: allow Qt::AA_DontShowShortcutsInContextMenus overridesVolker Hilsheimer2021-06-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Following the discussion in QTBUG-69452, the resulting change in cc33dd079796437bafed8f42de7fbf8f17d19ec8, and the documentation of QAction::shortcutVisibleInContextMenu, the intention is that the attribute allows the overriding of the platform default. However, QAction did ask both the attribute and the platform integration, making the override impossible. Instead, ask only the attribute, but default the value of the attribute to what the platform integration provides. [ChangeLog][QtGui][QAction] The shortcutVisibleInContextMenu property defaults to the value of the Qt::AA_DontShowShortcutsInContextMenus attribute, which in turn defaults to the platform integration. To override the default, set the application attribute after instantiating QApplication, or override the default for each QAction instance. Task-number: QTBUG-73990 Pick-to: 5.15 6.1 Change-Id: Iaba330913555d93d05efe1b3965a6aea39db5554 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Add support for building with clang-clCristian Adam2021-06-041-15/+20
| | | | | | | | | qmake had support for building with clang-cl as the win32-clang-msvc mkspec. Task-number: QTBUG-89642 Task-number: QTBUG-88081 Change-Id: I0709c289f90fedb121620d1e67ef841602219816 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Doc: Use \deprecated instead of \obsoletePaul Wicking2021-05-263-8/+8
| | | | | | Task-number: QTBUG-93990 Change-Id: I4e512354a49dde6678ca89cabc56bc76ba666bb3 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Farewell Q_DISABLE_MOVEGiuseppe D'Angelo2021-05-262-19/+5
| | | | | | | | | | | | | | | | | | | | In hindsight, this macro is an API mistake, as it should NEVER be used alone, but always in combination with Q_DISABLE_COPY. But in that case, there's a better macro: Q_DISABLE_COPY_MOVE; hence this API is either bad, or completely redundant. A GitHub search reveals that luckily there's a handful of usages in the wild (of which 0 in Qt/dev and KDE). Hence, I'm going for the kill, and removing it entirely. [ChangeLog][Source-Incompatible Changes][QtGlobal] The Q_DISABLE_MOVE macro has been removed. Code that was using it can be ported to Q_DISABLE_COPY_MOVE instead. Change-Id: I7e346f7e2288f3f5a45315f4f6bfaeb2661f1de5 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix compilation for other compilersJanne Koskinen2021-05-241-0/+1
| | | | | | | | Fixes property offset macro compilation issues. Change-Id: I401a9a35acd1d389c670960edb363a4d919cdb76 Reviewed-by: Kimmo Ollila <kimmo.ollila@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QRandomGenerator: let qt_initial_random_value() return 128 bits of dataThiago Macieira2021-05-233-28/+16
| | | | | | | | | | | | It's how much there is in Linux's AT_RANDOM block. I've also removed the check for validity. It's highly unlikely that 128 bits are bad. Change-Id: Id2983978ad544ff79911fffd16723161ea7ec315 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QHash & QRandomGenerator: cooperate to provide a simpler initial seedThiago Macieira2021-05-233-7/+77
| | | | | | | | | | | | | | | | | | | | | | Instead of initializing the whole QRandomGenerator::system(), which in turn gets to checking CPUID and whether the HWRNG works, trust the operating system functions for an initial value. On Linux, we'll use 4 or 8 of the 16 bytes of random data that the kernel populates for us on AT_RANDOM. This should make Qt applications not stall on an early system launch without an RNG daemon, if compiled without getentropy() support. And avoids silly mistakes causing recursion, like QTBUG-78007 found. Additionally, qt_random_initial_value() will most likely not throw either. It's marked noexcept, even though SystemGenerator::fillBuffer could throw on Linux, if the current thread is canceled, but Linux also has AT_RANDOM. That leaves the other Unix systems without getentropy() (read: macOS, since the BSDs have getentropy()). Fixes: QTBUG-69555 Change-Id: Id2983978ad544ff79911fffd1671fca1a9f9044d Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add runtime ARM64 AES checkAllan Sandfeld Jensen2021-05-202-29/+58
| | | | | | | | | | | | Adds runtime CPU detection for Windows and macOS, and switches feature detection of AES to runtime like for x86, So far only on ARM64, since gcc doesn't do function versioning on ARM32, but clang can, so it could be added later. Change-Id: Ibe5d60f48cdae3e366a8ecd6263534ba2b09b131 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Type erase native interfaces via string instead of typeidTor Arne Vestbø2021-05-201-11/+13
| | | | | | | | | | The latter forces users to build with RTTI enabled, as the typeid use is in our public headers. Surprisingly this is also the case even without instantiating the relevant template. Change-Id: Icd18a2b85b250e0b77960797e5c43b7eaf9bd891 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QKeyCombination: code tidiesGiuseppe D'Angelo2021-05-191-3/+3
| | | | | | | | | | | * Use the new QFlags::toInt() instead of an explicit cast. * Don't apply ~ to an enumerator and then convert the result to an int; instead, convert the enumerator to int and then bitwise negate it. The former is going to break in an upcoming commit. Change-Id: I3a798d61452891d2f61f84e2d8e17237f47c5659 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Fix single argument QT_OVERLOADED_MACRO with pedantic warnings enabledTor Arne Vestbø2021-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of QT_OVERLOADED_MACRO combined with pedantic warnings would result in warning: must specify at least one argument for '...' parameter of variadic macro [-Wgnu-zero-variadic-macro-arguments] when used with a single argument, as the QT_VA_ARGS_COUNT macro would end up not passing anything to the last ... argument of the helper macro QT_VA_ARGS_CHOOSE. To work around this we extend the arguments passed to QT_VA_ARGS_CHOOSE by one, adding a zero-count, so that the variadic parameter always has at least one argument. Unfortunately this doesn't give us a count of 0 if a overloaded Qt macro is used without arguments, due to __VA_ARGS__ always being treated as an argument to QT_VA_ARGS_CHOOSE, even when empty, due to the comma after it. The result is that we end up calling the 1-argument macro for this case as well. Getting a correct zero-count, for both MSVC and GCC/Clang, without using GCC extensions, is quite involved, so we're opting to live with this limitation. See https://stackoverflow.com/a/62183700 for details. Fixes: QTBUG-93750 Pick-to: 6.1 Change-Id: Ib7b26216f36a639642a70387e0d73223633ba6b6 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live qToUnderlyingGiuseppe D'Angelo2021-05-182-0/+16
| | | | | | | | | | | "Cherry-pick" of C++2b's std::to_underlying. [ChangeLog][QtCore][QtGlobal] The qToUnderlying function has been added, to convert an value of enumeration type to its underlying value. Change-Id: Ia46bd8e4496e55174171ac2f0799eacbcca02cf9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qglobal.cpp: build under QT_NO_EXCEPTIONSGiuseppe D'Angelo2021-05-181-3/+9
| | | | | | | | | | | | | | | | | The boostrap library is built with exceptions disabled, and its sources include qglobal.cpp. Therefore, the file must work when built w/o exceptions. Amend/partially revert 282b724808ea4524ed09b9f0183055fdffc3c38a with the necessary fixes. Driveby, cleanup an unnecessary QT_THROW (just throw, if we do have exceptions). Change-Id: I370c295c21edd3d81a9fa670e60909b29d1c68aa Pick-to: 6.1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Make qTerminate available when QT_NO_EXCEPTIONS flag is setAlexey Edelev2021-05-162-11/+3
| | | | | | | | | | | | It seems that QtCore could only be compiled with exceptions enabled. Therefore it doesn't make sense to keep conditonal code under QT_NO_EXCEPTIONS in qglobal.cpp. qTerminate may be called whether exceptions are enabled or not. Pick-to: 6.1 Fixes: QTBUG-93739 Change-Id: Ie49c10f27cfa75360f018e8638603e6a1791450e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: add test(Any)Flag(s)Giuseppe D'Angelo2021-05-152-1/+42
| | | | | | | | | | | | | | | QFlags was lacking a named function for testing whether a QFlags object contains _any_ of the bits set by a given enumerator/other QFlags. Drive-by, add testFlags taking a QFlags, not just an object of the enumeration; and simplify the implementation of testFlags to more closely follow what its documentation says it does. [ChangeLog][QtCore][QFlags] The testFlags, testAnyFlag and testAnyFlags functions have been added. Change-Id: Ie8688c8b0dd393d34d32bc7786cdcee3eba24d1c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* native interface plumbing: Fix ambiguities with existing classes named TypeInfoFriedemann Kleint2021-05-141-3/+2
| | | | | | | | | | | | | | As is the case in Qt for Python, causing: QtCore/qcoreapplication.h: In member function I* QCoreApplication::nativeInterface() const: QtCore/qcoreapplication.h:163:5: error: reference to TypeInfo is ambiguous 163 | QT_DECLARE_NATIVE_INTERFACE_ACCESSOR Amends 7feeb7c34b9fbab2593b958354dd57b4c487d5fe. Change-Id: I7d363e1d8c0a0f648d12f8040afb9d071356cbb8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QFlags::testFlag: code tidiesGiuseppe D'Angelo2021-05-131-1/+1
| | | | | | | | | | If the condition Int(flag) != 0 is false, it means that flag == 0. So just check i against 0, which is more in line with what testFlag behavior is documented to do. Change-Id: Ia75fa07eee65e67a769fda7c020bf17ada77e9a3 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QAbstractItemModel::match: code tidiesGiuseppe D'Angelo2021-05-122-0/+2
| | | | | | | | Remove a magic number from the code, by adding it (as a private value) to the right enumeration. Use toInt() to convert to integer. Change-Id: Id1b00dde900619684b5a3df247d46938439150ca Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rejig native interface plumbingTor Arne Vestbø2021-05-122-15/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The initial approach for providing public access to native interfaces via T::nativeInteface<I>() was based on the template not being defined, and then having explicit instantiations of the supported types in a source file, so that the accessors were exported and available to the user. This worked fine for "simple" types such as QOpenGLContext and QOffscreenSurface, but presented a problem in the context of classes with subclasses, such as Q{Core,Gui}Application. To ensure that a native interface for QCoreApplication was accessible both from QCoreApplication and its subclasses, while at the same time preventing a native interface for QGuiApplication to be accessible for QCoreApplication, the nativeInterface() template function had to be declared in each subclass. Which in turn meant specializing each native interface once for each subclass it was available in. This quickly became tedious to manage, and the requirements for exposing a new native interface wasn't very clear with all these template specializations and explicit instantiations spread around. To improve on this situation, while also squashing a few other birds at the same time, we change the approach to use type erasure. The definition of T::nativeInteface<I>() is now inline, passing on the requested interface to a per type (T, not I) helper function, with the interface type flattened to a std::type_info. The type_info requested by the user is then compared to the available types in a single per-type (T) "switch statement", which is a lot easier to follow for someone trying to trace the logic of how a native interface is resolved. We can safely rely on type_info being stable between the user application and the Qt library as a result of exporting the type info for each native interface, by explicitly ensuring they have a key function. This is the same mechanism that ensures we can safely dynamic_cast these interfaces, even across library boundaries. The use of a free standing templated helper function instead of a member function in the type T, is to avoid shadowing issues, and to not pollute the class namespace of T with the helper function. Since we are already changing the plumbing for how a user resolves a native interface for a type T, we take the opportunity to add a few extra safeguards to the machinery. First, we add a static assert in the T::nativeInteface<I>() definition, that ensures that only compatible interfaces, as declared by the interface themselves, are allowed. This ensures a compile time error when an incompatible interface is requested, which improves on the link time errors we had prior to this patch, and also offsets the one downside of type erasure, namely that errors are only caught at runtime. Secondly, each interface meant for public consumption through T::nativeInteface<I>() is declared with a revision, which is checked when requesting the interface. This allows us to bump the revision when we make breaking changes to the interface that would have otherwise been binary incompatible. Since the user will never see this interface due to the revision check, they will not end up calling methods that have been removed or renamed. One advantage of moving to a type-erased approach for the plumbing is that we're not longer exposing the native interface types as part of the T::nativeInteface symbols. This means that if we ever want to rename a native interface, the only exported symbol that the user code relies on is the type info. Renaming is then possible by just exporting the type info for the old interface, but leaving it empty. Since no class in Qt implements the old native interface, the user will just get a nullptr back, similarly to bumping the revision of an interface. Change-Id: Ie50d8fb536aafe2836370caacb22afbcfaf1712a Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* fix build for no feature futureLorn Potter2021-05-121-0/+1
| | | | | | | | | | | This amends afd7460affa17b5f8aac9034b1b9c3b13dd115f7 Add new app permissions API under QCoreApplication Which added QFuture use without protection for platforms with no real future. Change-Id: Iac50a71c9821255621d7582481270b2023610405 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* QFlags::testFlag: clarify the behavior in the docsGiuseppe D'Angelo2021-05-111-0/+8
| | | | | | | | | | | | | The name made me fall in a trap: I thought that testFlag returned true if *any* of the bits in the argument were set in the QFlags object. In reality, it returns true if *all* the bits are set, and an argument equivalent to 0 is treated specially. Clarify this in the documentation. Change-Id: I9e8088c48038b4e6ba5830fdb7e473c6d7884b29 Pick-to: 5.15 6.0 6.1 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: add operator== and !=Giuseppe D'Angelo2021-05-112-0/+37
| | | | | | | | | | | | | It's a value type, and we don't need detours through implicit conversions (which are a real disgrace, as they make nonsense like `flags != 3.14` well-formed). [ChangeLog][QtCore][QFlags] Added overloads of operator== and operator!= between QFlags objects, and between a QFlags object and an object of the flag's enumeration. Change-Id: I36701dea8fcd4cc64941e78af58fa7d38a15a8c7 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Q_DECLARE_OPERATORS_FOR_FLAGS: also define operator&Giuseppe D'Angelo2021-05-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bitwise ANDing an enum and a QFlags should yield identical results as ANDing a QFlags and the enum. This latter operator already existed, so add support for the former. Plus, ANDing two enumerators of a flag type should yield a QFlags, and not a plain int. (Note that an arbitrary amount of bits can be set in the result of such operation, as the enumerators themselves may be masks with more than 1 bit set.) This is slightly source incompatible, as we're changing the return type of operator&. Code that was assigning that result to `int` still works as expected, but code that wanted the value back in a QFlags may have inserted some conversions like: flag = Enum(enumerator & otherFlag); ^--------------------- used to yield int, now QFlags which are now going to break as there's no QFlags->Enum conversion. An earlier attempt of this patch, introduced -- and immediately deprecated -- such a conversion, under the form of explicit operator Enum() const; in order to keep such old code working both before and after this change. The problem is that MSVC has a bug with explicit conversions to enumerations [1], which get accidentally considered when they shouldn't, and thus making a lot of code stop compiling due to (false) ambiguities. So, I'm not adding that operator any more. Note that there's a way to keep code working before and after this change: just use flag = Flags(enumerator & otherFlag); // Flags, not Enum (thanks Edward), which goes through a int -> QFlag -> QFlags conversion, and arguably is the idiomatic way of writing such code; or use flag = otherFlag & enumerator; which, as discussed above, has always returned a QFlags. [1] https://developercommunity2.visualstudio.com/t/explicit-conversion-operator-to-enum-is/1412616 [ChangeLog][Potentially Source-Incompatible Changes][QFlags] Bitwise AND-ing two values of an enum type for which flag operations have been declared now produces a QFlags object. Similarly, AND-ing a value of enum type and one of type QFlags now produces a QFlags object. Before, it produced an integer in both cases. This may introduce a slight incompatibility in user code; it is possible to keep the code working in Qt versions before and after this change by inserting enough conversions to QFlags, and/or by changing expressions such as `enum & flag` to `flag & enum` (the latter has always produced a QFlags object). Change-Id: I6e645c010d3aa677820545b0c25678f1dc9a3295 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: add operator& / &= overloads taking a QFlags objectGiuseppe D'Angelo2021-05-112-0/+16
| | | | | | | | | | | | | It makes no sense to offer the "type-unsafe" operators taking a plain int, and not offer the ones taking a QFlags object. Using these operators has actually always worked by going through a conversion to int, but we're going to limit that possibility in the future. [ChangeLog][QtCore][QFlags] The operator& and operator&= now accept a QFlags object. Change-Id: Iee0845640014d35b646787e8bdb77854f180a9ef Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: plaster Q_IMPLICITGiuseppe D'Angelo2021-05-111-11/+11
| | | | | Change-Id: Ic56a32d354e6868f2e01771975c00509a9d91296 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: add qHash overloadGiuseppe D'Angelo2021-05-111-0/+9
| | | | | | | | | Stop going through the implicit int conversion. [ChangeLog][QtCore][QFlags] QFlags now has a qHash() overload. Change-Id: Id380ed252695f24af2e8c239b650dcb6f44e2893 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: add (named) explicit conversion from/to intGiuseppe D'Angelo2021-05-112-0/+21
| | | | | | | | | | | | | There are some use cases where one may want to convert a QFlags object from/to an integer deliberately; for instance, to store it in a bitfield, saving some space. So far this worked by means of a implicit conversions; instead, also add named conversions for this. [ChangeLog][QtCore][QFlags] Added the fromInt() and toInt() functions for explicit conversions from/to a plain integer. Change-Id: I705559bf75b28c30b4446bb6d0753aedfc808eed Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* PRIx macros: add missing \relates to the docsGiuseppe D'Angelo2021-05-101-0/+4
| | | | | | | Otherwise they won't appear. Change-Id: I19d93aef9acb9d7afced8acbc76813a30b572953 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Move QNativeInterface helpers to their own header fileTor Arne Vestbø2021-05-102-24/+73
| | | | | | | | | The machinery is not needed for all translation units, so keep it out of qglobal.h. Change-Id: Ib0459a3f7bc036f56b0810eb750d4641f567f1fe Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Tweak naming of QT_OVERLOADED_MACRO variantsTor Arne Vestbø2021-05-041-4/+4
| | | | | | | | Add a _ suffix before the number of arguments, to improve readability of the argument-specific functions. Change-Id: I1dfc4f381450825dd143ece524bb10e117c09971 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Delete less-than operator for QKeyCombinationVolker Hilsheimer2021-05-041-0/+2
| | | | | | | | | | | | | | | | | | QMetaType relies on QTypeTraits to identify whether a type provides operator<. Due to the the deprecated implicit conversion to int, this results in several screens of deprecation warnings when using QKeyCombination in a signal parameter or as a property type. QKeyCombination has no ordering semantics (is Alt+F5 larger than Control+Up?), so delete the operator. [ChangeLog][QtCore][QKeyCombination] Potentially source-incompatible change: the less-than operator for QKeyCombination has been deleted. Code relying on the deprecated implicit conversion to int will no longer compile. Use QKeyCombination::toCombined explicitly. Change-Id: Ic8522b88d68063f74b5a5582c51aee8e18982331 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-21 17:30:04 +0000