Add some details about the support of Qt apis (QFile, QDir, QFileInfo)
for Android content uris.
Fixes: QTBUG-99664
Task-number: QTBUG-98974
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I4b884623702ccad116d47049e34ccddfe21f83ca
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
The group page for Qt core classes related to I/O include classes from
other modules. Remove these classes from the group; it may confuse
the reader.
Fixes: QTBUG-110020
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: If7df85523ce6b3aa09605bd89d9899ce308d2671
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
And deprecate the non-native key support API. Qt 7 may not even store
the old, non-native Qt.
Documentation in a new commit, when the dust settles.
Change-Id: I12a088d1ae424825abd3fffd171d2b549eeed040
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Common to both QSharedMemory and QSystemSemaphore, this will hold the
native key and will replace the concept of non-native key in those
classes.
Change-Id: Id8d5e3999fe94b03acc1fffd171c03197aea6016
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
It is a valid URL reference, which is not what people may want.
Fixes: QTBUG-109855
Pick-to: 6.4 6.5
Change-Id: I69ecc04064514f939896fffd173783ce2228c1d2
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
As discussed in the latest CMake API Review, we are deprecating the
FILENAME_VARIABLE variable name everywhere, and replacing it with
OUTPUT_SCRIPT.
[ChangeLog][CMake] The FILENAME_VARIABLE option of
qt_generate_deploy_script and qt_generate_deploy_app_script is now
deprecated, use OUTPUT_SCRIPT option instead.
Change-Id: Ic8be33eefbc48540166ea0fcf1d1948b052d4b8a
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Drop the use of \qtcmakepackage for the module page that results in
incorrect instructions, and replace it with a snippet with the correct
commands to use.
Pick-to: 6.5 6.4 6.2
Fixes: QTBUG-109214
Change-Id: I936910ddb9e4118f931d85e4b096ad52006dcc32
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
This makes it possible to process QML files using qmlcachegen, and
retain the file nodes in the resource file system, but remove their
actual content from the binary. To do so, you need to mark your files
with the QT_DISCARD_FILE_CONTENTS source file property.
Fixes: QTBUG-87676
Fixes: QTBUG-103481
Fixes: QTBUG-102024
Fixes: QTBUG-102785
Change-Id: I93d5a2bfca1739ff1e0f74c8082eb8aa451b9815
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Deprecate usage of:
- qt_android_add_apk_target
- qt_android_apply_arch_suffix
- qt_android_generate_deployment_settings
when used by user projects directly. Instead, projects should use
qt_add_executable / qt_add_library.
Show a deprecation warning when the commands are used directly.
The deprecation warnings can be silenced using cmake's
-Wno-deprecated command line option.
To detect non-direct usage from inside our own function
implementations, we set some target properties which are then read to
decide whether to show the message.
Pick-to: 6.5
Fixes: QTBUG-108508
Change-Id: Ib039cc5f3a01c2276173abb1e43f4eed216d0170
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This mimics CMake's policy support. The policy state is stored in an
internal __QT_INTERNAL_POLICY_<policy> variable; by using normal
variables, we gain support for stacking for free.
Policies can be explicitly en- or disable via qt6_policy; that command
also has a GET mode to retrieve them again.
Furthermore, one can now pass min and max version to
qt6_standard_project_setup, to opt in to a certain set of defaults
introduced in a given Qt version.
We add support for policies in QtModuleHelpers, so that we can check for
known policies while building Qt itself.
No actual policies exist yet; but a follow up commit will introduce one
for qt_add_qml_module.
Change-Id: I57a0404c9193926dd499f94cc5f73e359355c0b3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Free most APIs using QTimeZone from feature timezone and route all
APIs taking a naked QTimeSpec via these, in preparation for their
eventual deprecation. Since qtimezone.h includes qdatetime.h (and MSVC
blocks our ability to remove the need for that), qdatetime.h's
declarations can't use a default value for QTimeZone parameters; so
add overloads taking no zone (or spec) to handle that.
[ChangeLog][QtCore][QDateTime] All QDateTime APIs involving a
Qt::TimeSpec can now be routed via QTimeZone's lightweight time
description support, saving the need to have different code paths for
different time specs. In the process, QDateTime gains a
timeRepresentation() method to return a QTimeZone reporting the
(possibly lightweight) time description it uses. (The older timeZone()
method always returns a non-lightweight QTimeZone, whose timeSpec() is
Qt::TimeZone.)
Task-number: QTBUG-108199
Change-Id: I23e43401eb2dbe9b7b534ca6401389920dd96b3c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
They are deemed good enough.
qt_deploy_translations is left in TP because with the current
signature, it's not clear yet how it's supposed to work for iOS
and other non-desktop targets.
[ChangeLog][CMake] The Core CMake deployment API
is out of Technical Preview status.
Task-number: QTBUG-108507
Change-Id: I384233c697b33644de3c9e1fb17d04f44ca16ea2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It is deemed good enough.
[ChangeLog][CMake] The Core CMake QT_RESOURCE_ALIAS
property is out of Technical Preview status.
Change-Id: I50128a8ea4e82b3d15ff272eb713bc0f6a8b167d
Fixes: QTBUG-109077
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Added some background about Serialization with the classes and used cases.
Fixes: QTBUG-103951
Pick-to: 6.4 6.3 6.2
Change-Id: I3ff179b814fc5d424f2ac2ffaf3237b90ddd7e2b
Reviewed-by: Vladimir Minenko <vladimir.minenko@qt.io>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Add functions which converts to and from JavaScript
data arrays:
static QByteArray::fromUint8Array(emscripten::val array)
emscripten::val QByteArray::toUint8Array() const
with corresponding internal qstdweb API:
static Uint8Array Uint8Array::copyFrom(const QByteArray &buffer)
QByteArray Uint8Array::copyToQByteArray() const
Both functions will make a copy of the data, i.e. there
is no shared reference counting. They take and return
Uint8Array typed array views, via emscripten::val JavaScript
object references.
Unlike other native conversion functions, these have
the special property that the data referenced by the
native Uint8Array exists outside the heap memory area.
This means we can’t e.g. memcpy the data. However, the
heap is itself a JavaScript ArrayBuffer, and we can
create a Uint8Array view to the buffer owned by the
QByteArray, and then use JavaScript API to copy. See
the qstdweb::Uint8Array::copy() implementation.
That also means that a fromRawUint8Array() variant
(which does not copy) is not possible to implement,
since we can’t create a pointer to the source data.
The inverse toRawUint8Array() is implementable - it
would return a Uint8Array view which references the
heap’s ArrayBuffer. However, this may turn out to be
ill-advised, since Emscripten will create a new ArrayBuffer
if/when it resizes the heap. In any case this left for
a future expansion.
Change-Id: Icaf48fd17ea8686bf04cb523cc1eb581ce63ed34
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
When updating Qt for Android platform documentation, it was discovered
that the CMake variable for setting a specific Android SDK Build Tools
Revision was undocumented.
Pick-to: 6.2 6.4
Change-Id: I5f1b4e9d10b9ce817f5529cf4897bd0423a84455
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Add brief descriptions of the pages that are shown in
https://doc.qt.io/qt-6/overviews.html
Pick-to: 6.4
Change-Id: I177e4ba82cd7b8e264122375bf9a595509918fdd
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Make the code snippets consistent, update the comparison table
and fix some sentences.
Pick-to: 6.4 6.2
Change-Id: Ic8baaa56805392855736164efa03d065330309fa
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Implements an adaptor from the notification signal of a Q_PROPERTY to
QBindable. The Q_PROPERTY does not need to be BINDABLE, but can still
be bound or used in a binding.
[ChangeLog][Core][Q_PROPERTY] Q_PROPERTYs without BINDABLE can be wrapped in QBindable to make them usable in bindings
Change-Id: Id0ca5444b93a371ba8720a38f3607925d393d98a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Make the browser compositor draw the window non-client area (using css
+ html). Get rid of OpenGL usage in non-OpenGL windows and use canvas
2d context instead to blit the texture (QImage).
Also, as part of the change, remove the deprecated canvas element support
in QScreen.
Fixes: QTBUG-107116
Fixes: QTBUG-107219
Change-Id: I65f0d91831c806315685ca681ac0e416673f5cd5
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
Remove the outdated code used for QStringList and point
QStringList and QList to the containers page.
Pick-to: 6.4 6.2
Task-number: QTBUG-108687
Change-Id: I6fae6410ca759f91da85832ddb9f24e8a0ce202b
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Introduce a section on iteration and add range-based for and index.
Pick-to: 6.4 6.2
Task-number: QTBUG-108687
Change-Id: Icb1ff55049361769f7c0b042d42f70148dd07c2e
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Use auto and initializer lists. Avoid repeated instantiations
of end().
Pick-to: 6.4 6.2
Task-number: QTBUG-108687
Change-Id: I8482638cda63e21feaa7ca21370e7947dfb4b606
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
qdoc does enforce lowercase file names for .html pages, and also
replaces underscore with a dash. Make sure that the original \page name
already is normalized, so that it's easier to search.
This was done by
find . -name "*.qdoc" -exec perl -p -i -E "s/\\\page (.*)/\\\page \L\1/ && s/_/-/g" {} ;
Pick-to: 6.4
Change-Id: Ib50b85af8ffd985edf06856266eefdebf8b328a3
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Many features of today's devices and operating systems can have
significant privacy, security, and performance implications if
misused. It's therefore increasingly common for platforms to
require explicit consent from the user before accessing these
features.
The Qt permission APIs allow the application to check or request
permission for such features in a cross platform manner.
The check is always synchronous, and can be used in both
library and application code, from any thread.
The request is asynchronous, and should be initiated from
application code on the main thread. The result of the request
can be delivered to lambdas, standalone functions, or
regular member functions such as slots, with an optional
context parameter to manage the lifetime of the request.
Individual permissions are distinct types, not enum values,
and can be added and extended at a later point.
Task-number: QTBUG-90498
Done-with: Timur Pocheptsov <timur.pocheptsov@qt.io>
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-with: Mårten Nordheim <marten.nordheim@qt.io>
Change-Id: I821380bbe56bbc0178cb43e6cabbc99fdbd1235e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
qhashfunctions.h defines a catch-all 2-arguments qHash(T, seed)
in order to support datatypes that implement a 1-argument overload
of qHash (i.e. qHash(Type)). The catch-all calls the 1-argument
overload and XORs the result with the seed.
The catch-all is constrained on the existence of such a 1-argument
overload. This is done in order to make the catch-all SFINAE-friendly;
otherwise merely instantiating the catch-all would trigger a hard error.
Such an error would make it impossible to build a type trait that
detects if one can call qHash(T, size_t) for a given type T.
The constraint itself is called HasQHashSingleArgOverload and lives in a
private namespace.
It has been observed that HasQHashSingleArgOverload misbehaves for
some datatypes. For instance, HasQHashSingleArgOverload<int> is actually
false, despite qHash(123) being perfectly callable. (The second argument
of qHash(int, size_t) is defaulted, so the call *is* possible.)
--
Why is HasQHashSingleArgOverload<int> false?
This has to do with how HasQHashSingleArgOverload<T> is implemented: as
a detection trait that checks if qHash(declval<T>()) is callable.
The detection itself is not a problem. Consider this code:
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
class MyClass {};
size_t qHash(MyClass);
static_assert(HasQHashSingleArgOverload<MyClass>); // OK
Here, the static_assert passes, even if qHash(MyClass) (and MyClass
itself) were not defined at all when HasQHashSingleArgOverload was
defined.
This is nothing but 2-phase lookup at work ([temp.dep.res]): the
detection inside HasQHashSingleArgOverload takes into account the qHash
overloads available when HasQHashSingleArgOverload was declared, as well
as any other overload declared before the "point of instantiation". This
means that qHash(MyClass) will be visible and detected.
Let's try something slightly different:
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
size_t qHash(int);
static_assert(HasQHashSingleArgOverload<int>); // ERROR
This one *does not work*. How is it possible? The answer is that 2-phase
name lookup combines the names found at definition time with the names
_found at instantiation time using argument-dependent lookup only_.
`int` is a fundamental type and does not participate in ADL. In the
example, HasQHashSingleArgOverload has actually no qHash overloads to
even consider, and therefore its detection fails.
You can restore detection by moving the declaration of the qHash(int)
overload *before* the definition of HasQHashSingleArgOverload, so it's
captured at definition time:
size_t qHash(int);
template <typename T>
constexpr bool HasQHashSingleArgOverload = /* magic */;
static_assert(HasQHashSingleArgOverload<int>); // OK!
This is why HasQHashSingleArgOverload<int> is currently returning
`false`: because HasQHashSingleArgOverload is defined *before* all the
qHash(fundamental_type) overloads in qhashfunctions.h.
--
Now consider this variation of the above, where we keep the qHash(int)
overload after the detector (so, it's not found), but also prepend an
Evil class implicitly convertible from int:
struct Evil { Evil(int); };
size_t qHash(Evil);
template <typename T> constexpr bool HasQHashSingleArgOverload = /* magic */;
size_t qHash(int);
static_assert(HasQHashSingleArgOverload<int>); // OK
Now the static_assert passes. HasQHashSingleArgOverload is still not
considering qHash(int) (it's declared after), but it's considering
qHash(Evil). Can you call *that* one with an int? Yes, after a
conversion to Evil.
This is extremely fragile and likely an ODR violation (if not ODR, then
likely falls into [temp.dep.candidate/1]).
--
Does this "really matter" for a type like `int`? The answer is no. If
HasQHashSingleArgOverload<int> is true, then a call like
qHash(42, 123uz);
will have two overloads in its overloads set:
1) qHash(int, size_t)
2) qHash(T, size_t), i.e. the catch-all template. To be pedantic,
qHash<int>(const int &, size_t), that is, the instantiation of the
catch-all after template type deduction for T (= int)
([over.match.funcs.general/8]).
Although it may look like this is ambiguous as both calls have perfect
matches for the arguments, 1) is actually a better match than 2) because
it is not a template specialization ([over.match.best/2.4]).
In other words: qHash(int, size_t) is *always* called when the argument
is `int`, no matter the value of HasQHashSingleArgOverload<int>. The
catch-all template may be added or not to the overload set, but it's
a worse match anyways.
--
Now, let's consider this code:
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
This code compiles, although we do not define any qHash overload
specifically for enumeration types (nor one is defined by MyEnum's
author).
Which qHash overload gets called? Again there are two possible
overloads available:
1) qHash(int, size_t). E1 can be converted to `int` ([conv.prom/3]),
and this overload selected.
2) qHash(T, size_t), which after instantiation, is qHash<MyEnum>(const
MyEnum &, size_t).
In this case, 2) is a better match than 1), because it does not require
any conversion for the arguments.
Is 2) a viable overload? Unfortunately the answer here is "it depends",
because it's subject to what we've learned before: since the catch-all
is constrained by the HasQHashSingleArgOverload trait, names introduced
before the trait may exclude or include the overload.
This code:
#include <qhashfunctions.h>
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
static_assert(HasQHashSingleArgOverload<MyEnum>); // ERROR
will fail the static_assert. This means that only qHash(int, size_t) is
in the overload set.
However, this code:
struct Evil { Evil(int); };
size_t qHash(Evil);
#include <qhashfunctions.h>
enum MyEnum { E1, E2, E3 };
qHash(E1, 42uz);
static_assert(HasQHashSingleArgOverload<MyEnum>); // OK
will pass the static_assert. qHash(Evil) can be called with an object of
type MyEnum after an user-defined conversion sequence
([over.best.ics.general], [over.ics.user]: a standard conversion
sequence, made of a lvalue-to-rvalue conversion + a integral promotion,
followed by a conversion by constructor [class.conv.ctor]).
Therefore, HasQHashSingleArgOverload<MyEnum> is true here; the catch-all
template is added to the overload set; and it's a best match for the
qHash(E1, 42uz) call.
--
Is this a problem? **Yes**, and a huge one: the catch-all template does
not yield the same value as the qHash(int, size_t) overload. This means
that calculating hash values (e.g. QHash, QSet) will have different
results depending on include ordering!
A translation unit TU1 may have
#include <QSet>
#include <Evil>
QSet<MyEnum> calculateSet { /* ... */ }
And another translation unit TU2 may have
#include <Evil>
#include <QSet> // different order
void use() {
QSet<MyEnum> set = calculateSet();
}
And now the two TUs cannot exchange QHash/QSet objects as they would
hash the contents differently.
--
`Evil` actually exists in Qt. The bug report specifies QKeySequence,
which has an implicit constructor from int, but one can concoct infinite
other examples.
--
Congratulations if you've read so far.
=========================
=== PROPOSED SOLUTION ===
=========================
1) Move the HasQHashSingleArgOverload detection after declaring the
overloads for all the fundamental types (which we already do anyways).
This means that HasQHashSingleArgOverload<fundamental_type> will now
be true. It also means that the catch-all becomes available for all
fundamental types, but as discussed before, for all of them we have
better matches anyways.
2) For unscoped enumeration types, this means however an ABI break: the
catch-all template becomes always the best match. Code compiled before
this change would call qHash(int, size_t), and code compiled after this
change would call the catch-all qHash<Enum>(Enum, size_t); as discussed
before, the two don't yield the same results, so mixing old code and new
code will break.
In order to restore the old behavior, add a qHash overload for
enumeration types that forwards the implementation to the integer
overloads (using qToUnderlying¹).
(Here I'm considering the "old", correct behavior the one that one gets
by simply including QHash/QSet, declaring an enumeration and calling
qHash on it. In other words, without having Evil around before including
QHash.)
This avoids an ABI break for most enumeration types, for which one
does not explicitly define a qHash overload. It however *introduces*
an ABI break for enumeration types for which there is a single-argument
qHash(E) overload. This is because
- before this change, the catch-all template was called, and that
in turn called qHash(E) and XOR'ed the result with the seed;
- after this change, the newly introduced qHash overload for
enumerations gets called. It's very likely that it would not give
the same result as before.
I don't have a solution for this, so we'll have to accept the ABI
break.
Note that if one defines a two-arguments overload for an enum type,
then nothing changes there (the overload is still the best match).
3) Make plans to kill the catch-all template, for Qt 7.0 at the latest.
We've asked users to provide a two-args qHash overload for a very long
time, it's time to stop working around that.
4) Make plans to switch from overloading qHash to specializing std::hash
(or equivalent). Specializations don't overload, and we'd get rid of
all these troubles with implicit conversions.
--
¹ To nitpick, qToUnderlying may select a *different* overload than
the one selected by an implicit conversion.
That's because an unscoped enumeration without a fixed underlying type
is allowed to have an underlying type U, and implicitly convert to V,
with U and V being two different types (!).
U is "an integral type that can represent all the enumerator values"
([dcl.enum/7]). V is selected in a specific list in a specific order
([conv.prom]/3). This means that in theory a compiler can take enum E {
E1, E2 }, give it `unsigned long long` as underlying type, and still
allow for a conversion to `int`.
As far as I know, no compiler we use does something as crazy as that,
but if it's a concern, it needs to be fixed.
[ChangeLog][Deprecation Notice] Support for overloads of qHash with only
one argument is going to be removed in Qt 7. Users are encouraged to
upgrade to the two-arguments overload. Please refer to the QHash
documentation for more information.
[ChangeLog][Potentially Binary-Incompatible Changes] If an enumeration
type for which a single-argument qHash overload has been declared is
being used as a key type in QHash, QMultiHash or QSet, then objects of
these types are no longer binary compatible with code compiled against
an earlier version of Qt. It is very unlikely that such qHash overloads
exist, because enumeration types work out of the box as keys Qt
unordered associative containers; users do not need to define qHash
overloads for their custom enumerations. Note that there is no binary
incompatibity if a *two* arguments qHash overload has been declared
instead.
Fixes: QTBUG-108032
Fixes: QTBUG-107033
Pick-to: 6.2 6.4
Change-Id: I2ebffb2820c553e5fdc3a341019433793a58e3ab
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The `rcc_PREFIX` will be set to `/` if it is not passed to the
function and it is not defined in `QT_RESOURCE_PREFIX`.
I also removed an unnecessary check of the `rcc_PREFIX`.
[ChangeLog][QtCore][CMake] The `PREFIX` parameter of the
`qt_add_resources` is now optional. If not passed, and
`QT_RESOURCE_PREFIX` is not defined, `/` will be used as the path
prefix.
Fixes: QTBUG-104938
Change-Id: I6524ab5dc54f035272e4c2e3154eb67591efb650
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This is a follow up from commit 1e904ab342c1aaa; changing more
documentation to pass a widget * in the ctor of a layout, rather
than creating a parent-less layout then calling setLayout().
Change-Id: I4fc59c6cfa46ccd279a153acd67335a6daf22ff9
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
Add the options PRE_INCLUDE_REGEXES, PRE_EXCLUDE_REGEXES,
POST_INCLUDE_REGEXES, POST_EXCLUDE_REGEXES, POST_INCLUDE_FILES, and
POST_EXCLUDE_FILES. These are forwarded to
qt_deploy_runtime_dependencies.
Change-Id: I003814bec7f797a0035e52b17fd0231f9ad7ff0d
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
We restricted the runtime dependencies we deployed on Linux to libraries
within the Qt installation prefix. This restriction was supposed to
prevent the deployment of all kinds of system libraries, which is most
likely not wanted.
However, the user might link against non-system libraries, and those
should be deployed. The same holds for QML backend libraries that exist
outside the Qt installation prefix in the build directory of the
project.
Now, we restrict deployment to libraries that are not in default system
library directories. This can be overridden with the new
qt_deploy_runtime_dependencies option POST_EXCLUDE_REGEXES.
We add the following options to qt_deploy_runtime_dependencies, which
are then forwarded to file(GET_RUNTIME_DEPENDENCIES):
PRE_INCLUDE_REGEXES, PRE_EXCLUDE_REGEXES, POST_INCLUDE_REGEXES,
POST_EXCLUDE_REGEXES, and POST_INCLUDE_FILES.
Change-Id: I99a98fd91218abedda270609d0bafbb7f3e0feeb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This portion of the documentation was there since the Qt 4.5 import of
the repository and may have been correct at the time. They haven't been
for some time and definitely aren't now. So be clear that even if there
are overloads, some of them are bad ideas.
Pick-to: 6.2 6.3 6.4
Change-Id: I810d70e579eb4e2c8e45fffd1719adefb6f9f3bf
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
To indicate success of a conversion, the public API has previously only
supported registering member functions of the form To (From::*)(bool *).
When adding custom converters for types that cannot be modified, this is
usually not a possibility.
As an alternative, this patch adds support for std::optional in the
UnaryFunction overload of QMetaType::registerConverter. If the returned
optional has no value, the conversion is considered failed.
Task-number: QTBUG-92902
Change-Id: Ibac52d2cb9b5a2457081b4bebb0def1f03e3c55d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add the MANUAL_FINALIZATION option to qt_add_plugin and run
qt_finalize_target like we do for qt_add_executable and qt_add_library.
Currently, the only user-visible effect is that resource files are put
into a FOLDER and not underneath a XXX_other_files target.
Change-Id: I430d87b5357f6d2ed7fe32198a73eb919f393dd8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
- Clarify how the object ownership works
- Language clean up
- Update the snippets
Pick-to: 6.4 6.3 6.2
Task-number: QTBUG-106071
Change-Id: I7caf42a150ef82dee920df4d03db6fd988796bd4
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Add the NO_TRANSLATIONS option to qt_deploy_runtime_dependencies and
qt_generate_deploy_app_script. On Windows and Linux, this option
prevents the deployment of Qt translations.
[ChangeLog][CMake] Added the NO_TRANSLATIONS option to
qt_deploy_runtime_dependencies and qt_generate_deploy_app_script.
Change-Id: I9d8435e262e2ff6c7242760ddb189473af850476
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the command qt_deploy_translations to the CMake deployment API.
This can be used to deploy a set of Qt translations.
This command is supposed to be called by the generic deployment tool in
a future commit.
[ChangeLog][CMake] Added qt_deploy_translations for deploying Qt
translation catalogs in user projects.
Change-Id: I4492a5042970cf89b2be2ed0c34521c7af904771
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, qt_deploy_runtime_dependencies supported Windows and
macOS only. We add a generic deployment method implemented in
cmake-language with file(GET_RUNTIME_DEPENDENCIES). This deployment
method is now enabled for shared builds on Linux.
The file(GRD) command requires that the EXECUTABLE argument points to
the executable in the build directory.
Only libraries in Qt's installation directory are considered for
deployment. This includes Qt's own libraries and also things like
libicu*.so we're shipping with the installer.
Unlike macdeployqt and windeployqt, the generic
qt_deploy_runtime_dependencies does not yet support deploying
translations. We will catch up on this in a later commit.
Change-Id: Iea23abcdba774d4c1885c8d2c243eb3e48fb7fae
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a subsequent commit we will add Linux support for
qt_deploy_runtime_dependencies based on file(GET_RUNTIME_DEPENDENCIES).
The file(GRD) command expects that we pass the not-yet-installed
executable to it, because the command reads the RUNPATH/RPATH from the
executable and resolves libraries against these paths. This resolution
is likely going to fail if file(GRD) is run on an installed executable,
because the RPATH was modified to be relocatable in the installation
phase.
This patch adds a recommendation to use the build directory's executable
for qt_deploy_runtime_dependencies on non-macOS platforms.
Also, the Windows code path of qt_deploy_runtime_dependencies is
adjusted to support both, the .exe in the build dir and the .exe in the
installation prefix.
For consistency, qt_generate_deploy_app_script calls
qt_deploy_runtime_dependencies with EXECUTABLE pointing to the build
directory's executable.
[ChangeLog][CMake] On non-macOS platforms,
qt_deploy_runtime_dependencies' EXECUTABLE argument now expects the
executable in the build directory instead of the installation directory.
Change-Id: Id76b52cc5a0f285586679d7ae600a8c7996429c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Should the deployment script that qt_generate_deploy_app_script not be
sufficient, the new function qt_generate_deploy_script can be used to
generate a custom deployment script. Before, one had to add quite some
boilerplate code to generate a custom deployment script.
The qt_generate_deploy_app_script function now uses
qt_generate_deploy_script internally.
The TARGET option of qt_generate_deploy_script is currently only used
for controlling the base name of the generated deployment script. We
will do more with the target in a subsequent commit.
Fixes: QTBUG-105731
Change-Id: I85bfc50dac1f0b0b1aae0f657f803e9e30f53616
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_standard_project_setup() is not in technical preview anymore.
Move this variable out of TP as well.
This commit amends 85970834b5.
Task-number: QTBUG-100793
Change-Id: I46f57972b385ac033e106bd8cbdc1efe7c9777af
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Take QT_HOST_PATH out of technical preview. It has proven worthy of
being documented as proper CMake variable.
Fixes: QTBUG-106463
Pick-to: 6.2 6.3 6.4
Change-Id: Ie1dd83eff526d5b803ea275dd3c6ecc3a7aa0e17
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously _qt_internal_collect_apk_dependencies() only collected
targets that were built by the current project and informed
androiddeployqt their directory paths for deployment consideration.
The libraries would be bundled into the apk based on whether
the application links to any of those libraries directly,
e.g. via target_link_libraries.
CMake 3.21 added a new feature that allows us to query all IMPORTED
targets in a directory scope. Using this information we can now tell
androiddeployqt about these libraries as well, of course only when a
new enough CMake version is used. Introduce
_qt_internal_collect_apk_imported_dependencies_defer to do that.
In contrast to _qt_internal_collect_apk_dependencies(), the IMPORTED
libraries are collected by recursively looking at a target's directory
scope and its parent directories, rather than child subdirectories.
Also, the collection / deferral is done when the target's directory
scope has finished processing, rather than when the root project
has finished processing.
Why? IMPORTED libraries are usually non-global, which means we can't
refer to them in parent scopes using functions like
get_target_property, the targets don't exist in those scopes.
Note that the code only covers IMPORTED target libraries. It
does not cover INTERFACE libraries, plain library names or
file paths specified in target_link_libraries.
It also doesn't account for loadable libraries (dlopen()ed ones).
In such cases, projects still need to manually specify the library
paths in the executable's QT_ANDROID_EXTRA_LIBS target property.
To prevent the deployment json file from being extra long when
looking for IMPORTED libraries, filter out paths to Qt modules or
plugins by checking for the _qt_package_version property.
These are handled via a different code path in anddroiddeployqt,
so there's no reason to duplicate the information.
Added documentation for how to opt out of this new behavior.
Amends d20f4ae706
[ChangeLog][CMake][Android] Imported targets are now considered
during Android deployment when using CMake 3.21+.
Fixes: QTBUG-94714
Fixes: QTBUG-105165
Change-Id: I9f01cdc4e63004e4768027e412899e441e72bf04
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Add documentation of usage of CBOR in convert and cbordump examples,
add a CBOR overview, and add links to them other places in the
documentation.
Task-number: QTBUG-85912
Change-Id: I518792db63647bf9ddd4507d8d4b7ef056192f82
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Two qdoc files included a .cmake file that contained qdoc markup. After
.cmake files got license headers, the license header showed up in the
flow content of the documentation.
Rename the .cmake file to .qdocinc and adjust the license header to be
in line with the rest of the documentation.
This amends commit 87bcb9ca6ec883afb86165a282557014c9f06e41.
Change-Id: Ie9b02c75b67791c60cc8e054b52a15ffa9cf3e32
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Type registration isn't necessary any more, unless you're trying to look
up a name back to ID or QMetaType object. It hasn't been since 6.0.
Drive-by update the example not to use deprecated API.
Drive-by remove the paragraph about requirements that aren't accurate
any more.
Pick-to: 6.4
Task-number: QTBUG-104858
Change-Id: Ic6547f8247454b47baa8fffd170eecb66719fa65
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
For foreach, we just mention that it is deprecated, and forever is not
actually directly related to Qt containers. Both macros are also
documented in qglobal.cpp, and the section title is not referenced
anywhere so this patch won't break any links.
Pick-to: 6.4
Change-Id: I6c3e11b205237e5b502173f2216606adf5812f55
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The Static Plugins page describes handling of qmake and CMake already
in greater detail. No need to replicate it here.
Pick-to: 6.4
Task-number: QTBUG-88044
Change-Id: I2cae85c0b0d20585b563bab9e263121181adeb8c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The exact version doesn't add much information, and will most likely
go stale again; so just remove the mentioning.
Change-Id: Ifd87f7cf655a610aa45e341cf5a3491ae7d91171
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][CMake] Added the QT_ANDROID_SIGN_AAB variable that can be
set to ON to enable signing of .aab packages.
Pick-to: 6.4
Fixes: QTBUG-105529
Change-Id: Ic06cc452851dc81b10a2721b544641cb5eeea8be
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When loading a Qt CMake project in an IDE like Visual Studio, many
Qt-internal targets are visible, right next to the user's targets. This
is inconvenient and confusing.
Use CMake's FOLDER concept, and put Qt-internal targets into a dedicated
FOLDER.
For that we introduce the new global property QT_TARGETS_FOLDER that,
analoguous to AUTOGEN_TARGETS_FOLDER, is the folder name for Qt-internal
targets. By default, it's not set, nor is folder support enabled.
Change qt_standard_project_setup() to
- enable folder support
- initialize QT_TARGETS_FOLDER if unset
- initialize AUTOGEN_TARGETS_FOLDER to the same value if unset
Set the FOLDER property of qtbase's internal targets for user projects
to the value of QT_TARGETS_FOLDER.
Task-number: QTBUG-99808
Change-Id: I880ac7731f88faa83a384dcdec98b1b88ac6cc2e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
[ChangeLog][CMake] The target-based variant of qt6_add_resource gained
the option BIG_RESOURCES. This can be used instead of
qt6_add_big_resources, which is not target-based.
Fixes: QTBUG-100268
Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Change-Id: Ied5eb0c218d11872fbf590d735a88a11b5cd1c3e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The instructions for porting away from QRegExp to QRegularExpression in
the Qt 6 porting guide were mostly copied from the similar docs for
QRegExp, which are moved to
doc/global/includes/corelib/port-from-qregexp.qdocinc. The later now
covers everything that the docs from porting guide did and doesn't have
the issues listed in QTBUG-89702.
Remove the old docs and include the docs from doc/global/includes
instead.
Task-number: QTBUG-89702
Pick-to: 6.4 6.3 6.2
Change-Id: Ifdb79d5775bc0cadd02c21299d58adb27ae13337
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Cpp.ignoretokens, Cpp.ignoredirectives, falsehoods are not
used anymore by clang based qdoc.
Most defines are not needed, either, because clang based qdoc
will get these defined by scanning the normal headers. And QDOC,
Q_CLANG_QDOC is actually set by qdoc itself.
What's left is Q_GUI_LIB, Q_WIDGETS_LIB, which is used in headers
modules to make some API conditionally available. Finally, there's
QT_KEYPAD_NAVIGATION, which seems to be a Qt 3 thing, but still
some documentation depending on it ;)
Pick-to: 6.4
Change-Id: Ib9cf0debac8d569cc21271087168a46c0f8635ca
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
BINDABLE should generally behave the same as MEMBER if "WRITE default",
except where it cannot. In particular we cannot know if any NOTIFY
signal should be sent from the synthetic WRITE accessor.
[ChangeLog][QtCore] moc will now synthesize WRITE accessors for
properties with BINDABLE if you specify "WRITE default".
Task-number: QTBUG-97249
Change-Id: I883c40ba0dda7989c840971860addaeaa75a8c83
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The commands qt6_add_executable and qt6_add_library both accept a list
of sources that get automatically added to the created target.
Extend qt6_add_plugin to also accept sources for consistency.
Fixes: QTBUG-104189
Change-Id: Iad5d8c5b31551663be155d068d55e770e1a91b27
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The behavior is similar to MEMBER: If the READ accessor is "default",
synthesize it using the bindable.
[ChangeLog][QtCore] You can now specify "READ default" in a Q_PROPERTY
if you also specify a BINDABLE. moc will synthesize a READ accessor in
that case.
Task-number: QTBUG-97249
Change-Id: I4a275adabaed12df95dac505095f847c4be65dfe
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
qt6_add_big_resources works by calling rcc to generate a resource
.cpp file, compiling it into an object file, then passing the
compiled object file to rcc again for further manipulation.
The path to the object file is passed to rcc using the
$<TARGET_OBJECTS> generator expression.
This generator expression does not work when used in
add_custom_command / file(GENERATE) when targeting iOS, because
CMake claims it does not know where the object file will be on-disk
(presumably because the location is controlled by Xcode itself and it
can vary based on the active architecture and sysroot).
The following error is shown at generation time:
Error evaluating generator expression:
$<TARGET_OBJECTS:rcc_object_foo>
The evaluation of the TARGET_OBJECTS generator expression is only
suitable for consumption by CMake (limited under Xcode with multiple
architectures). It is not suitable for writing out elsewhere.
More details about the issue can be found at
https://gitlab.kitware.com/cmake/cmake/-/issues/20516
Trying to work around the issue by manually invoking the compiler
instead of using a genex so we know the location of the object file
hits similar issues in that we don't know the active arch and sysroot
for which to compile the object file.
Until the CMake limitation is lifted or we find a different fix, warn
that qt6_add_big_resources can't be used when targeting iOS and
fall back to using qt6_add_resources instead.
Note that qmake CONFIG+=big_resources also falls back to non-big
resources mode when targeting Xcode (mac-xcode) and doesn't even show
a warning.
Another note is that using CMake + Xcode + qt6_add_big_resources does
work when targeting macOS, although it generates some warnings
warning same member name (qrc_assets.o) in output file used for input
files: qrc_assets.o qrc_assets.o
(due to use of basename, truncation, blank padding or duplicate input
files)
So there is some hope this could be fixed for iOS in the future.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-103497
Change-Id: I91152247651ecd35e8110b8874399cb1b8b394bd
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The arguments to qt_add_big_resources are not known to CMake as source
files.
They need to be added explicitly to a CMake target in order for Qt Creator
to treat them as source files and in the case of a qrc file to expand
the contents in the project view.
Fixes: QTBUG-104320
Pick-to: 6.4 6.3
Change-Id: Iea755d998e8f9814a82983272731b0c654f80644
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Snippet [22] was unused and the example using snippet [21] neglected
to show how its oldCategoryFilter got initialized, which is what [22]
does. But it turns out the example code was crashy in any case, as it
left the oldCategoryFilter uninitialized (albeit probably null) until
the call to installFilter() had returned, and installFilter() calls
the new filter, so the new filter needs to check oldCategoryFilter
before calling it. The doc also failed to explain why it's OK to not
defer to the prior filter in these calls during installFilter(), so
revise the doc and example so that the latter behaves sensibly and
readers of the former are likely to use the function safely.
This amends commit 8f0654ceb8 which
added the snippets and the use of one of them, but not the other.
Fixes: QTBUG-49704
Pick-to: 6.4 6.3 6.2 5.15
Change-Id: Iddb8d97b0bef417d8f16e7910730cfa59ea3e715
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Classes to aid Android development are currently available in the
CorePrivate module. In order to have correct information for
the requisites table (for CMake and qmake inclusion), document
the private module, mark it \preliminary, and link the classes
to it using the \inmodule command.
Fixes: QTBUG-103865
Pick-to: 6.3
Change-Id: Id913148751ab925eb4e8488aa28a54b0e0c2d78d
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Commit contains the new QT_ANDROID_SIGN_APK variable. It extends
*make_apk target by signing the package with the specified key.
For key setup these environment variables must be set:
- QT_ANDROID_KEYSTORE_PATH
- QT_ANDROID_KEYSTORE_STORE_PASS
- QT_ANDROID_KEYSTORE_ALIAS
- QT_ANDROID_KEYSTORE_KEY_PASS
Task-number: QTBUG-97107
Change-Id: If42c74298c1b385889b32517ab7f1f5b0628b487
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Such semantics have been dropped from Qt 6.
Change-Id: I12f3478833afafa34f9075faf9ed030d06cd86f9
Pick-to: 6.2 6.3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Sometimes it is not desirable to include the libraries in the APK,
e.g. system and vendor apps could prefer having one set of libraries
installed on the device. If unbundled deployment is specified,
native libraries will not be included in the APK.
With unbundled deployment, optional arguments can be passed to
set the path to load the libraries on the device.
[ChangeLog][Android][Deployment Changes] Adds option for Unbundled
deployment, where native libraries are not packaged in the APK.
Task-number: QAA-771
Change-Id: Ica51ef83a24dad58c7586bf610a58abe21fc1100
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Originally, this argument was meant for internal use only. But it
turned out useful for user projects too.
Pick-to: 6.2 6.3
Change-Id: I58af5ca8303fa9166d41a0538a60913d1fba9784
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
Added QFuture::unwrap() for unwrapping the future nested inside
QFuture<QFuture<T>>. QTBUG-86725 suggests doing the unwrapping
automatically inside .then(), but this will change the return type
of .then() that used to return QFuture<QFuture<T>> and might cause
SC breaks. Apart from that, QFuture::unwrap() might be helpful in
general, for asynchronous computations that return a nested QFuture.
[ChangeLog][QtCore][QFuture] Added QFuture::unwrap() for unwrapping the
future nested inside QFuture<QFuture<T>>.
Task-number: QTBUG-86725
Change-Id: I8886743aca261dca46f62d9dfcaead4a141d3dc4
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
std::chrono::year_month_day and related classes offer very
convenient to specify dates.
This patch adds implicit constructors to QDate to support this
convenience, e.g.:
// YYYY-MM-DD, DD-MM-YYYY, MM-DD-YYYY formats:
QDate d1 = 1985y / December / 8;
QDate d2 = 8d / December / 1985;
QDate d3 = December / 8d / 1985;
// Indexed weekday:
QDate d4 = 2000y / January / Monday[0];
QDate d5 = 2000y / January / Monday[last];
and so on.
These are all implemented using the conversion from the std
calendaring classes to sys_days. Conversions between sys_days
and QDate are also added, since they're basically "for free".
I don't expect "ordinary" users to stumble upon it, but it's
worthy mentioning that std::chrono::year *does* have a year
zero (hence, year_month_day in year 0 or below are offset
by one with the corresponding QDate). I've left a note
in the documentation.
[ChangeLog][QtCore][QDate] QDate (and therefore QDateTime)
is now constructible using the year/month/day/week classes
available in the std::chrono library. Moreover, it now
features conversions from and to std::chrono::sys_days.
Change-Id: I2a4f56423ac7d1469541cbb6a278a65b48878b4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As a drive-by, did also minor refactorings/improvements.
Task-number: QTBUG-98434
Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
Percent-decoding was previously only present as a static method taking
a QBA parameter; it might as well be an instance method of that
parameter. Change most QBA tests to use it rather the static method.
[ChangeLog][QtCore][QByteArray] percentDecoded() is now available as
an instance method of the byte array to be decoded, equivalent to the
static QByteArray::fromPercentEncoding().
Change-Id: I982101c44bdac5cc4041e85598d52ac101d38fa1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use new global include snippets for the 'Using the Module' section and
reorganize the sections structure. The sections should follow this
order:
- Using the Module
- Articles and Guides
- Examples
- (API) Reference
- Module Evolution
- Licenses and Attributions
Task-number: QTBUG-100369
Pick-to: 6.3
Change-Id: I239bcf53719f0036867ac1d513dc74e1bfa7bc8b
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Our associative containers' iterator's value_type isn't a destructurable
type (yielding key/value). This means that something like
for (auto [k, v] : map)
doesn't even compile -- one can only "directly" iterate on the
values. For quite some time we've had QKeyValueIterator to allow
key/value iteration, but then one had to resort to a "traditional" for
loop:
for (auto i = map.keyValueBegin(), e = keyValueEnd(); i!=e; ++i)
This can be easily packaged in an adaptor class, which is what this
commmit does, thereby offering a C++17-compatible way to obtain
key/value iteration over associative containers.
Something possibly peculiar is the fact that the range so obtained is
a range of pairs of references -- not a range of references to pairs.
But that's easily explained by the fact that we have no pairs to build
references to; hence,
for (auto &[k, v] : map.asKeyValueRange())
doesn't compile (lvalue reference doesn't bind to prvalue pair).
Instead, both of these compile:
for (auto [k, v] : map.asKeyValueRange())
for (auto &&[k, v] : map.asKeyValueRange())
and in *both* cases one gets references to the keys/values in the map.
If the map is non-const, the reference to the value is mutable.
Last but not least, implement pinning for rvalue containers.
[ChangeLog][QtCore][QMap] Added asKeyValueRange().
[ChangeLog][QtCore][QMultiMap] Added asKeyValueRange().
[ChangeLog][QtCore][QHash] Added asKeyValueRange().
[ChangeLog][QtCore][QMultiHash] Added asKeyValueRange().
Task-number: QTBUG-4615
Change-Id: Ic8506bff38b2f753494b21ab76f52e05c06ffc8b
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Clarified the docs that using the deployment variables is for avoiding
hard-coding of specific paths.
Added docs on how to customize the variable defaults
Added example doc snippet demonstrating how to modify the values.
Added upstream doc links where relevant.
Pick-to: 6.3
Fixes: QTBUG-100924
Change-Id: I938dcadd776c8b7019da4709dfced166454a6c92
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Nicholas Bennett
Andreas Eliasson
Thiago Macieira
Friedemann Kleint
Amir Masoud Abdol
Ahmad Samir
Topi Reinio
Ulf Hermann
Alexandru Croitor
Kai Köhne
Fabian Kosmale
Edward Welbourne
Alexey Edelev
Jaishree Vyas
Morten Sørvig
Patrick Stewart
Mikolaj Boc
Tor Arne Vestbø
Giuseppe D'Angelo
Paul Wicking
Marc Mutz
Joerg Bornemann
Arno Rehn
Venugopal Shivashankar
Øystein Heskestad
Lucie Gérard
Sona Kurazyan
Laszlo Papp
Albert Astals Cid
Cristian Adam
Bartlomiej Moskal
Tinja Paavoseppä