Was meant to be >=, not <.
Amends ab06d402dd833cefe9c0d929c13e93068aab96d9
Pick-to: 6.7
Change-Id: I5aa2236d2ffc7274e14918aea28c9a3e3545b6c4
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit d6eda60b330e72570be9ce43ce5dc01cd8851665)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
... which claim full C++20 conformance (__cplusplus >= 202002), but
still lack https://wg21.link/P0846.
Fix by extending the existing workaround for lack of P0846 support to
these compilers.
Known to fail: _MSC_VER 1936
Known to pass: _MSC_VER 1939
We might need to check 1938 and 1937, but the workaround should only
show up as an additional get/get_if overload and not disturb normal
operation, so it's not critical to get the boundary version exactly
right.
Amends eb9c8042cfa71f16cda27cdeb052d84a6cc117d7.
Pick-to: 6.7
Task-number: QTQAINFRA-6204
Change-Id: Ia3e0072d606efb7efd6ce0f75239850c7cd925bb
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The lengthHelperContainer() implementation for sizeof(Char) == 1 case
is using qstrnlen() for the non-constexpr case.
qstrnlen() is an inline function which is effectively a nullptr check
and a memchr() call.
For some reason, on MSVC this combination resulted in very slow
compilation for the user projects, where each call to
QObject::setObjectName() was hitting this codepath.
Fix it by replacing the qstrnlen() call with strnlen_s() for MSVC.
It seems that for now all versions of MSVC are affected. However,
introduce a new Q_COMPILER_SLOW_QSTRNLEN_COMPILATION definition,
which will allow us to check for the compiler version later on.
For now this definition is set for all MSVC versions unconditionally.
Fixes: QTBUG-124376
Pick-to: 6.7 6.7.1
Change-Id: Id769bef1e950ffa756acf7af39d362fd8b112019
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Clang supports `__attribute__((fallthrough))`. While C++ sources use
[[attribute]], the C codepath still requires a fallback.
Pick-to: 6.7
Change-Id: Iaa93d2debc21fdd34e414ddb024b95942ae9191f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We'll need this in more places, so centralize its definition in
qcompilerdetection.h.
Amends 595b4e1a9b436a8190964dc41f79621400f5a6be.
Pick-to: 6.7 6.6 6.5
Change-Id: I87f84cb9ff3ad339c000604423295180176f5799
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
We only used it in one location and it's no longer needed.
Change-Id: I2092313b75d4510dda12f8f6decc9652f8191301
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
These macros should unwrap into a proper set of equality and ordering
operators, depending on the C++ standard being used.
For C++17, all 6 operators (==, !=, <, >, <=, >=) are overloaded, while
for C++20 only the overloads for opeartor==() and operator<=>() are
provided.
The macros are documented as internal for now.
The macros rely on two helper functions:
bool comparesEqual(LeftType lhs, RightType rhs);
ReturnType compareThreeWay(LeftType lhs, RightType rhs);
The comparesEqual() helper function is used to implement operator==()
and operator!=().
The compareThreeWay() helper function is used to implement the four
relational operators in C++17, or operator<=>() in C++20.
ReturnType must be one of Qt::{partial,weak,strong}_ordering.
When possible, the functions should also be declared constexpr and
noexcept.
It's the user's responsibility to provide the functions before
using the macros.
Implement a test case which applies the new macros to the dummy
classes, and uses the new helper function to verify the comparison
results.
The MSVC compiler before version 19.36 has a bug, where it fails
to correctly generate reverse opeerators in C++20 mode. Introduce
a new Q_COMPILER_LACKS_THREE_WAY_COMPARE_SYMMETRY definition for such
compiler versions, and use it to manually generate reversed
operators when needed.
Task-number: QTBUG-104113
Change-Id: Idc19d55df011fd616ff654f35a964e831b8ab93b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
stdext is deprecated, slated for removal.
The macros were used to work around a compiler warning generated
when using the 3-arg overload of certain STL algorithms even when
the 4-arg version (added in C++14) was not available.
These deprecation warnings seem to have been discontinued as of
MSVC++ 14.15 _MSC_VER == 1915 (Visual Studio 2017 version 15.8)
so making the macros no-ops from VS 2022 17.8 onward is not expected
to trigger these warnings again.
Pick-to: 6.6 6.5 6.2 5.15
Fixes: QTBUG-118993
Change-Id: I2c3b69d46d13f6fcccf0ffce186b984b7758f287
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The Q_DECL_{IMPORT,EXPORT} macros change with the configuration, so the
lack of our configuration this ended up producing inconsistent builds.
Amends 43ec3d8d011f1c067be2257ba657838f2c118415.
Pick-to: 6.6
Change-Id: Ifeb6206a9fa04424964bfffd17892394d19e648f
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
MSVC seems to emit warnings failing the build in some situations where a
return statement comes after a Q_UNREACHABLE. This does not seem to
happen on other compilers. The Q_UNREACHABLE_RETURN macro already exists to deal with this situation. Define it for MSVC.
Change-Id: Iad06f4048e2829b1eac4f78a1053041ef72c21e7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Wrappers around P1301 [[nodiscard("reason")]].
[ChangeLog][QtCore][Q_NODISCARD_X/Q_NODISCARD_CTOR_X] Added as
wrappers around C++20 [[nodiscard("reason")]].
Task-number: QTBUG-114767
Change-Id: Ie566d9c9d500ef632c7e243af97081f83506a752
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
They both check __has_cpp_attribute(nodiscard), so keep them together.
Move the fall-back (empty) definition to the block that does the same
for all other such macros.
Mention that both P1771 ([[nodiscard]] for ctors) and P1301
([[nodiscard("reason")]]) use the same numerical value.
Amends 959800f6de137f6a77c7d5a2741a5bae0638cbd9.
Pick-to: 6.6
Change-Id: I0ef913b6076ffa4058220b542303591de6fefde7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
And add some additional parenthesis for extra safety.
Amends f7c8ff511c30dc4310a72b3da4b4a345efe1fba0.
Pick-to: 6.6 6.5
Change-Id: I4ca8b70f6adb876a10f82685ba9800021218d418
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Although the header is available, and the compiler reports that the
standard library supports memory_resource, the feature is only
available on macOS 14 and iOS 17, as reported by
https://developer.apple.com/xcode/cpp/
As long as our deployment target is lower we can't unconditionally
use this feature. It's not clear whether the expectation is that
consumers of the standard library on these platforms will have to
runtime check their uses of these APIs.
Pick-to: 6.6 6.5
Task-number: QTBUG-114316
Change-Id: I50c1425334b9b9842b253442e2b3aade637783ea
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Remove qglobal.h include from qcompilerdetection.h, qsystemdetection.h
and modulecppexports.h.in
Testing locally, the code builds on Linux with precompiled headers
disabled/enabled (qt_pch.h includes qglobal.h, so building with PCH
enabled isn't useful for testing this) and with/without bootstrap.
qrunnable.*: missing includes detected by compiling with
-DFEATURE_headersclean=ON.
Task-number: QTBUG-106722
Change-Id: I70864dfbf117ffd7fe492eb715a413eb6f209990
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
[ChangeLog][QtCore] Introduced Q_NODISCARD_CTOR which resolves to
[[nodiscard]] attribute for constructors on compilers that support
it, and does nothing on other compilers.
Using [[nodiscard]] attribute on a constructor is a C++20 feature,
however in practice it is supported on most of the compilers that
we use in Qt 6. Clang generates a [-Wunused-value] warning, GCC
and MinGW generate a [-Wunused-result] warnings, and MSVC
generates a C4834 warning.
However, there are some exceptions.
The Integrity compiler provides the following warning:
"tst_qglobal.cpp", line 699: warning #3435-D:
the "nodiscard" attribute doesn't apply to constructors,
destructors, or routines with void return type
[[nodiscard]] explicit Test(int val) : m_val(val) {}
The QNX compiler (QCC 8.3.0) and GCC 9.3.1 on OpenSUSE generate
the [-Wattributes] warning:
tst_qglobal.cpp: In member function
'void tst_QGlobal::nodiscardConstructor()':
tst_qglobal.cpp:699:44: warning: 'nodiscard' attribute applied to
'tst_QGlobal::nodiscardConstructor()::Test::Test(int)' with void
return type [-Wattributes]
[[nodiscard]] explicit Test(int val) : m_val(val) {}
These warnings will lead to build failures when compiled with
-warnings-are-errors flag, so for these compilers the macro
does not do anything.
An attempt to use __attribute__((__warn_unused_result__)) was
also unsuccessful on these compilers, so this patch goes for
an easy solution, and simply checks
__has_cpp_attribute(nodiscard) >= 201907L
to decide if the attribute is supported or not.
This commit also introduces a syntax-only test, and also applies
the new macro to QMutexLocker, because not all platforms in the
CI build and run unit tests.
Fixes: QTBUG-104161
Change-Id: Ib4230661a5ad5e8af0d67b21b034486ebcd67562
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In C++17, unqualified lookup doesn't find function templates that
require ADL from a call with explicit template arguments, unless
another function template of that name is in scope (otherwise, the <
is parsed as operator less-than instead).
P0846, merged for C++20, fixes this to repeat the name lookup, parsing
the < as indicating a template.
We have API in Qt (Tuple Protocol for some types, e.g. QPoint) that
work for the purpose of Structured Bindings, but don't work for manual
unqualified calls when P0846 semantics are missing, and we're adding
more, to QVariant, so add a macro to handle the issue.
The macro simply declares a function template overload of the given
name for a throw-away struct, thereby bringing, for that one name,
P0846 semantics into C++17.
When we require C++20, we can drop this again.
Amends:
- fb6b7869e8bdda94f7e791db7f281f3bb6e0e004 for QPoint(F)
- 8ae9431c792f14a32909ac013a1383547d6bcfa8 for QMargins(F)
- 0e22001a3bb070d4e9956e89543ec0e5ac6f23f8 for the rest
[ChangeLog][QtCore][QSize/F, QMargins/F, QPoint/F] Fixed manual
get<I>() calls (Tuple Protocol) in C++17 mode.
Task-number: QTBUG-111598
Change-Id: I2ffaef12c5bb6d82f75ce78a7c03c6789dfa0691
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
I got tired of being told off by the inanity 'bot for faithfully
reflecting existing #if-ery in new #if-ery. Retain only the
documentation and definition of the deprecated define.
Change-Id: I47f47b76bd239a360f27ae5afe593dfad8746538
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Remove a redundant QT_VISIBILITY_AVAILABLE check. Pointed out by Thiago
in review.
Note that this is going to help with breaking include cycles between
qglobal.h and qcompilerdetection.h (otherwise we'd have to include
qtconfiginclude.h in qcompilerdetection.h as the former includes
qconfig.h which defines QT_VISIBILITY_AVAILABLE; without
QT_VISIBILITY_AVAILABLE defined, Q_DECL_EXPORT/IMPORT expands to
nothing on Linux and co., and tools linking to qtcore (with bootstrap)
can't find exported methods.
Change-Id: Ib1244d43e606a6c80e122adea631305f6d8c51d3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
build/include/QtCore/../../../src/corelib/global/qcompilerdetection.h:546:7:
warning: '__cplusplus' is not defined, evaluates to 0 [-Wundef]
# if __cplusplus >= 201103L || defined(__GXX_EXPERIMENTAL_CXX0X__)
^
build/include/QtCore/../../../src/corelib/global/qcompilerdetection.h:648:7:
warning: '__cplusplus' is not defined, evaluates to 0 [-Wundef].
# if __cplusplus > 201103L
^
Change-Id: I8ed8e0c4b93977238986df0b3339ffae4d1d0fda
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This is similar to Q_COMPILER_MANGLES_RETURN_TYPE, except that the
other such compiler, SunPro CC, at least by my cursory reading of
https://archive.org/download/SunWorkshopVol5No1/Sun%20WorkShop%E2%84%A2%20for%20Solaris%202.x%20Volume%205%20Number%201.iso/SPROmrcpl%2Freloc%2FSUNWspro%2FSC4.2%2FREADMEs%2Fmangling.ps
doesn't appear to mangle the access specifier. So it's only MSVC. It's
still better to have a properly-named macro for this than to work with
Q_CC_MSVC and, hopefully, an explanatory code comment.
May come in handy to maintain BC when we find the need to change an
access specifier in the future. The original use-case, in QtPositioning,
was fixed differently. If nothing else, let's have it to raise awareness
of the issue.
Pick-to: 6.5
Change-Id: Ia8b789d2713ec19487a21c6bb0a12cf285e6ba83
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The reason for having a link to a "user page" on cppreference was to
have in the same place the papers, feature-test macro and corrisponding
value. This information has now been updated in a "official" page so we
can just link to that one instead.
Change-Id: I42658a46c8c0d3b78e1c10c06c81fa4bc78af9aa
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Both links are valid for both C++14/17 and C++20+ variants, they're
just sorted differently. Mention that.
Pick-to: 6.4
Change-Id: Id88ec05f935fd6d01c0f1e733ca42faaaa88dd25
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
This allows us to check whether Qt is compiled with ASAN enabled; it is
mostly used to disable tests which are too slow under ASAN
Change-Id: I381e287c4a72ffefd4cc92850451477032ad4204
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Using wrappers for these macros is problematic when for example passing
the -frewrite-includes flag to preprocess sources before shipping off to
distcc or Icecream. It will also start producing warnings when compilers
implement http://eel.is/c++draft/cpp.cond#7.sentence-2. See for example
https://reviews.llvm.org/D49091
Now that all uses of the macros are gone, we can follow up
c3bd5ffdc8a3b459f18ba6e35fca93e29f3b0ab0 and remove the wrappers.
Change-Id: I764aea17dcdabd420097a7f4bc0b987a53a345eb
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
...and update the documentation for how we detect post-C++11 features,
as proposed on the mailing-list:
https://lists.qt-project.org/pipermail/development/2022-November/043248.html
According to https://en.cppreference.com/w/cpp/compiler_support,
<version> is available from
- libstdc++ from GCC 9
- libc++ from LLVM 7
- MSVC 19.22 = VS 2019 16.2
- AppleClang 10 = Xcode 10.0 beta (10L176w), 10.0 (10A255), 10.1 (10B61)
It is _not_ available on
- GHS 22.1.4
- GCC 8.3.0 (as used by QNX 7.1, but the default is libc++)
Pick-to: 6.4
Task-number: QTBUG-108228
Change-Id: I61e0727573d1b4559228e3f5bd58d73e86a9256e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
This is a combination of Q_UNREACHABLE() with a return statement.
ATM, the return statement is unconditionally included. If we notice
that some compilers warn about return after __builtin_unreachable(),
then we can map Q_UNREACHABLE_RETURN(...) to Q_UNREACHABLE() without
having to touch all the code that uses explicit Q_UNREACHABLE() +
return.
The fact that Boost has BOOST_UNREACHABLE_RETURN() indicates that
there are compilers that complain about a lack of return after
Q_UNREACHABLE (we know that MSVC, ICC, and GHS are among them), as
well as compilers that complained about a return being present
(Coverity). Take this opportunity to properly adapt to Coverity, by
leaving out the return statement on this compiler.
Apply the macro around the code base, using a clang-tidy transformer
rule:
const std::string unr = "unr", val = "val", ret = "ret";
auto makeUnreachableReturn = cat("Q_UNREACHABLE_RETURN(",
ifBound(val, cat(node(val)), cat("")),
")");
auto ignoringSwitchCases = [](auto stmt) {
return anyOf(stmt, switchCase(subStmt(stmt)));
};
makeRule(
stmt(ignoringSwitchCases(stmt(isExpandedFromMacro("Q_UNREACHABLE")).bind(unr)),
nextStmt(returnStmt(optionally(hasReturnValue(expr().bind(val)))).bind(ret))),
{changeTo(node(unr), cat(makeUnreachableReturn,
";")), // TODO: why is the ; lost w/o this?
changeTo(node(ret), cat(""))},
cat("use ", makeUnreachableReturn))
);
where nextStmt() is copied from some upstream clang-tidy check's
private implementation and subStmt() is a private matcher that gives
access to SwitchCase's SubStmt.
A.k.a. qt-use-unreachable-return.
There were some false positives, suppressed them with NOLINTNEXTLINE.
They're not really false positiives, it's just that Clang sees the
world in one way and if conditonal compilation (#if) differs for other
compilers, Clang doesn't know better. This is an artifact of matching
two consecutive statements.
I haven't figured out how to remove the empty line left by the
deletion of the return statement, if it, indeed, was on a separate
line, so post-processed the patch to remove all the lines matching
^\+ *$ from the diff:
git commit -am meep
git reset --hard HEAD^
git diff HEAD..HEAD@{1} | sed '/^\+ *$/d' | recountdiff - | patch -p1
[ChangeLog][QtCore][QtAssert] Added Q_UNREACHABLE_RETURN() macro.
Change-Id: I9782939f16091c964f25b7826e1c0dbd13a71305
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Just to persist the knowledge of how to detect it for the next guy.
Pick-to: 6.4 6.2 5.15
Change-Id: I16847d02ce60fab0ae14ffb2688f2ee92fa6a9f2
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The description of the macros in this header should not belong to
<QtGlobal>, so move it to a separate documentation page.
Task-number: QTBUG-106154
Change-Id: Ic31604b96d9ebea6e8aac285b00a8d4c82b15c9a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's not needed for any of our supported compilers and isn't used in
Qt codbase anymore. It was only required for IBM xlC compiler, which
doesn't seem to support C++17 at the moment (when it does, hopefully
they will also fix the issue).
[ChangeLog][QtGlobal] Removed the Q_DUMMY_COMPARISON_OPERATOR macro,
which was needed to workaround outdated template instantiation rules
on some outdated compilers.
Fixes: QTBUG-105098
Change-Id: I2b992dd8c0f389d874d2a8521fc1a1aad3f80699
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Use C++98's __cpp_exceptions to check if exceptions are enabled by gcc
and clang. Q_CC_GNU is always defined when Q_CC_CLANG is, so simplify
the condition and check only for Q_CC_GNU.
Change-Id: I1e15643ded9684f9e4e6eba1be9479665b526766
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
These seem to be leftovers after
475cef58f96d1d274e5c7b448df7231415783af0.
Task-number: QTBUG-99313
Change-Id: I6059cfe1ea0a0f85e3617338215effb114d3b60b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add the qt_sync_skip_header_check and qt_sync_stop_processing pragmas
to:
qtbase/src/corelib/global/qsystemdetection.h
qtbase/src/corelib/global/qprocessordetection.h
qtbase/src/corelib/global/qcompilerdetection.h
to avoid checking by synqt. These files were previously blacklisted
in syncqt.profile.
Change-Id: I268a3063e7eafb9a78e9e8d1cb67cd2def490b35
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As a drive-by, add a link back to Q_ASSUME() in Q_LIKELY() docs.
Change-Id: I4a46e281d0fbf55c11001f15667fcc4faa3b0c5b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
QT_POST_CXX17_API_IN_EXPORT_CLASS (introduced in commit e996253774)
works around a deficiency of MSVC by marking affected methods as
templated. Anyhow, this doesn't need to be reflected in the
documented API.
Pick-to: 6.4
Change-Id: I9d5dd8b979a84f2fecc582613c2e944bb33eb790
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Hide the 'template magic' to implement Q_WEAK_OVERLOAD from the
documentation. So far Q_WEAK_OVERLOAD void foo() lead to
template <typename> void foo()
in the generated documentation, which is arguably confusing to the
uninitiated. And people interested in implementation details & exact
overload resolution will arguably just read the .h files themselves.
Fixes: QTBUG-104851
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: I5e0b1b337b28e621e6a627241aa8037da0a879a7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
I'm not sure why they're here, but they only undo the work
from earlier.
Spotted in the API review
Amends 20104bb237d5231640649bcc610d4e51e03ea617.
Pick-to: 6.4
Change-Id: Ifc0fa66a304f819c1f59ef8e4e498ab14f859ef8
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use __has_cpp_attribute mechanism to check availability of
[[noreturn]]. For MSVC 2019 and 2022, this is always
the case, so we can also remove the (now dead)
__declpsec(noreturn) definition.
Pick-to: 6.4
Change-Id: Ie7b39bd93bc5e1a173e245a3a5d5ff7e9067a59f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Later on we redefine them to
[[deprecated]], [[deprecated("")]], if the attribute
is available.
Since both MSVC 2019 and 2022 support the attribute,
the __declspec() definition was never used.
https://docs.microsoft.com/en-us/cpp/cpp/attributes
Pick-to: 6.4
Fixes: QTBUG-93748
Change-Id: I3e12f2ace414e316a811f2ceb44e6f312803439a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Like Q_ASSERT(), which was fixed for 5.10, it's also useful if
Q_ASSUME() expands to an expression instead of a statement. This way,
it's usable in more contexts, esp. the comma operator.
[ChangeLog][QtCore][QtGlobal] Q_ASSUME() now expands to an expression
(was: statement).
Change-Id: I33dc3d1551a1b7454aa9587b9c33dfa2e3d2b09c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
