summaryrefslogtreecommitdiffstats
path: root/src/corelib/global/qflags.h
Commit message (Collapse)AuthorAgeFilesLines
* Break cyclic includes in qglobal.h [2/3]Ahmad Samir2023-05-261-3/+3
| | | | | | Task-number: QTBUG-106722 Change-Id: I6cf2b3fcd419659cc8a0633892393febd26e505b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* 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>
* QFlags: Mark the operators declared in macro maybe_unusedMårten Nordheim2022-09-231-0/+9
| | | | | | | | | | | Because, when used in a .cpp file, the compiler can verify that they are. With warnings-are-errors this breaks compilation for me on windows with clang++. Pick-to: 6.2 6.4 Change-Id: Ib29c3b0b485be2c7d7cf6f1fa4541cac8fe32708 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: Mark the mixed enum operator declared in macro maybe_unusedMårten Nordheim2022-09-231-0/+1
| | | | | | | | | Because, when used in a .cpp file, the compiler can verify that it is. With warnings-are-errors this can break compilation. Pick-to: 6.4 6.2 Change-Id: I2c403d914fca24158dba93f618476521cbcfe39f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | 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>
* Restore C++20-deprecated mixed-enum bitwise operatorsMarc Mutz2022-03-151-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C++20 deprecated arithmetic on enum types. For enums used on QFlags<>, these operators have always been user-defined, but when the two enums are of different type, such as QFrame::Shape and QFrame::Shadow, the deprecation warning pops up. We have in the past fixed these in our headers by manual casts, but that doesn't help our users when our API requires them to OR together enums of different type. Until we can rework these APIs to use a variadic QFlags type, we need to fix it in an SC and BC way, which is what this patch sets out to do. The idea is simply to mark pairs of enums that are designed to be ORed together and replace the deprecated built-in bitwise operators with user-defined ones in C++20. To ensure SC and BC, we pass an explicit result type and use that to check, in C++17 builds, that it matches the decltype of the result of the built-in operator. This patch is the first in a series of similar patches. It introduces said markup macro and applies it to all enum pairs that create warnings on (my) Linux GCC 11.3 and Clang 10.0.0 builds. It is expected that more such markups are needed, for other modules, and for symmetry. Even with this patch, there is one mixed-enum warning left, in qxcbwindow.cpp. This appears to be a genuine bug (cf. QTBUG-101306), so this patch doesn't mark the enums involved in it as designed to be used together. This patch also unearthed that QT_TYPESAFE_FLAGS, possibly unsurprisingly so, breaks several mixed bitwise flags-enum operations (QTBUG-101344). Pick-to: 6.3 6.2 5.15 Task-number: QTBUG-99948 Change-Id: I86ec11c1e4d31dfa81e2c3aad031b2aa113503eb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* QFlags: fix missing bitwise xor operators in QT_TYPESAFE_FLAGS buildsMarc Mutz2022-02-281-0/+4
| | | | | | | | | Add tests that cover them. Pick-to: 6.3 Fixes: QTBUG-101300 Change-Id: I5a8af4a91d796cc4d287b813bd5cc13da3d7e766 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Long live QT_TYPESAFE_FLAGS!Giuseppe D'Angelo2021-06-231-6/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* QFlags: add test(Any)Flag(s)Giuseppe D'Angelo2021-05-151-1/+4
| | | | | | | | | | | | | | | 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>
* 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>
* QFlags: add operator== and !=Giuseppe D'Angelo2021-05-111-0/+13
| | | | | | | | | | | | | 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-111-0/+2
| | | | | | | | | | | | | 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 (named) explicit conversion from/to intGiuseppe D'Angelo2021-05-111-0/+3
| | | | | | | | | | | | | 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>
* QFlags::setFlag: don't go through Int, go through QFlags itselfGiuseppe D'Angelo2021-05-031-1/+1
| | | | | | | | Avoid a "detour" outside QFlags' type safety: operator~ is defined on QFlags already, use that one. Change-Id: Iedd07d1652b8f92e3881298ceafcd5c761346bb0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: streamline some macrosGiuseppe D'Angelo2021-05-021-10/+6
| | | | | | | | | | | | There's little point at keeping the separate Q_DECLARE_INCOMPATIBLE_FLAGS macro, only to invoke it exactly once (from the expansion of Q_DECLARE_OPERATORS_FOR_FLAGS). Besides, Q_DECLARE_OPERATORS_FOR_FLAGS already had some "incompatible" operators in its expansion (the deleted arithmetic ones), so adding the "incompatible" ones in there is consistent. Change-Id: I591d57af8eec5b03ecaa7a3b0de23a967b13f7a5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: remove the doc-only declaration of copy operationsGiuseppe D'Angelo2021-05-021-4/+0
| | | | | | | qdoc is now able to recognize the special members automatically. Change-Id: I773d94d9e622e67340f3acdbe8bff66143ee1aaa Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: kill Q_NO_TYPESAFE_FLAGSGiuseppe D'Angelo2021-05-021-13/+0
| | | | | | | The macro is undocumented and unused. Change-Id: I5c09f4e0e2d41e13d2678e2936e0d0e39ed69639 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Whitespace cleanup in corelib/globalAllan Sandfeld Jensen2020-10-211-2/+2
| | | | | Change-Id: I087d7d949cfd43e48e8a008621a4eeaa9d104ceb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QFlags: remove deprecated constructorEdward Welbourne2020-10-031-7/+0
| | | | | | | | Fix remaining places that still exercised it. Task-number: QTBUG-85700 Change-Id: I84562f53439197141343831c0b9f88983689e6bf Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Disable operator+ and operator- for QFlagsGiuseppe D'Angelo2020-09-091-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and the associated enumeration. Using them is almost always a certain mistake. 1) op+ between two enumerators of the same enumeration yields int, not QFlags, so removing the type safety that QFlags is supposed to give and breaking the semantics of bitwise operations. 2) op+ between two enumerators of different enumerations is deprecated in C++20 (already flagged by GCC10), and again yields int. This is a code smell. Dedicated classes (holding a combination of unrelated enums) should be used instead. 3) op+ between an enumerator and its QFlags loses the semantic meaning of bitwise operations. If the real meaning was to use operator|, then use that instead; operator+ hides the intent, and can introduce bugs by creating a result not expressible via OR combinations of enumerators: enum E { A = 0x01, B = 0x02 }; QFlags<E> f = E::A; f + E::A; // ??? f + E::B; // ??? Identical reasoning applies for operator-. Technically the other arithmetic operators could be disabled as well, but I really don't expect any real-world usage for them. This has spotted bugs in Qt. [ChangeLog][Potentially Source-Incompatible Changes][QFlags] Using operator+ or operator- with a QFlags object or with an enumeration that has a corresponding QFlags object will now result in a compile-time error, because it's a generally unsafe operation. Use the proper bitwise operations instead (|, &, ~); or cast the enumeration to a integral type before attempting arithmetic manipulations on it. Change-Id: I5eabc5195dec3d3082bc9da10dbc8cf5dff3e1eb Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Remove friend declarations that aren't requiredLars Knoll2020-08-151-2/+0
| | | | | | | | | | | | Those are problematic as they are also interpreted as forward declarations of methods that are defined inline in qdatastream.h and might never get instantiated. This can lead to problems if template code checks for the existence of the method. Change-Id: I4550a6bc70ebd7edc57fe0420b89b453195971d0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Replace Qt CONSTEXPR defines with constexprAllan Sandfeld Jensen2020-08-141-45/+45
| | | | | | | | Both normal and relaxed constexpr are required by our new minimum of C++17. Change-Id: Ic028b88a2e7a6cb7d5925f3133b9d54859a81744 Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
* Port Q_STATIC_ASSERT(_X) to static_assertGiuseppe D'Angelo2020-06-191-2/+2
| | | | | | | | | | | | | | | | | There is no reason for keep using our macro now that we have C++17. The macro itself is left in for the moment being, as well as its detection logic, because it's needed for C code (not everything supports C11 yet). A few more cleanups will arrive in the next few patches. Note that this is a mere search/replace; some places were using double braces to work around the presence of commas in a macro, no attempt has been done to fix those. tst_qglobal had just some minor changes to keep testing the macro. Change-Id: I1c1c397d9f3e63db3338842bf350c9069ea57639 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Deprecate constructing QFlags from a pointerAllan Sandfeld Jensen2019-11-201-1/+6
| | | | | | | | | This was used to support QFlags f = 0 initialization, but with 0 used as a pointer literal now considered bad form, it had been changed many places to QFlags f = nullptr, which is meaningless and confusing. Change-Id: I4bc592151c255dc5cab1a232615caecc520f02e8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove handling of missing Q_COMPILER_INITIALIZER_LISTSAllan Sandfeld Jensen2019-05-021-6/+0
| | | | | | Change-Id: Id65b39c787235a051262544932e6717d076f1ea0 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace Q_DECL_NOEXCEPT with noexcept in corelibAllan Sandfeld Jensen2019-04-031-42/+42
| | | | | | | In preparation of Qt6 move away from pre-C++11 macros. Change-Id: I44126693c20c18eca5620caab4f7e746218e0ce3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace Q_NULLPTR with nullptr in corelibAllan Sandfeld Jensen2019-04-031-1/+1
| | | | | Change-Id: I9cdb5b7015c62c50b35f8a6519ea4e777db97683 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* doc: Add template text to \fn commands in qglobal.cppMartin Smith2017-12-081-25/+25
| | | | | | | | | | | | | | This update corrects many qdoc warnings in qglobal.cpp caused by incomplete \fn commands. It also corrects many undocumented parameter errors caused by clang's requirement that the formal parameter names be the same in both the declaration in the include file and the \fn command. Some formal parameter names were changed in the declarations in the header file. Change-Id: I4cd38f30461c585b97ec11923cdbc81a41fe00b8 Reviewed-by: Martin Smith <martin.smith@qt.io>
* Merge remote-tracking branch 'origin/5.10' into devLiang Qi2017-11-301-1/+1
|\ | | | | | | | | | | | | | | | | Conflicts: src/corelib/thread/qsemaphore.cpp tests/auto/network/access/qnetworkreply/tst_qnetworkreply.cpp tests/auto/widgets/itemviews/qtreeview/tst_qtreeview.cpp Change-Id: Id35b535e88df63fdfe4007ea92ed4a39c4b6d707
| * QFlags: support enum classes in setFlag()Giuseppe D'Angelo2017-11-241-1/+1
| | | | | | | | | | | | | | Unary ~ is not defined for enum classes, so we need a cast. Change-Id: I79d495ebcc24ab960da8dae3be08eb307a9de448 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Replace Q_NULLPTR with nullptr where possibleKevin Funk2017-09-191-1/+1
|/ | | | | | | | | | | | | Remaining uses of Q_NULLPTR are in: src/corelib/global/qcompilerdetection.h (definition and documentation of Q_NULLPTR) tests/manual/qcursor/qcursorhighdpi/main.cpp (a test executable compilable both under Qt4 and Qt5) Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* Add QDataStream streaming operator for QFlagsThiago Macieira2017-02-091-0/+4
| | | | | | | | | | | | We're already using it, for example in qpaintengine_pic.cpp:502: d->s << p << ti.text() << fnt << ti.renderFlags() << [...] ^ [ChangeLog][QtCore][QFlags] Added operator<< and operator>> for streaming QFlags into and out of QDataStreams. Change-Id: I33dc971f005a4848bb8ffffd1478e79d6102d1bc Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* Streamline #include <type_traits>Giuseppe D'Angelo2017-01-311-2/+0
| | | | | | | It's included by qglobal.h, so we get it for free in other headers. Change-Id: I90072156e313271a5354a39cbf78a83a6885c431 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove qtypetraits.h's contents altogetherGiuseppe D'Angelo2017-01-121-4/+5
| | | | | | | | | | | | | | | | | So that QFlags can use an (un)signed int matching the underlying type as identified by the compiler and not by us. Requires fixing a few warnings about sign conversion due to QFlags misusages in qtbase that were either plain wrong, or were relying on the enum being backed by an (un)signed int when it wasn't. Keep qtypetraits.h in the source tree in order to prevent source breaks if some downstream #includes it (note however that it did not contain any public API). Change-Id: Ib3a92b98db7031e793a088fb2a3b306eff4d7a3c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rename QtPrivate::is_[un]signed to QtPrivate::Is[Un]signedEnumKai Koehne2016-11-091-1/+1
| | | | | | | | Any other use than for enums should use std::is_[un]signed. Make this explicit by renaming the type traits. Change-Id: I494158563c95c710e710d0d337f4e547006df171 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace custom type traits with std one'sKai Koehne2016-11-081-1/+1
| | | | | | | | | | | | | | | | | | Remove most type traits from qtypetraits.h, but keep the custom implementation of is_signed/is_unsigned. This gets rid of BSD-3 licensed code from Google in a public header (hugh!). The custom implementations for is_signed/is_unsigned are kept because the implementations in gcc's standard headers do not work as we expect for enums - both is_signed and is_unsigned always returns false there - see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59027 [ChangeLog][QtCore][General] Qt now relies on type traits from the C++ standard library. Change-Id: I3f2188b46949f04ca4482a6ac9afd3482103f0e1 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Let Q_DECLARE_METATYPE and Q_DECLARE_FLAGS be undefined under Q_MOC_RUNThiago Macieira2016-05-041-0/+5
| | | | | | | That's required so that they remain in the output from the preprocessor Change-Id: Id69569111e7d4e619e22ffff144b4a1ee90865f0 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* QFlags documentation: The constructors are constexprOlivier Goffart2016-03-291-2/+2
| | | | | | | | | | | One day we might add that information to the documentation itself. But it is important to declare them as constexpr otherwise this causes error while parsing code that wants it to be constexpr when generating the documentation of other constexpr function Change-Id: I28120fea90b29fe1e87af0d8cded0f2430e35443 Reviewed-by: Marc Mutz <marc.mutz@kdab.com> Reviewed-by: Martin Smith <martin.smith@theqtcompany.com>
* Add setFlag method to QFlagsAndre Somers2016-02-081-0/+5
| | | | | | | | | | | | This makes implementing class methods that enable or disable a feature stored in a QFlags<> member easier. [ChangeLog][QtCore][QFlags] Added setFlag method to set or unset a flag Task-number: QTBUG-27100 Change-Id: Ic602abbbf3100df78f21b7918573744d1bbd18c1 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
* Updated license headersJani Heikkinen2016-01-151-14/+20
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* QtCore: Use Q_NULLPTR instead of 0 in all public headersMarc Mutz2015-07-011-1/+1
| | | | | | | | | This is in preparation of adding -Wzero-as-null-pointer-constant (or similar) to the headers check. Task-number: QTBUG-45291 Change-Id: I0cc388ef9faf45cbcf425ad0dc77db3060c104a8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update copyright headersJani Heikkinen2015-02-111-7/+7
| | | | | | | | | | | | | | | | | | Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Outdated header.LGPL removed (use header.LGPL21 instead) Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing combination. New header.LGPL-COMM taken in the use file which were using old header.LGPL3 (src/plugins/platforms/android/extract.cpp) Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license combination Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
* QFlags: plaster API with Q_DECL_NOTHROWMarc Mutz2015-01-051-36/+37
| | | | | | | | | | | | Yes, this is necessary. The noexcept operator looks for noexcept tagging, not at the contents of the function to determine whether to return true. The more conditionally-noexcept functions are used, the more important it becomes that low-level classes are correctly marked noexcept. In that, it is like constexpr. Change-Id: Ia1aebf9b8d73fd8164c10dfca27a710934ba79a8 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* Use Q_DECL_RELAXED_CONSTEXPR in QFlagsOlivier Goffart2014-10-311-7/+7
| | | | | Change-Id: I91073f4bb71e554402fc13cbd0e9ba5b5b95bce0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Update license headers and add new license filesMatti Paaso2014-09-241-19/+11
| | | | | | | | | - Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 - Removed LICENSE.GPL Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2 Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
* Merge remote-tracking branch 'origin/5.3' into devFrederik Gladhorn2014-07-101-6/+15
|\ | | | | | | Change-Id: Ia12ffdb27ecdf25c2a2bdb0eed1945387502108a
| * Attempt to work with Visual Studio in -Za (strict ANSI) modeThiago Macieira2014-07-051-6/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Visual Studio always treats enum values as signed int, even when the value doesn't fit in a signed int (like 0x80000000 or larger than 32- the tags themselves are still signed. That causes ambiguity in creating a QFlag from an enum value. Visual C++ defines __STDC__ in C mode, but we have no macro in C++ mode. Also note that the Windows SDK headers don't compile in -Za mode. Task-number: QTBUG-39700 Change-Id: Ia943cef37ac1f539bd461c3c18200b0c365c72b3 Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
* | Add support for initializer_list construction in QFlagsAdam Majer2014-07-021-0/+17
|/ | | | | | | | [ChangeLog][QtCore][QFlags] Added initializer_list constructor Task-number: QTBUG-39786 Change-Id: I36967c67b489c2a893fb031954f46f5243aba2c4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-12 10:28:00 +0000