Skip on crashing tst_qvulkan test
Blacklisted completer_data on qfiledialog
(8d76c5af51 should have been enough but
it is still failing)
Task-number: QTBUG-108328
Task-number: QTBUG-108329
Change-Id: Iad5573af60cca16d16ba0462293e276186e25653
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This effectively reverts a4a51f6a64
while solving the problem that change intended to fix by an
alternative approach: Swap the order of checks for rhi-based
flushing. Checking the widgets' wishes first was a mistake. We should
first check what is forced, e.g. via the env.vars. Then only move on
investigating the child widget hierarchy if there was nothing specific
requested.
This way having a QOpenGLWidget in a window and running with
QT_WIDGETS_RHI=1 QT_WIDGETS_RHI_BACKEND=vulkan will prioritize the
forced request (Vulkan) and so the QOpenGLWidget will gracefully not
render anything while printing the expected warning to tell what's
going on.
The expensive recursion plaguing the construction of larger widget
hierarchies is now avoided, that should no longer take seconds due to
walking the entire widget hierarchy of the top-level window every time
a new widget is added to it.
However, this then uncovered a set of problems concerning native child
widgets. The repaint manager seems to have an obvious mistake where
the usage of rhi (and so textures and whatnot) is decided based on
'widget' (which is either a top-level or a native child) instead of
'tlw' (which is the top-level with the backingstore). The usesRhiFlush
flag only really matters for a real top-level, not for native child
widgets. The rhi-based flushing is tied to the backingstore, and the
backingstore comes from the top-level widget.
Finally, make the qopenglwidget autotest to actually exercise
something when it comes to QOpenGLWidgets (or their ancestors) turned
native. The original code from a long time ago does not really test
native child widgets, because it turns the top-level into native which
is quite superfluous since the toplevel is backed by a native window
(and a backingstore) anyway.
Pick-to: 6.4
Task-number: QTBUG-105017
Fixes: QTBUG-108344
Fixes: QTBUG-108277
Change-Id: I1785b0ca627cf151aad06a5489f63874d787f087
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
saveRestoreGeometry() somtimes creates a 29px offset when debugged in
Qt Creator, which makes the test fail.
This patch adds a code comment to make developers aware of this fact.
Pick-to: 6.2 6.4
Change-Id: I920bd02eb7543faf8b25a0a242b888f3a3745e2a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
multipleToplevelFocusCheck() occasionally failed on XCB because
QApplication::activeWindow() was nullptr immediately after
qWaitForWindowActive() returned true.
This patch replaces QCOMPARE on QGuiApplicaiton::activeWindow() with
QTRY_COMPARE in order to continue spinning the event loop until the
condition has been met. It adds QWidget::activateWindow after show()
to ensure focus is acquired also when another window has received
focus in the meanwhile.
Pick-to: 6.2 6.4
Change-Id: If84eb8b77c5a6b16af271334a1fe5eb92c05644b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The test function raise() occasionally failed because of unexpected
paint events being counted.
This is due to a QTRY_VERIFY returning after consumption of the first
paint event. If more than one paint event got posted, it will be
delivered and counted when no more paint events are expected.
This patch ensures that all paint events are consumed before resetting
the count and expecting no more paint events.
Fixes: QTBUG-68175
Pick-to: 6.2 6.4
Change-Id: I3e91a34e851da4bd01c7429e824d2b9101077a06
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The uses of the click_cocoa_button() function was removed in 2012,
in ba21ca7b5b.
Change-Id: If7abfc56bb307cfbf9f6628cec9c7267a8a1f31f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This tests that strings using the first Unicode code-point of such a
multi-character token don't get recognized as "valid" number strings.
This would catch an implementation issue if the parsing code
mistakenly matched against only the first code-point of each "single
character" token.
It also adds tests of integer formatting, with multi-character sign,
and reworks some QStringView().toString()s to use u"..."_s.
Task-number: QTBUG-107801
Change-Id: I7b868ce2955bb322b3ecfc200438a21437090a0c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Based on those for QString, but with locale variation and exercising
some of the locales with multi-character signs and exponents.
Pick-to: 6.4 6.2 5.15
Change-Id: Id0253449f9abcc154285f89337aa0e26dd69900d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Based on the tests for QString::number(), but run in reverse, with
some embelishments. Also moved some shared code from number_*_data()
to their shared number_integer_common template.
Pick-to: 6.4 6.2 5.15
Change-Id: I74e7082372166c3cdbcd6bcbc31f9003e07cbcbc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Upon programmatic window state changes, windowStateChange was fired
once in QWindow::setWindowStates and once when the visual state had
been changed by the window interface.
This patch adds if guards to ensure that the singal is fired only once.
It adds a corresponding autotest to tst_QWindow.
tst_QWidget::resizePropagation() is adapted to no longer expect double
signal emission.
Fixes: QTBUG-102478
Pick-to: 6.4 6.2
Change-Id: If093c0a883d76d8a676e4fab90db6b0676452267
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When a complex object (i.e. one with children that are themselves not
fully exposed objects) gets focus, then we need to inform the
accessibility system about which child object actually has focus. This
was only done for item views, but not for other complex widgets.
An editable QComboBoxes is the focus proxy for its line edit. The line
edit never gets focus itself (QComboBox forwards relevant events),
and is the accessible child item with index 1. So when an editable
combobox gets focus, it needs to raise the automation event for the
line edit child.
Implement QAccessibleComboBox::focusChild to return the interface to the
lineedit for editable comboboxes so that the UI Automation bridge can
correctly notify about the focus being moved to an editable text input
field.
Fixes: QTBUG-107572
Pick-to: 6.4 6.2
Change-Id: Id60e2791ec859365255baa9bfd01547979cd2b44
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
For a11y purposes, a table needs to be mapped into a logical
accessibility hierarchy. There are several ways of doing this mapping,
and unfortunately macOS expects something different than what
QAccessibleInterface does.
So suppose we have a a 2x2 QTableView with both horizontal and vertical
header like this (the names reflect the QAccessible::Role names):
+-----------+--------------+--------------+
| | ColumnHeader | ColumnHeader |
+-----------+--------------+--------------+
| RowHeader | Cell | Cell |
+-----------+--------------+--------------+
| RowHeader | Cell | Cell |
+-----------+--------------+--------------+
In order to be presented to the screen reader on a platform, it goes
through two rounds of mapping:
QAccessibleInterface will have all headers and cells as direct children of the table:
- Table
+- ColumnHeader
+- ColumnHeader
+- RowHeader
+- Cell
+- Cell
+- RowHeader
+- Cell
+- Cell
macOS expects a deeper hierarchy:
- AXTable [QAccessible::Table]
+- AXRow [Qt:no eqiuivalent]
+- [QAccessible::Cell] (The content of the cell, e.g. AXButton, AXGroup or whatever)
+- [QAccessible::Cell] (The content of the cell, e.g. AXButton, AXGroup or whatever)
+- AXRow
+- [QAccessible::Cell] (The content of the cell, e.g. AXButton, AXGroup or whatever)
+- [QAccessible::Cell] (The content of the cell, e.g. AXButton, AXGroup or whatever)
+- AXColumn (this seems to just store the geometry of the column)
+- AXColumn (this seems to just store the geometry of the column)
+- AXGroup (this represents the column headers)
+- AXSortButton (clicking a header cell will trigger sorting)
+- AXSortButton (clicking a header cell will trigger sorting)
It's unclear to me how RowHeaders are mapped (they are rarer than
ColumnHeaders, I expect to find them in e.g. spreadsheet applications).
I haven't found any native usage of them. So this patch simply ignores
them.
Notice that macOS have a three layer deep hierarchy to represent a table
(Table->Row->Cell), while QAccessibleInterface has a two-layer deep
hierarchy (Table->Row/Cell).
In the macOS bridge we therefore need to "inject" the Row/Column element
to be "between" the table and the cell.
The table will take ownership of all row and column elements that are
children of the table. These elements are not inserted into the cache
(it would be pointless, since the cache is basically just a mapping
between the QAccessibleInterface -> QMacAccessibilityElement, and the
row and column elements does not have a corresponding
QAccessibleInterface to be mapped from).
The rows and columns are therefore also created as soon as the table
element is initialized, and they are stored in two NSMutableArray
members of QMacAccessibilityElement.
A table is constructed like any other accessibility element, with a
valid axid and synthesizedRole set to nil.
Each child row and column element is constructed with the same axid as the
parent table element, and they will have the synthesizedRole set to
either NSAccessibilityRow or NSAccessibilityColumn.
With the synthesizedRole member we can then identify if we are a row,
column or the actual table, and implement their respective behaviors.
Notice that the child row/column is created with the parent's table axid
in order for them to have a way of finding their parent table element.
(there is no 'parent' member variable in QMacAccessibilityElement)
This glorious scheme isn't pretty, but seems to work.
Fixes: QTBUG-37207
Change-Id: I7c2451e629f5331b9a0ed61dc22c6e74a82cc173
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When comparing a glyphIndex with a hard coded number, the number is
cast to an int, whereas the glyphIndex is an unsigned int.
That causes a compiler warning.
This patch forces the numbers to be cast to an unsigned int.
Change-Id: I8a31124c6afacfc4ecfb13caf2cb8133dad44a21
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Debug serials and detatch numbers of deep and shallow detatch in test
function cacheKey, if it fails.
That implicitly removes a compiler warning about these variables being
unused.
Change-Id: I481f4b63e3ed0d50fb442dffc658b97d913059bc
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
And add license headers and some minor fixes for warnings in the
example and test.
Task-number: QTBUG-90498
Change-Id: I34592f7f2844c92c25a6a676c8ac1ffca9e03c6d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The usage of the helpers was removed in 2011,
in bf8dfc394a.
Change-Id: I950812982148fd76bcc65c4781a144c21cb3c901
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The lock and unlock of the Android deadlock mutex is now part
of the internal implementation instead of limited to the enum
based permission API. It is unclear why 8bca441b6f added
the guard only to this API and not to the string based API
as well.
The check for isBackgroundLocationApi29 has been removed,
as the logic seemingly resulted in accepting every single
permission type except location permissions if used via
the enum-based API.
Since Android's platform permission API doesn't have an
Undetermined status, we keep a hash of the status for each
permission type, and by default checkPermission() would
return Undetermined, until a requestPermission() call
is done which updates the internal hash, and after that
checkPermission() would return properly Granted/Denied.
Task-number: QTBUG-100413
Change-Id: Ia95c76af754481a281bc90198e349966c9c2da52
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Most of them were easy to change. The pair one was a bit of a stretch,
but still worked. I've removed the lines on QPair, since QPair is
std::pair in Qt 6.
Change-Id: I3d74c753055744deb8acfffd17246ec98c583d08
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
qIsNumericType does not return true for enum types, which meant we never
called numericCompare() or numericEquals() when one of the types was an
enum.
Task-number: QTBUG-108188
Change-Id: I3d74c753055744deb8acfffd172449c68af19367
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The code implementing the C++ rules of type promotion and conversion
was too pedantic. There's no need to follow the letter of the standard,
not when we can now assume that everything is two's complement (this was
true for all architectures we supported when I wrote this code in 2014,
but wasn't required by the standard).
So we can reduce this to fewer comparisons and fewer rules, using the
size of the type, not just the type ID.
Change-Id: I3d74c753055744deb8acfffd172446b02444c0c0
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Generate bc file using the "new way".
Task-number:QTBUG-106331
Pick-to: 6.4
Change-Id: I70d2c0e5026636deee1b8389f50f51e075187b76
Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
qWaitForWindowActive was called in two test functions without
activating the relevant widget.
This patch adds widget activation before calling
qWaitForWindowActive.
Helper function verifyColor:
A loop made six comparison attempts of widget size, pixel color and
image with a 200ms waiting time after each unsuccessful attempt.
The widget size was tested at the beginning of the loop.
The test was failed on the first size mismatch, which occurred when
verifyColor was called before the widget was rendered.
That has lead to flakiness (e.g. on openSuSE).
This patch encapsules each check in a lambda and calls qWaitFor to
ensure event processing until each condition has become true.
Change-Id: Ic98f93c8acf41459bc728f2969fe8b01768048dd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Follow-up to 8222e06d12, which only reset
the item repaint count.
Flushing the queued paint events will bump numRepaints, and the whole
point of calling reset() is to prepare a consistent state before the
next test, so we need to call it after flushing the events.
Pick-to: 6.2 6.4
Change-Id: Id1fe840c14c0940d7020cf8f8cc6a3aeceaa5fb5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This patch replaces the first instance of QCOMPARE with QTRY_COMPARE /
QVERIFY with QTRY_VERIFY after a call to QWidget::grabGesture.
It re-groups verifications so that the verification of the highest
event count is on top.
The test function customGesture is skipped if
QGestureManager::deliverEvents cannot establish a target to deliver
the custom event.
Change-Id: I8188559a40ed5be86f3c6e9c82fa54a97ce5d7d6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The insets used to calculate the correct height were not the best
choice. It used display cutout insets which would work correctly on
most devices, but in the case of an emulator or a device without a
camera, it could fail to calculate correctly.
Task-number: QTBUG-107604
Task-number: QTBUG-107709
Task-number: QTBUG-107523
Pick-to: 6.4 6.4.1 6.2 5.15
Change-Id: I8c4da83ae7359a0c133dbeb02dbd2cd260565f78
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Setting the flag QSurfaceFormat::StereoBuffers does not actually do
anything, because we do not utilize the extra buffers provided. We need
to expose setting the correct buffers using glDrawBuffers between draw
calls.
Change-Id: I6a5110405e621030ac3a2886fa83df0cfe928723
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Flushing the queued paint events will bump numRepaints, and the whole
point of calling reset() is to prepare a consistent state before the
next test, so we need to call it after flushing the events.
Pick-to: 6.2 6.4
Change-Id: Iaefc9854caafe82c65c9587e18fd081439e8dda6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The qfiledialog test was failing on completer_data test. The fix
available for Android 11 also works in Android 7, so removed the if
clause.
Task-number: QTBUG-105377
Change-Id: I76a4c1073a754c9b299cfe731f42b80da1a6f8e2
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
It may take some time before the shown window is available through the
accessible hierarchy, so do an asynchronous test for that to happen.
Pick-to: 6.4
Change-Id: I3f312ae636505b805899973678b1bf10a65f96b3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There's no need to split it, we can use the -x compiler flag to build
the .cpp file as Objective-C++, or, as done here, just rename the file.
This allows us to use QVERIFY and friends, giving more precise failure reporting.
Pick-to: 6.4
Change-Id: I6fb1c4454335082c8a39010c5b75c59e6ec6561b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When a compound widget is created not directly before its children,
then another widget will be in the focus chain between the compound and
the compound's first child. If one of those children is then made the
focus proxy of the compound, then the widget in between becomes
unreachable by tabbing.
To fix this, detect that we set the focus proxy to be a descendent of
the compound widget, and then move the compound widget directly in front
of its first child in the focus chain. This way we can't have any gaps
in the focus chain.
Augment the test case with a corresponding scenario. As a drive-by, move
the debug helper up in the code so that it can be easier used, and set
object names on relevant widgets.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-89156
Change-Id: I17057719a90f59629087afbd1d2ca58c1aa1d8f6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Basic unitttest and one to verify erase returns iterator, not
const_iterator.
Change-Id: I44c3b82b4686ff3809648063376f5e36fb7e181d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- If the string isn't shared, don't call detach(), instead remove characters
matching ch, and resize()
- If the string is shared, create a new string, and copy all characters
except the ones that would be removed, see task for details
Update unittets so that calls to this overload of remove() test both code
paths (replace() calls remove(QChar, cs) internally).
Drive-by change: use QCOMPARE() instead of QTEST()
Task-number: QTBUG-106181
Change-Id: I1fa08cf29baac2560fca62861fc4a81967b54e92
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
- If this bytearray isn't shared call d->erase() as needed
- if it's shared, instead of detaching, create a new bytearray, and copy
all characters except for the ones that would be removed
See task for details.
Adjust unittest to test both code paths.
Task-number: QTBUG-106182
Change-Id: I806e4d1707004345a2472e056905fbf675f765ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This reverts commit 79a11470f3, which
resulted in QTBUG-105735. The new behavior is worse and affects multiple
screen readers, while the old issue is isolated to Windows Narrator and
could be considered a narrator bug.
Task-number: QTBUG-105735
Pick-to: 6.2 6.4
Change-Id: Ic8be1dbd592a3fdf2c3219ec4c5524bc2c7f0f6a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When submitting applications to the iOS and macOS AppStore the
application goes through static analysis, which will trigger on
uses of various privacy protected APIs, unless the application
has a corresponding usage description for the permission in the
Info.plist file. This applies even if the application never
requests the given permission, but just links to a Qt library
that has the offending symbols or library dependencies.
To ensure that the application does not have to add usage
descriptions to their Info.plist for permissions they never
plan to use we split up the various permission implementations
into small static libraries that register with the Qt plugin
mechanism as permission backends. We can then inspect the
application's Info.plist at configure time and only add the
relevant static permission libraries.
Furthermore, since some permissions can be checked without any
usage description, we allow the implementation to be split up
into two separate translation units. By putting the request in
its own translation unit we can selectively include it during
linking by telling the linker to look for a special symbol.
This is useful for libraries such as Qt Multimedia who would
like to check the current permission status, but without
needing to request any permission of its own.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change-Id: Ic2a43e1a0c45a91df6101020639f473ffd9454cc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
- If this string isn't shared, don't call detach, instead use ->erase() as
needed
- If this string is shared, create a new string, and copy all elements
except the ones that would be removed, see task for details
Update unittest to test both code paths.
Task-number: QTBUG-106181
Change-Id: I4c73ff17a6fa89ddcf6966f9c5bf789753f6d39e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When 'this' is IPv6 and 'other' is Any then there is no point in testing
'other's IPv6 address.
Added extra tests against QHostAddress::Any*.
Pick-to: 6.4 6.2 5.15
Fixes: QTBUG-108103
Change-Id: I09f32b1b147b1ec8380546c91cd89684a6bebe2e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
With the introduction of QAnyStringView, overloading based on UTF-8
and Latin-1 is becoming more common. Often, the two overloads can
share the processing backend, because we're only interested in the
US-ASCII subset of each.
But if they can't, we need a faster way to convert L1 into UTF-8 than
going via UTF-16. This is where the new private API comes in.
Eventually, we should have the converse operation, too, to complete
the set of direct conversions between the possible three
QAnyStringView encodings L1/U8/U16, but this direction is easier to
code (there are no error cases) and more immediately useful, so
provide L1->U8 alone for now.
Change-Id: I3f7e1a9c89979d0eb604cb9e42dedf3d514fca2c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
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>
Borrowed from tst_qtemporaryfile with some changes.
Change-Id: I596ddd0ac8dbe10edd63e481198064dcec15d3e6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
If we use winrt's factories we have to make sure to to clear the factory
cache when one of our dlls is unloaded or we will run into dangling
factory entries which might result in crashes. So we have to make sure
that winrt::clear_factory_cache is called on every dll unload.
In order not to increase compile times and dependencies too much
qfactorycacheregistration_p.h needs to be included in Qt code whenever
we use winrt's factory cache. A rule of thumb being: Include
qfactorycacheregistration_p.h whenever including winrt/base.h.
Other Qt modules which use winrt's factories need to be updated too.
Fixes: QTBUG-103611
Pick-to: 6.2 6.4
Change-Id: I7ab24e4b18bffaca653c5b7f56a66ce99212e339
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
