in our tests.
They are not needed anymore since
d20f4ae706 got merged and the
QT_ANDROID_PACKAGE_SOURCE_DIR property is read at generation time
rather than configure time.
This means the
qt_internal_add_test ->
qt_internal_add_executable ->
_qt_internal_android_executable_finalizer ->
qt_android_generate_deployment_settings
calls take care of generation the right value for the property even
with CMake 3.16.
Remove the direct qt_android_generate_deployment_settings calls,
in preparation for their deprecation in public api.
Pick-to: 6.5
Task-number: QTBUG-88506
Task-number: QTBUG-88840
Task-number: QTBUG-108508
Change-Id: Ief1d0f9f620bd37beeedde26dedb66f728fa4a6f
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Fixes issues with readback of storage buffers modified on GPU for D3D
and Metal. Adds unit test for storage buffer readback.
D3D
* Fixes issue where QRhiBufferReadbackResult::completed callback could
be called twice on buffer readback completion.
Metal
* Fixes issue where buffer readback occurred prior to command buffer
being committed.
Change-Id: If55ac005f4438d66d2f65ea2e1ee0d5686c884ff
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The object replacement character (U+FFFC) is used to represent
inline objects such as images in rich-text. To enable this,
we have special handling of it in QTextEngine. For classes
where inline images are not supported, it will just be hidden
from the visual text, which is unexpected.
Instead of always special-casing it, we make this dependent
on whether the document layout has registered any object handlers.
If they have not, then there will be no visual representation of
the object, and it is better to show the glyph for it.
For anything based on QTextDocument, there will always be the
image handler, so U+FFFC will still have special handling there,
but for non-rich labels and plain text editors the glyph will
be shown instead.
Note that there was also a bug in QLineEdit, where the object
replacement character was always replaced by a space. This was
introduced in 2007, in a patch which replaced a !ch.isPrint()
with a check for "the most obvious non-printable characters"
to reduce the number of characters that were not shown. However,
U+FFFC is a printable character and would thus not have been
filtered by the !isPrint() condition, so I think this was a
mistake at the time. However, due to the special-casing of
the character in Qt, it would not have had any effect until
now.
This also changes the QTextLayout::cursorToXForInlineObject()
test to actually test proper inline objects, as this was
previously using a hack which depended on the inline object
code to be used even for plain QTextLayouts with no handlers
for these.
[ChangeLog][Text] The object replacement character (U+FFFC)
is now only filtered out in rich text controls, where they
represent inline objects. In other controls, its glyphs will
be shown as with other text.
Pick-to: 6.5
Fixes: QTBUG-101526
Change-Id: I7fcaf2b10918feb41589e1098016efbf79a0e62d
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
QBuffer::open() was only documented as \reimp, so its behavior
regarding WriteOnly was never actually described.
Add a test and document the outcome.
Pick-to: 6.5 6.4 6.2 5.15
Change-Id: I75c49cd3f6a1961bcaece4a92a4e479bb3300d36
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
tests/auto/corelib/text/qbytearrayapisymmetry/tst_qbytearrayapisymmetry.cpp:1174:80:
warning: overflow in expression; result is -9223372036854775808 with
type 'long long' [-Winteger-overflow]
const qlonglong longMaxPlusOne =
static_cast<qlonglong>(Bounds::max()) + 1;
tests/auto/corelib/text/qbytearrayapisymmetry/tst_qbytearrayapisymmetry.cpp:1175:81:
warning: overflow in expression; result is 9223372036854775807 with type
'long long' [-Winteger-overflow]
const qlonglong longMinMinusOne =
static_cast<qlonglong>(Bounds::min()) - 1;
I usually build with GCC, but building with Clang for clazy-standalone,
so I saw these two warnings 500+ times, enough already. :)
Change-Id: Idd86af568ffe89ae49b2a3f9bbeedf312de5e631
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It looks like AAssetDir_getNextFileName is not enough.
Directories that contain only other directories (no files)
were not listed.
On the other hand, AAssetManager_openDir() will always return a
pointer to initialized object (even if the specified directory does not
exists), so we can't just leave only it here.
Using FolderIterator as a last resort. This approach should not be too
time consuming.
As part of this fix, add some unit tests to cover/ensure assets
listing/iterating works as expected.
Fixes: QTBUG-107627
Pick-to: 6.4 6.2 5.15
Change-Id: Id375fe8f99f4ca3f8cad4756f783ffafe5c074df
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Silence warnings such as:
variable 'sum_lookup_visual' set but not used [-Wunused-but-set-variable]
Change-Id: If38515d9753cf7b79a250985890a139e96e92329
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Cocoa's columnArray::count is an unsiged int, resulting in a compile
warning when QCOMPARE'ed with a signed integer literal.
Change-Id: I420a9e89bba5feeb9d8a040a06e6ba0e209c82f3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Variant-selectors are special unicode symbols which are used to
modify glyph selection for the preceding character. For instance,
a regular symbol could be turned into a color emoji using VS16,
the emoji variation selector. In order for this to work, however,
the font that handles the selector has to handle the full pair of
characters, so that it can apply the correct substitution rules.
One specific example of this was on macOS, where an airplane
symbol + VS16 would match the symbol to the default UI font but
the VS16 to the emoji font. Since there string provided for the
emoji font did not have any preceding character for VS16, we just
ignored it.
To improve on this, we now detect variation selectors that have
been matched to different font engines than the preceding
character. When such a case occurs, we check if the selector font
also supports the preceding character, and if it does, we keep
the pair together and use the same font for both.
[ChangeLog][QtGui][Text] Fix some cases where a variation-selector
character would be ignored in font selection and the correct
variant of a character would thus not be selected.
Task-number: QTBUG-108799
Change-Id: I9f427e0520e652ee2f24a4f7dc3c1957251e06bd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Add storage buffer memory qualifier and run time array stride information
to QShaderDescription::StorageBlock.
Memory qualifiers allow more informed selection of RHI resource buffer
binding (bufferLoad / bufferStore / bufferLoadStore) function.
Run time array stride (for last block member unsized array) allows
packing of buffer data for transfer to / from GPU. Without this
information, applications must infer or guess which packing rules
(std430 / std140) are in use.
Change-Id: I676d7e848afefd40d01cdd463c569b07022b683e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
In the process actually handle all time-spec cases in various places
that only handled UTC or LocalTime, or at least note that they don't
where that's not practical. Also tidy up header ordering and ensure
QDateTime's header is included wherever it's used, while adding the
include for QTimeZone where needed.
Task-number: QTBUG-108199
Change-Id: Ic1a5cdf0aaf737bf1396aa8ac58ce2004cef7e19
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
As foreshadowed when QDateTime adapted to route all QTimeSpec use
through QTimeZone, this commit deprecates the old API in favor of the
newly more capable QTimeZone-based API.
Fixes: QTBUG-108199
Change-Id: I9a3f9f94d4a5d8cc229db72b3e4731a9e318a076
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Input events that originate from actual device interaction should reflect the
device's state, and device and events need to be kept in sync so that event
sequences (such as multi-touch events, where we have begin/update/end cycles
spanning multiple events) are working correctly.
For that reason, the event point data in pointer events is explicitly shared,
and we only detach in exceptional situations. This saves us memory allocations,
and makes sure that the event point data carried by events, and the event point
data stored persistently in the device, are kept in sync.
Cloned pointer events do not originate from device interactions, and should
therefore not sync back to the device. E.g. accepting a clone should not modify
the original event data stored in the device. There are exceptions here as
well, e.g. when cloning an event in Qt in order to deliver a translated version
of it to a different scene. Different points might even get delivered to
different scenes or windows, or at least different items in the same scene. For
that reason, we explicitly detach, and then explicitly write back the relevant
states after the cloned event has been delivered.
But in general, we should assume that cloned events do not write back to the
device. Since QEventPoint is an explicitly shared data type that never detaches
itself, we have to explicitly detach it when making copies that should not be
shared.
The ideal implementation of this would be to do the detach in the copy
constructor of QPointerEvent, which is called when cloning. However, Qt itself
makes copies of QPointerEvent without using clone, e.g. when assembling lists
of touch events for the different subscenes or windows in
QGuiApplicationPrivate::processTouchEvent, where event objects are added to a
QVarLengthArray<QMutableTouchEvent>. This makes copies, and those copies must
not detach.
So we have to implement the special cloning behavior in each override of
QPointerEvent::clone(). For this, introduce a dedicated macro for the common
member functions. This macro must be used for QPointerEvent subclasses.
Fixes: QTBUG-107560
Change-Id: I4b56f9e71c7d067ba9054a2a631e8ba5bc7b1ab9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
XML does not impose any semantics based on the order of the attributes;
they're an unordered set. Quoting [1]:
> Note that the order of attribute specifications in a start-tag or empty-element tag is not significant
and [2] 2.2.5:
> An unordered set of attribute information items
Still, using a QHash-based implementation to store attributes is
annoying, because one cannot serialize the document in a stable way.
The order of attributes is going to depend on the QString hash function
(which we can change at any time) and the QHash seed (which is random
and changes at every run). In other words, saving the same DOM will
yield non deterministic outputs. That's annoying for testing,
reproducible builds, and so on.
Switching to an _ordered_ associative container for storing attributes
won't, on its own, ensure any specific ordering. That's because:
* attributes are currently kept associated using their name as the key,
ignoring an eventual namespace prefix;
* there's some convoluted logic that sometimes emits attributes in the
xmlns namespace (to qualify a prefix).
Hence, just go for the straightforward implementation and sort the
attributes before streaming them. In the main loop I could have used a
range-based for loop over the associative container used for attributes;
since it's a Qt container, it would have yielded just the values in the
map, and we are not interested into the keys. However I'm preparing for
further changes down the road, so I'm opting for key/value iteration.
I'm deliberately not offering an opt-out because:
* I don't think this is so expensive to justify an opt-out;
* I'm going to remove QHash anyways in a follow up commit.
[1] https://www.w3.org/TR/xml11/#sec-starttags
[2] https://www.w3.org/TR/xml-infoset/#infoitem.element
Task-number: QTBUG-76800
Task-number: QTBUG-25071
Change-Id: I6282ae2ccbee9c0099f138de48b94bb7c40b3680
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In the process, centralize the creation of date-time values, where
doing so requires catching invalid results caused by spring-forward
gaps; this saves some repetition and extends the treatment to more
places that did need it. Also, de-inline two overrides of virtuals;
being inline does them no good.
Replace the Qt::TimeSpec member of QDTEPrivate with a QTimeZone so
that creation of values can be streamlined and to make it easier to
add support for (currently unsupported) OffsetFromUTC and TimeZone
timespecs in the public QDTE API.
This greatly simplifies a lot of the code, while preparing it for a
long-needed extension to its functionality.
Task-number: QTBUG-80417
Task-number: QTBUG-108199
Change-Id: I0ac2c78025013bf89899e3ef1a56e89392f67ce5
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This saves (mostly in corelib/time/) some complications that used to
arise from needing different code-paths for different time-specs.
Task-number: QTBUG-108199
Change-Id: I5dbd09859fce7599f1ba761f8a0bfc4633d0bef9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For now, just addDays() and the springForward() test, as proofs of
concept for future work to be more systematic.
Change-Id: Id2c4e9ad304d3aef6fdfb48ae6328df8c638c934
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
[ChangeLog][QtCore][QTimeZone] QTimeZone is now always defined;
feature timezone now controls most of its prior API and some new API
is added, most of it always present, to enable QTimeZone to package a
Qt::TimeSpec and, for Qt::OffsetFromUTC, its offset. Prior to this
change, APIs using Qt::TimeSpec had to provide a separate function
taking a QTimeZone alongside a function taking a Qt::TimeSpec and
optional offset; it will now be possible to unify these into a single
function taking a QTimeZone. Adaptation of other Qt classes to do so
shall follow.
Task-number: QTBUG-108199
Change-Id: If5ec3cc63920af882ebb333bf69cde266b1f6ad7
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
... where 50b05e3e2a originally added
them.
While qtversion.h is included in qglobal.h, using qtversion.h directly
is a tiny step towards removing qglobal.h includes from our code-base,
so don't let this opportunity go to waste.
Change-Id: I28eaca1f4e250fc9e12e2ce6a6f94670a1d08dbe
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This test makes use of a GCC extension-slash-defect in matching of
template template parameters. Either Clang has recently changed its
behavior not to accept them any more, or we've never compiled this test
with Clang.
Tested with Clang 15.0.6.
Pick-to: 6.4
Change-Id: I69ecc04064514f939896fffd172e98d826989ca3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The 'QT_ANDROID_MULTI_ABI_FORWARD_VARS' variable allows to forward
variable values to ABI-specific external projects. The variable accepts
names of variables that needs to be forwarded.
Pick-to: 6.4
Task-number: QTBUG-107893
Change-Id: Iaa4fa7e98ad0df956d90f91e157edb561183c795
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the full set of substringing operations:
- mid/left/right (old-style)
- sliced/first/last (new style)
- chop/chopped/truncate
The implementation is copied from QUtf8StringView, adjusted to use
sliced() instead of the (ptr, n) ctor, so we need to deal with the tag
twiddling only once, in sliced().
The documentation is also copied from QUtf8StringView.
[ChangeLog][QtCore][QAnyStringView] Added substring functions
sliced(), first(), last(), chop()/chopped(), truncate().
Change-Id: Ief454e9694519e97d9146fa84bc05dda1dded046
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Mate Barany <mate.barany@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The test message sent to the dbus might never see a reply, e.g. in case
of a misconfigured dbus. Instead of waiting for a reply and stopping the
static top-level build, timeout after the CI had enough time to receive
the dbus message (5 seconds).
Change-Id: Ic6d60e7d1ddb2d864dc4a78d4edbd0ef7b6604c2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Amends a874087504, which tested whether
d->container is nullptr to decide whether to hide the popup, and then
dereferences d->container later without checking again. This raised a
correct static analyzer warning.
Simplify that logic. hidePopup() does nothing if there is no visible
container, and we don't want to accept() the cancel key if there isn't.
So the closeOnCancel logic isn't actually needed, we only need to accept
the ShortcutOverride to make sure that QComboBox sees the Cancel key
even if there is a shortcut registered, and then we can handle and
accept the cancel key to call hidePopup() only if the popup is visible.
Add test to verify that this interaction works as expected.
Pick-to: 6.4
Task-number: QTBUG-108908
Change-Id: I60d92b068f0f5139d629cf4a58e225512170df77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In the process, split some long lines. The test relies on omitting the
hour (so as to get the default, 0) from both the format string and the
string parsed, so as to test that the parser correctly handles the
corner case where the zone skips the first hour of the day. This was
not entirely obvious when reading the row data, so make it explicit in
a comment.
Change-Id: I919b292b78bd399a8749806a0e913d43f5b414e1
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mate Barany <mate.barany@qt.io>
Test a few more cases are correctly handled.
Change-Id: I7f286ba93f59bf0168cac789cd30590f40e98cee
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The spec deseralized isn't a Qt::TimeSpec; handle it correctly instead
of taking for granted that QDateTimePrivate::Spec's values happen to
match.
Change-Id: I67f3c960f3a3b90cdad3c1eca673f7ec8fd10b82
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Mostly pedagogic checks in operator_insert_extract(), but also
sanity-checking, to confirm spec conversions produce results equal to
what each came from.
In daylightTransitions(), verify the spring forward goes from standard
time to daylight-saving time.
Change-Id: Ieb9c603ee2eadecea055da4e8889528161f4d999
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Use QCOMPARE(a, b) in place of QVERIFY(a == b), similar with
QCOMPARE_LT() and QCOMPARE_LE(); and use a scope-guard to emit a
message on failure instead of incurring the cost of building a string
for the message, even when the passing test doesn't need it.
Change-Id: I3884bc40e89a4b1ba881968b99faab27d4b1abc9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Principally to get Qt::LocalTime mentions out of the way ahead of the
QTimeZone work on Qt::TimeSpec, but also mop up trailing 0 parameters
to QTime for seconds and milliseconds.
Change-Id: I51041582faae100894a567c9e5ae96a60a3b2d8c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Mate Barany <mate.barany@qt.io>
Left over from long ago, making confused use of Qt::hex.
Change-Id: I7f411e4888ee1a637d2212fd6976dd003f8da9ce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Several were overlong (or soon to get so by being made longer); others
were inconsistent with neighbors; one was inconsistent with itself.
Change-Id: I272680499605a757e4827d27021bf234a91cf77a
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As a result, also make sure the test will fail if output to debug
stream doesn't produce the expected result.
Change-Id: I9914c9c41c8d8b79f32dfb8e0c735f12e2d59f5e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Put core includes all in a common form, sort alphabetically.
Remove a stray blank line.
Change-Id: I211c6b407f5e49d907cb065521883567f1dd30f4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Comparing to true and false doesn't enrich the output.
Change-Id: Ie26a3f3d584f88310b8d4a31cad07be8dc8cb646
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Same fix as in tst_qbytearray's QCOMPARE() in
cb9715557c.
Pick-to: 6.4 6.2
Change-Id: I2222d9015ae7121a2fbcf5b936b27de20e873064
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
After this change, private CMake scripts are mostly live in
`libexec/`, except the `qt-cmake` which will stay in `bin/`.
This doesn't affect the Windows configuration.
- `qt-cmake` stays in `bin/`
- `qt-configure-module` moves into `libexec/`
- `qt-cmake-private` moves into `libexec/`
- `qt-cmake-private-install.cmake` moves into `libexec/`
- `qt-cmake-standalone-test` moves into `libexec/`
- `qt-internal-configure-test` moves into `libexec/`
In cases where `QT_GENERATE_WRAPPER_SCRIPTS_FOR_ALL_HOSTS` is set to
ON, e.g., ANDROID, WASM, both Batch and Bash files will be generated
and placed in `bin/` and `libexec/` accordingly; in both cases,
qt-cmake and qt-cmake.bat will be in `bin/` anyway.
[ChangeLog][CMake] The private Qt CMake scripts, i.e.,
qt-configure-module, qt-cmake-private, qt-cmake-private-install.cmake,
qt-cmake-standalone-test and qt-internal-configure-test were moved
into $prefix/libexec on Unix platforms.
Fixes: QTBUG-107621
Change-Id: Ic4f4ec85f64d2ede0e208bca928959e30be906a6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends fccd419dd6.
If Harfbuzz failed on one of the items in a string and returned
zero glyphs, then we would exit the shaping loop. The mentioned
change fixed a crash related to this when the ignored character
was the only character in the string, but it occurred in a
subitem of a longer string, then we would return and fail to
lay out the rest of the string.
This popped up recently because an update to Harfbuzz has caused
it to return zero glyphs when applying the Apple emoji font to
an isolated variant character (see bug report). When we matched
the symbol to the main font and only the variant character to
the emoji font, we would get in this situation, and end up
exiting the shaping early.
[ChangeLog][QtGui][Text] Fixed a regression which would
sometimes cause text to disappear if the string contained
an unmatched variation selector character.
Pick-to: 6.4
Fixes: QTBUG-108799
Change-Id: I616ab1b2d33c2df731419c5ce06fbc578a625a32
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When Harfbuzz returns zero glyphs, this will typically be because
the character is ignored. We currently have no way to differentiate
this from actual error cases, so to avoid return the error glyph
for cases which are not really errors, we set the dontPrint flag
for this.
When we add a way to differentiate between error cases and non-error
cases later, we should revert this for the actual errors.
Pick-to: 6.4
Task-number: QTBUG-108799
Change-Id: I2a910d951b71c705fb4dd761fcfe3a942b3afa7c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
There is no technical reason why qFatal shouldn't support categorized
logging, nor have a streaming version.
There is perhaps an API issue, that is, a streaming syntax may encourage
users to do "too much":
qFatal() << gatherLogs() << saveDatabase() << ...;
and that sounds like a bad idea in case the application is in an
unrecoverable state that requires immedate terminatation (indeed,
through qFatal). I'd err on the side of providing the extra convenience.
This commits adds overloads of QMessageLogger::fatal to support
categorized logging (note that fatal messages cannot be disabled),
the relative qCFatal macro, as well as overloads for streaming.
[ChangeLog][QtCore][QMessageLogger] QMessageLogger::fatal now supports
categorized logging, for instance using the qCFatal(category) macro.
Moreover, qFatal() and qCFatal() now support streaming of values
to be printed in the fatal message.
Change-Id: Ia57f25f5c85fca97e5fcf27eaa760dbde09cba0e
Fixes: QTBUG-8298
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
