Warns the include is non-standard, so replace it with standard
includes.
Pick-to: 6.3
Change-Id: I8db4b65a3f706cb31215332277a3378df88a0003
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The API couldn't be simpler (function without arguments), and we want to
use the function on our "Getting Started with CMake" documentation page.
Pick-to: 6.3
Task-number: QTBUG-100793
Change-Id: I83ba66c2970ac7441b425add4df1da2695e50ddb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This de-inlines destuctors of classes whose vtables are proven to be
duplicated even within the set of Qt libraries.
Since these are all private API classes, we can pick all the way back
to 6.2, and we don't need the comment that the dtor must always stay
empty, like for public classes.
As a drive-by, also de-inline the QPaintDeviceWindowPrivate ctor.
That's just code hygiene, it doesn't partake in vtable duplicating.
Pick-to: 6.3 6.2
Task-number: QTBUG-45582
Change-Id: I3477063d6f42edc9a5d352c47900366fd50c3ef6
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
... which implements or assumes something about the
broken^Wnon-STL-compliant insertion behavior.
Once this has integrated into all module dependencies, we can
re-implement these APIs using STL-compatible semantics.
Task-number: QTBUG-100092
Change-Id: I54f4f5ce7addd9543866d2c399f48aff50983b88
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Even QtCore alone cannot be built without the properties feature since
Qt 5.5. While fixing this is easy, other modules like dbus,
networking are also using QObject::property() and friends liberally.
All in all I doubt that anybody will miss the feature (otherwise it
would have been fixed in the last decade).
Change-Id: Iaf3cc20bda54ee2ff3b809fac8fa82b94ecc88c0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
While 'pure' in GCC is weaker than Stepanov's Regular Procedure from
Elements of Programming (equal result for equal inputs), it does not
allow accesses to volatile memory:
> functions declared with the pure attribute can safely read any
> non-volatile objects
The globalSeed() function reads from an atomic variable that can be
changed at any time from another thread.
Atomics, while not volatile objects in the sense of the keyword, must
fall under the pure attribute doc's exclusion criterion:
The difference between a volatile and an atomic access, while
important for the implementation of the function, is indistinguishable
to the caller of the function: both volatile and atomic objects can
change value without the current thread of execution changing them,
with no way for the caller of the function to distinguish which one
occurred.
Therefore, globalSeed() should not be pure.
5.15 is not affected, as qGlobalQHashSeed() is not marked as pure.
Task-number: QTBUG-62185
Pick-to: 6.3 6.2
Change-Id: I6fc52e2bd41ef4aa3f8039072b47c7a1314b98fa
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
GCC 12 -std=c++20 says:
qstringview.h:155:39: error: ‘std::is_constant_evaluated’ always evaluates to false in a non-‘constexpr’ function [-Werror=tautological-compare]
With this, it's possible to declare:
constexpr QStringView sv = u"Hello, World!";
QStringView f() { return sv; }
And GCC will generate:
movl $13, %eax
leaq .LC0(%rip), %rdx
ret
Writing simply
QStringView f() { return u"Hello, World!"; }
Causes GCC to emit a comparison loop (the std::char_traits::length
function), but at least there's no function call in either C++17 or
20. Clang 13 is able to reduce the loop to a constant and produces the
same code as the constexpr variable in either mode.
Pick-to: 5.15 6.2 6.3
Change-Id: I74249c52dc02478ba93cfffd16d282fa35a5b883
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Don't add 1 ms when it's rounded to 1 ms.
Found when running unit tests on QNX, where the clock did not update
between two subsequent calls to clock_gettime().
All of this ought to be refactored to use std::chrono::nanoseconds.
Fixes: QTBUG-100438
Pick-to: 6.2 6.3
Change-Id: I47dc6426c33d3a66dec946ae3589694745ed1835
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
cf043a785a unified QtConcurrent::run() and
QtConcurrent::runWithPromise(). Remove the last mentions of
runWithPromise. Also did some minor cosmetic improvements.
Pick-to: 6.3
Change-Id: Ie3b39600978ccfa4a009d3ff68567a348dc7b166
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Setting a value for the QT_RESOURCE_ALIAS source file property on a
path ending with a slash (a directory) is not handled properly by
CMake. This leads to unpredictable values being set for multiple
directories. Fix this by stripping the the final slash from the file
path, which makes CMake think it's a file rather than a directory.
Change-Id: I7a39be68e6f58bf2726c80108da9947057e7add6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On several platforms std::bit_ceil() returns 1 for input values that
would overflow the output. Our test expects 0 though. Since the value
is documented as undefined, avoid it.
Pick-to: 6.3 6.2
Change-Id: I00556893a8f0e1e24f08f73cd112b56148bc5bd0
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
We are storing a copy of the this pointer in the constructor,
and later deference it to access EventCallback object
memebers. This makes the class noncopyable: delete
the copy constructor to make sure it isn’t.
Also change the callback API to propagate the event
to the event callback.
Change-Id: Ida4bb192b3e905b260ebeec30293aad71b7d8c49
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Allocate a PATH_MAX-sized buffer on stack only in case we are not using
realpath(X, null), i.e. on platforms with older POSIX versions, macOS,
or Android.
This fixes the build on platforms that do not have PATH_MAX (e.g.
GNU/Hurd), and it provides a minor optimization on realpath(X, null)
platforms.
Change-Id: Icd92a1b15ec18c5eef8113408e9610dfac774101
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Introduced in commit d07742f333. Reported
by GCC 12:
qlibrary.cpp:672:9: error: dangling pointer to ‘candidates’ may be used [-Werror=dangling-pointer=]
672 | if (isValidSuffix(*it++))
| ^~
qlibrary.cpp:634:29: note: ‘candidates’ declared here
634 | const QLatin1String candidates[] = {
| ^~~~~~~~~~
This is a false positive report because the lambda does not return a
pointer or iterator. But it's a good update anyway to keep the array
outside the lambda, so it won't be recreated every time.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
Pick-to: 6.3
Change-Id: I74249c52dc02478ba93cfffd16d230abd1bf6166
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Don't allow the compiler to inline them in qHashBits() because they
require a lot of register use and add to the hot code path to aeshash().
Now all calls in this function are tail calls.
Change-Id: I54f205f6b7314351b078fffd16cf7f2f97d99144
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
...that may lack GetCurrentProcessToken. The definition in the new SDKs
is:
FORCEINLINE HANDLE GetCurrentProcessToken (VOID)
{
return (HANDLE)(LONG_PTR) (-4);
}
This is a partial revert of ae7e11e5c6.
Pick-to: 6.3
Change-Id: I74249c52dc02478ba93cfffd16d23c487229f95d
Reviewed-by: Yuhang Zhao <2546789017@qq.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
It's relied on implicitly, which is no longer valid in dev.
And may accidentally be broken in other branches.
Pick-to: 6.3 6.2
Change-Id: I2272b6914e883e20d0989a1762eb1a5c1aef4e0e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Before this patch, Clang versions greater than 11.0.0 emitted
-Wsuggest-override warnings whenever the Q_OBJECT macro was used.
Excerpt from compiling GammaRay against Qt 6, using Clang 13.0.0:
```
.../qtbase/src/corelib/io/qfile.h:96:5: warning: 'qt_metacall' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
Q_OBJECT
^
.../qt5/qtbase/src/corelib/kernel/qtmetamacros.h:166:17: note: expanded from macro 'Q_OBJECT'
virtual int qt_metacall(QMetaObject::Call, int, void **); \
^
.../qt5/qtbase/src/corelib/io/qfiledevice.h:54:5: note: overridden virtual function is here
Q_OBJECT
^
.../qt5/qtbase/src/corelib/kernel/qtmetamacros.h:166:17: note: expanded from macro 'Q_OBJECT'
virtual int qt_metacall(QMetaObject::Call, int, void **); \
^
```
This was also discussed on the QtCreator mailing list:
https://www.mail-archive.com/qt-creator@qt-project.org/msg08500.html
Pick-to: 6.2 6.3
Change-Id: I149782472ce8a2e30ed8062ada460c39926f1613
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Q_ASSERT goes away in release builds, Q_UNREACHABLE() does not.
This also solves the GCC 12 warning about out-of-bounds access in
QAbstractEventDispatcherPrivate::allocateTimerId():
In member function ‘_PTp* std::__atomic_base<_PTp*>::load(std::memory_order) const [with _PTp = QFreeListElement<void>]’,
inlined from ‘_Tp* std::atomic<_Tp*>::load(std::memory_order) const [with _Tp = QFreeListElement<void>]’ at atomic:579:25,
inlined from ‘static T QAtomicOps<X>::loadAcquire(const std::atomic<T>&) [with T = QFreeListElement<void>*; X = QFreeListElement<void>*]’ at thread/qatomic_cxx11.h:249:29,
inlined from ‘X* QBasicAtomicPointer<X>::loadAcquire() const [with X = QFreeListElement<void>]’ at thread/qbasicatomic.h:233:64,
inlined from ‘int QFreeList<T, ConstantsType>::next() [with T = void; ConstantsType = QtTimerIdFreeListConstants]’ at qfreelist_p.h:245:34,
inlined from ‘static int QAbstractEventDispatcherPrivate::allocateTimerId()’ at kernel/qabstracteventdispatcher.cpp:99:24:
bits/atomic_base.h:820:31: warning: ‘long unsigned int __atomic_load_8(const volatile void*, int)’ writing 8 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
820 | return __atomic_load_n(&_M_p, int(__m));
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
In file included from qglobalstatic.h:1,
from qglobal.h:1395:
qglobalstatic.h: In static member function ‘static int QAbstractEventDispatcherPrivate::allocateTimerId()’:
qglobalstatic.h:127:23: note: at offset -8 into destination object ‘holder’ of size 56
127 | static Holder holder;
| ^~~~~~
Pick-to: 5.15 6.2 6.3
Change-Id: I74249c52dc02478ba93cfffd16d232b275d5d216
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
[ChangeLog][Potentially Source-Incompatible Changes] The qtextstream
header no longer includes <QString>, <QStringEncoder> and
<QStringDecoder>. Code which relied on the implicit inclusion of those
classes might now need to include the headers explicitly.
Task-number: QTBUG-97601
Change-Id: Ifb8c8452026195a772c0588dbbbc53fb51cac548
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use custom script to copy big Android artifacts on Windows platforms.
The script uses 'copy' but not 'copy_if_different' when source file
size is bigger than 2GB. 'cmake -E copy_if_different' only compares
first 2GB of files because of cmake issue, so this step only
workaround the problem.
Pick-to: 6.2 6.3
Task-number: QTBUG-99491
Change-Id: Id076734700e334dfc3330da412462c2b53829b33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Removes a static string literal. QtMiscUtils allows the compiler to
possibly avoid the array, or share with other TUs
Pick-to: 6.3
Change-Id: I449800f113620a53d2f4b11fe027ebcb710f7b86
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's used as a thread_local static, so it better be.
What prevented it was the unused inheritance from QObject and the
missing constexpr ctor of the StatIdent() data member.
Fixed both.
Pick-to: 6.3
Change-Id: I312ed6dc8bf7193cdaa7dc708bf19b018e56ec8a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The typical argument, source_location::current(), is consteval, so it
cannot actually be used outside constexpr contexts. Having a
non-consteval, non-constexpr ctor to accept the return value is
conceptually wrong, as a constexpr-only result is forced though a
non-constexpr function. It may even trigger MSVC's consteval bug:
https://developercommunity.visualstudio.com/t/Cannot-use-std::source_location-in-C-m/1436152
because the work-around given, wrapping in a lambda, means wrapping
the result in a constexpr context, and that may just be the root cause
of the issue.
Pick-to: 6.3 6.2
Change-Id: I49534cf86f32e16b13d7e169cd5cb0c8fc374d69
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This string table is small, so instead of using qOffsetStringArray(),
just don't make it static. The compiler will do it's thing, then,
without introducing relocations.
Proof:
$ ~/bin/relinfo.pl libQt6Core.so.6.4.0
libQt6Core.so.6.4.0: 6303 relocations, 5346 relative (84%), 318 PLT entries, 1 for local syms (0%), 0 users
vs.
$ ~/bin/relinfo.pl libQt6Core.so.6.4.0
libQt6Core.so.6.4.0: 6300 relocations, 5343 relative (84%), 318 PLT entries, 1 for local syms (0%), 0 users
Task-number: QTBUG-100536
Pick-to: 6.3 6.2
Change-Id: I7f5c3c127867c9baebfb270ef3e257dd818f821a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Unless "." (or the empty string) is in $PATH, we're not supposed to find
executables in the current directory. This is how the Unix shells behave
and we match their behavior. It's also the behavior Qt had prior to 5.9
(commit 28666d167a). On Windows, searching
the current directory is the norm, so we keep that behavior.
This commit does not add an explicit check for an empty return from
QStandardPaths::findExecutable(). Instead, we allow that empty string to
go all the way to execve(2), which will fail with ENOENT. We could catch
it early, before fork(2), but why add code for the error case?
See https://kde.org/info/security/advisory-20220131-1.txt
[ChangeLog][Important Behavior Changes] When passed a simple program
name with no slashes, QProcess on Unix systems will now only search the
current directory if "." is one of the entries in the PATH environment
variable. This bug fix restores the behavior QProcess had before Qt 5.9.
If launching an executable in the directory set by setWorkingDirectory()
or inherited from the parent is intended, pass a program name starting
with "./". For more information and best practices about finding an
executable, see QProcess' documentation.
Pick-to: 5.15 6.2 6.3
Change-Id: I54f205f6b7314351b078fffd16cf7013c97ee9fb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In C++20, any given relational operator is also considered in its
reversed form, so e.g.
given op==(X, Y)
and X x, Y y, then y == x will compile, by using the reversed op(X, Y)
This, unfortunately, makes some existing asymmetric operator overload
sets ambiguous, and instead of applying tie-breaker rules, at least
Clang is warning about these.
For us, this means we need to make our overload set non-ambiguous. The
QJsonValue{,Ref} classes failed this, because they only provide the
following member-operators:
- QJsonValue::op==(const QJsonValue&) const
- QJsonValueRef::op==(const QJsonValue &) const
For member functions, there are no implicit conversions on the LHS. So
in C++17, we have a nice dichotomous overload set:
- LHS is QJsonValue -> use QJsonValue::op==(QJsonValue)
- LHS is QJsonValueRef -> use QJsonValueRef::op==(QJsonValue)
In both of these, it the RHS is a QJsonValueRef, it's implicitly
converted to QJsonValue for the call.
Enter C++20, and the reversed signatures are suddenly available, too,
which is a problem for QJsonValueRef <> QJsonValueRef, which could be
resolved, as in C++17, using
lhs.QJVR::op==(QJV(rhs))
or it could now be
rhs.QJVR::op==(QJV(lhs)); // reversed
Says Clang 10:
tst_qtjson.cpp:990:5: warning: ISO C++20 considers use of overloaded operator '==' (with operand types 'QJsonValueRef' and 'QJsonValueRef') to be ambiguous despite there being a unique best viable function [-Wambiguous-reversed-operator]
CHECK(r0, a0, r1);
^ ~~ ~~
qjsonvalue.h:189:17: note: ambiguity is between a regular call to this operator and a call with the argument order reversed
inline bool operator==(const QJsonValue &other) const { return toValue() == other; }
^
A similar argument makes op!= ambiguous.
Says Clang 10:
tst_qtjson.cpp:988:5: error: use of overloaded operator '!=' is ambiguous (with operand types 'QJsonValueRef' and 'QJsonValueRef')
CHECK(r0, r0, r1);
^ ~~ ~~
qjsonvalue.h:190:17: note: candidate function
inline bool operator!=(const QJsonValue &other) const { return toValue() != other; }
^
qjsonvalue.h:189:17: note: candidate function
inline bool operator==(const QJsonValue &other) const { return toValue() == other; }
^
qjsonvalue.h:189:17: note: candidate function (with reversed parameter order)
To fix, provide the missing operators as free inline functions (so Qt
6.2 and 5.15 don't get new symbols added) so there's always exactly
one best match.
This is a fix for 6.2 and 5.15. At the time of writing, 6.3 isn't
released, yet, so there, we could QT_REMOVED_SINCE the pre-existing
member operators in favor of hidden friends (as per QTBUG-87973).
Use C++17'isms to prevent an automatic merge to 5.15, which requires
contains(QT_CONFIG,c++2a):CONFIG += c++2a
added to tst_qtjson.pro.
[ChangeLog][QtCore][QJsonValue] Fixed relational operators to not
cause warnings/ambiguities when compiling in C++20.
Pick-to: 6.3 6.2 5.15
Change-Id: Ic70f3cad9987c87f7346d426c29cc2079d85ad13
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2dea20e4b0 de-inlined the dtor to avoid
duplicating its vtable in multiple translation units, but the class is
used externally, so we need to export it now.
Pick-to: 6.3
Fixes: QTBUG-100569
Change-Id: I7cf2abdfdeb59bced0631838fe329ba94ab8c73a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Those classes are not used by any bootstrapped tool.
Also remove the QT_BOOTSTRAPPED code paths.
Change-Id: Ic5a9b153a578fedcba37cd81a62ccf0182a2d34f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Because at least one compiler *cough*MSVC*cough* is unable to dllexport
a method that is in a dllexport'ed class.
Change-Id: I54f205f6b7314351b078fffd16d06b4e6ef0c086
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Before the #ifdef __cplusplus and namespace start. We don't need to
export anything from C (and I hope that remains the case), but at least
this removes the need for QT_{BEGIN,END}_INCLUDE_NAMESPACE. Which also
weren't needed.
Pick-to: 6.2 6.3
Change-Id: I54f205f6b7314351b078fffd16d0bc84c57cb2ec
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
This class is used by androidtestrunner, which is not bootstrapped.
Change-Id: Ie75b4dd039f773a8ccb58f243bf9f74a5121c3f3
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the CSR_ALLOW_UNRESTRICTED_FS bit of System Integrity Protection (SIP)
is enabled lldb will fail to print a valid stack trace when launched from
the crashed process, and might also resulting in hanging or crashing the
parent process (Terminal e.g.):
https://github.com/llvm/llvm-project/issues/53254
We detect this situation and avoid printing a stack trace if so.
Pick-to: 6.3 6.2
Change-Id: Iad8cab5fcdc545d810ca4d4e985aefc0988d0234
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Some properties and commands were mistakenly assigned to Qt 6.3.
Pick-to: 6.3
Task-number: QTBUG-100212
Change-Id: I504021863ce628628af469f0ac12881c2eb07dbb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Having just spent another afternoon wrapping my head around why this
code is correct, I chose to save the next person (quite possibly me)
faced with it the slowest half of the effort that went into doing so.
This amends commit d3ff95dcb8
Change-Id: If0fcd2fb1fff5e99b1046d07039169e928fda9e4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
My understanding is that the two bullet list items should be
treated as one item.
Pick-to: 6.3
Change-Id: Ibdd2bbc8677e925e71e6de7b3f076a1fab3914bf
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Those platform specific classes are not covered by our
binary/source compatibility guarantee between minor releases.
Pick-to: 6.3
Change-Id: I2a69c7ea07feea62fdf9899839e47fc540f89c12
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Qt 6 automatically registers all types used in properties. Thus, the
functionality is mostly obsolete since Qt 6. We can simply return the
stored metatype's id instead.
The code in moc is kept in place for compatibility with older code,
though there seem to be no remaining users of the metacall in Qt itself
anymore.
Change-Id: I3c654150988ae7780b4e9ea1f16191fdadf8d791
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Qt 6's metatype does no longer care whether the type is from Core, GUI
or a user metatype.
Change-Id: I4f41d44a61a9839f58b957219c2404512630587a
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Allan Sandfeld Jensen
Joerg Bornemann
Marc Mutz
Kai Köhne
Thiago Macieira
Sona Kurazyan
Alexey Edelev
Ievgenii Meshcheriakov
Morten Johan Sørvig
Pino Toscano
Alexandru Croitor
Mårten Nordheim
Fabian Kosmale
Kevin Funk
Tor Arne Vestbø
Edward Welbourne
Andreas Eliasson