summaryrefslogtreecommitdiffstats
path: root/tests
Commit message (Collapse)AuthorAgeFilesLines
* QHttp2Stream: add Configuration with downloadBuffer optionHEADdevDennis Oberst111 min.1-0/+55
| | | | | | | | | | | | | | | | | | | Especially useful for clients who don't use the PUSH_PROMISE functionality and don't require buffering the data. We add the QHttp2Stream::Configuration struct to allow customizing stream behavior. Every stream comes with a configuration and the default constructed objects represents that. The configuration is per-stream and does not change during the lifetime. Add a testcase with further extensibility in mind for further stream configurations. Task-number: QTBUG-142473 Pick-to: 6.11 6.10 Change-Id: I1e862f4996baa61f024f40516f74fc052a9b57c4 Reviewed-by: Alexey Edelev <semlanik@gmail.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Bump version to 6.12.0Jani Heikkinen6 hours4-4/+4
| | | | | Change-Id: I788b0b0b10284703aaf4153e2b714444a3fbcf44 Reviewed-by: Antti Kokko <antti.kokko@qt.io>
* QReadWriteLock: fix data race on weakly-ordered memory architecturesMiao Wang18 hours1-0/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Testcase: ./tst_qreadwritelock heavyLoadLocks When the test run under release mode on arm64, all the spawned threads may block without this fix. When the test run with optimization enabled and assertions enabled and the assertions for !mutex.try_lock() are removed from the entry of QReadWriteLockPrivate:: lockFor{Read,Write}, random assertion failures may happen without this fix. The reason for the race is because when a lock is uncontended locked and being converted into a contended lock, no synchronization happens between the initialization of new allocated QReadWriteLockPrivate object and the use of the existing QReadWriteLockPrivate object in lockFor{Read,Write}. QReadWriteLockPrivate objects are allocated from a statically allocated freelist and it is of high probability that the newly allocated object has just been released. The possible execution order that leads to a data race is described as follows: Suppose there are three threads T1, T2, and T3, and T1 holds the write lock initially. T1 first releases the lock, and then gains the read lock, while T2 tries to gain the write lock, and T3 tries to gain the read lock. The interleaved execution order is as follows, where <- means a normal memory write, <1> means a memory address of a QReadWriteLockPrivate object, : means a return value, #n means a synchronization point. For abberviation, wc denotes writerCount and rc denotes readerCount. The .h/.c and the number in the parentheses denotes the line number in qreadwritelock.h/.cpp. T2 T1 T3 unlock() lockForRead() d = d_ptr.loadRelaxed(): <1> (.h 52) d = d_ptr.loadRelaxed(): <1> (.h 52) <1>->mutex.lock() (.c 393) d = d_ptr.loadAcquire(): <1> (.c 229) <1> <-{wc = 0}(rc should be 0) (.c 397) <1>->mutex.lock() ... (.c 236) d_ptr.storeRelease(null) #1 (.c 409) <1>->release() (.c 410) <1>->mutex.unlock() #2 (.c 412) lockForRead() <1>->mutex.lock() returns #2 d = d_ptr.loadRelaxed(): null (.h 93) lockForWrite() d_ptr.testAndSetAcquire(1) #3 (.h 81) d = d_ptr.loadRelaxed(): 1 (.h 116) val = allocate -> <1> (.c 321) // ^ suppose <1> is reused here <1> <-{rc = 1}(wc should be 0) (.c 325) d_ptr.testAndSetOrdered(<1>) #5 (.c 326) d = d_ptr.loadAcquire(): <1> #6 (.c 335) d_ptr.loadRelaxed(): <1> (.c 237) <1>->mutex.lock() ... (.c 342) // Here T3 sees the d_ptr load result // as <1>, which is the same as // before, thinking it unchanged and // thus continues to execute // d->lockForRead(). // T3 here has no synchronization T2, // but had synchronization with T1 at // #2. So T3 may see the stale data // previous written by T1 to <1>, i.e. // wc = 0, rc = 0 <1> <-{rc = 1} (.c 432) <1>->mutex.unlock() #4 (.c 248) <1>->mutex.lock() returns #4 d_ptr.loadRelaxed(): <1> (.c 343) // The same happens to T2 here, it continues // to execute d->lockForWrite(). // T2 here is synchronized with T3 at #4, // so T2 must see the data written by T3 // to <1>, i.e. wc = 0, rc = 1 <1>->writerCond.wait() (.c 455) After the above interleaved execution, T2 is blocked while T3 and T1 are holding the read lock, but in the QReadWriteLockPrivate object, the readerCount is 1, which is incorrect. This might further lead to deadlock if readerCount becomes -1 after the two readers release the lock or letting a writer to proceed when only one of the readers releases the lock. The fix changes the relaxed load of d_ptr in lockFor{Read,Write} after the acquire of the mutex to an acquire load, to establish synchronization with the release store of d_ptr when converting from an uncontended lock to a contended lock. Fixes: QTBUG-142321 Change-Id: I5a570471b52359dd65f309e644d9aacfd58ce943 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QRMA: try to constrain the data source for insertColumn(s)Volker Hilsheimer20 hours1-4/+4
| | | | | | | | | | | | | | | | | | | | | insertColumn can insert a data element, or a range of data elements, which then inserts one element from the source range for each row. insertColumns can insert a range of data elements (which is then the data inserted into each row), or a range of ranges of data elements (in which case we insert one range from the source for each row). Try to constrain this by inspecting the input data type, and allowing only compatible data elements, as well as ranges holding compatible data elements. Make the API test more specific - test with lists of integers, so that we can confirm that such input data wouldn't be allowed to add columns to a model holding pointers. Pick-to: 6.11 Change-Id: I1b67510b3f70f147530a3ae453b01328f2e639d2 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* tst_qt_testrunner: do not write XML files to current directoryDimitrios Apostolou20 hours1-16/+24
| | | | | | | | | | | The tests under class Test_testrunner_with_xml_logfile did not pass --log-dir to qt-testrunner.py, so XML files were being written to CWD. Fix that by forcing --log-dir argument over the whole testsuite. Pick-to: 6.11 6.10 6.8 Change-Id: Iaf66e86970a07595cf995df3a4cdd5f272644ffb Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* qt-testrunner: check validity of the XML file on test function re-runsDimitrios Apostolou20 hours1-9/+18
| | | | | | | | | | | | | | | | | | | | | Tests on certain platforms run with specific wrappers, that might have trouble reporting back the proper exit code. For example, on Android each test is transfered to the device/emulator and is executed not as a separate process, but as an activity. The equivalent of "exit code" is caught and returned by a special wrapper script for the platform. It happens sometimes that these wrapper scripts fail to report back correctly, and report zero (0) despite failed tests. For that reason we now parse the test XML log on individual test re-runs too, and reporting inconsistencies as CRASH, like we do with the main test execution. Task-number: QTQAINFRA-7349 Task-number: QTQAINFRA-7378 Pick-to: 6.11 6.10 6.8 Change-Id: I27525f22331d44141be8825786a6f71e89543e92 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Test qt-testrunner as the first test that CTest runsDimitrios Apostolou20 hours5-0/+852
| | | | | | | | | | | | | Only for inside the Coin CI, as it is Coin that uses qt-testrunner by exporting TESTRUNNER=qt-testrunner. Also rename the test executable from tst_testrunner to tst_qt_testrunner to avoid confusion with other testrunners, or generic $TESTRUNNER testing. Pick-to: 6.11 6.10 6.8 Change-Id: I607f8c2affec2ca5dd38b4a333abb3a324d2078c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* QFuture::cancelChain(): improve propagation through unwrap()Ivan Solovev23 hours1-0/+79
| | | | | | | | | | | | | | | | | | | | | | | | QFuture::unwrap() returns a new QFuture that is not added to the continuation chain, but potentially fulfilled by both outer and nested futures. As a result, the parent-child relation in the continuation chain is broken, and a cancelChain() call will not be propagated up the chain through unwrap(). Fix it by explicitly adding the newly-created QFutureInterface into the hierarchy. This requires using some private API of QFutureInterfaceBase, so add UnwrapHandler as a friend class. There is still one more pending issue with the cancellation propagation: if at the time of cancellation the outer future is already finised and the nested is in progress, the cancellation will not be propagated into it, and so it will finish successfully. This issue should be addressed separately. Task-number: QTBUG-140786 Pick-to: 6.11 6.10 Change-Id: I62a4038f4544fff3cca65cb817940ae8b48db384 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Test: Verify QTest::qWaitFor() result in tst_qparallelanimationgroupLu YaNing42 hours1-3/+1
| | | | | | | | | | Use QVERIFY to validate that animation starts before deletion and eliminate the compiler warning. According to 33eeb091629889fec2c6332dcaf6ec1021febb82 Pick-to: 6.10 6.11 Change-Id: I1358116cb124d85a2cc05d6d610c44f0b656ea0d Reviewed-by: Tim Blechmann <tim.blechmann@qt.io>
* QColor: add benchmark for toHsl() and toHsv()Marc Mutz47 hours1-0/+37
| | | | | | | | | I'm interested in whether the planned fixes of the qFuzzyCompare() calls in these functions have a measurable performance impact. Pick-to: 6.11 6.10 6.8 6.5 Change-Id: I2385e6b6ef8483516bd4fe83a077cabea8a7f159 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Fix failing tst_QComboBox::popupPositionAfterStyleChange openSuSE 16Frédéric Lefebvre47 hours1-0/+1
| | | | | | | | | | | | | | | | tst_QComboBox::popupPositionAfterStyleChange was failing consistently where the mouseEvent was sent just a few pixels out of the popup. Set a fix size for the popup. On openSuSE, the popup width appears to be twice its actual size. The cause of this is still unclear. Workaround to Fix consistently failing tst_QComboBox::popupPositionAfterStyleChange on openSuSE 16. Fixes: QTBUG-141772 Change-Id: I9f659c02ea3af862b57025aead8cc27462bf59aa Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QRMA: add setRange overloads for initializer list and iteratorsVolker Hilsheimer2 days1-0/+10
| | | | | | | | | | | | | | Factor the setRange logic out into helper functions. For the iterator version, use a std::ranges compatible Iterator/Sentinel pair API. Also add "assign" aliases for the new overloads. No assign alias for the existing setRange overload, as that would be assign_range in STL API. Pick-to: 6.11 Change-Id: Ibbcfc1ec53c31fea2a6646e5d70486fe237fdff3 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* QRMA: clean up memory in test caseVolker Hilsheimer2 days1-15/+39
| | | | | | | | | | | | | | The model doesn't take ownership of the item objects, so we have to delete them when the row items get destroyed. As usual, tree items that are not move-only are a mess, so make them move only, and implement move-semantics to explicitly clear the moved-from row's array (as moving from a std::array doesn't clear the source). Adapt the test case accordingly. Pick-to: 6.11 Change-Id: I4722be0bbe3846f7e274583d19b75beb502b7095 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* QRMA: add move assignment operator to DataReferenceVolker Hilsheimer2 days1-1/+1
| | | | | | | | | | | | | | Don't copy the new value into the QVariant if we can move it. Also add move-construction and move-assignment SFM to the DataReference type itself; they don't save us anything right now, but it clarifies the semantics. Amends e22cd01076e795ed853b0536605d3bb205587d78. Pick-to: 6.11 Change-Id: I6cdba7a03f5e6e59bb9e2f5e44483fea7b1ed1cc Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* tst_qpluginloader: fix running with MSVC in debug modeThiago Macieira3 days1-4/+4
| | | | | | | | | | | | | | | | | | Amends commit 418890e0748384eb684f33b10dc6f32493aee54b ("QPluginLoader: fix loading of plugins with a relative file name") from Qt 5.0. Are we not running debug mode tests in the CI? C:\Qt\qt6\qtbase\tests\auto\corelib\plugin\qpluginloader\tst_qpluginloader.cpp(181) : message location WARNING: tst_QPluginLoader::loadHints() testdata bin/theplugin.dll could not be located! C:\Qt\qt6\qtbase\tests\auto\corelib\plugin\qpluginloader\tst_qpluginloader.cpp(181) : message location FAIL! : tst_QPluginLoader::loadHints() Compared values are not the same Actual (loader4.loadHints()) : 0 Expected (QLibrary::ResolveAllSymbolsHint): 1 Pick-to: 6.11 6.10 Change-Id: I25b6278aa3b572d59315fffdae3f9b1d79d8a52a Reviewed-by: Tim Blechmann <tim.blechmann@qt.io>
* Re-add tests for old iterablesUlf Hermann3 days1-6/+264
| | | | | | | | | | We want to keep them until Qt7. Amends commit 9adaf8505a9eb9d7acb7fee6aeac5341aa24a074. Pick-to: 6.11 Change-Id: I59922fe56704f09e5b6a73e66361e0e6f7cdf501 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Core: Rename constants to upper caseUlf Hermann3 days1-6/+6
| | | | | | | | | Amends commit 9adaf8505a9eb9d7acb7fee6aeac5341aa24a074. Pick-to: 6.11 Change-Id: I03b60f79f4c267f5dff7da0b004e11ec567f96eb Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QMenu: return the triggered widget action from exec()Volker Hilsheimer4 days1-0/+22
| | | | | | | | | | | | | | | | | | | | A QMenu executed via QMenu::exec is expected to return the QAction that was triggered to close the menu. For QWidgetActions, this case is handled explicitly in the private _q_actionTriggered slot, as the mouse event is handled by the widget, and not by the menu. However, QMenu's mouse and key event handling was the only place where the current action got updated, and written also to the "syncAction" for menus opened synchronously. As a result, QMenu::exec returned nullptr if the menu was closed by triggering a widget action. Fix this by setting the current and sync action in the code that closes the menu when a widget action gets triggered. Fixes: QTBUG-141992 Pick-to: 6.11 6.10 6.8 Change-Id: Ie506b33dab8f9bd5b6fd54fd3fc91a107cbda64f Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
* a11y: Add tests for check state change notifications of item view itemsIngo Klöcker4 days1-0/+100
| | | | | | | | | | This change adds some tests for QListView, QTreeWidget, and QTableWidget to verify that assistive technology is notified about changes of the check state of checkable item view items. Task-number: QTBUG-141856 Change-Id: Ic7fb7618ad94cca6cc266c2f52b8b62b0864e4a4 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* MetaObjectBuilder: add support for Virtual and OverrideDmitrii Akshintsev6 days1-0/+37
| | | | | | | | | Adapt MetaObjectBuilder to newly added property attributes. Task-number: QTBUG-98320 Change-Id: Ife1d388fd75939c730055746426dbf5459e170d8 Reviewed-by: Sami Shalayel <sami.shalayel@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QMetaObject: Include a class def's hash in the meta objectOlivier De Cannière6 days1-3/+4
| | | | | | | | | | | | | | The hash has the following format <hash_revision>$<hash_b64>, where hash_revision is an integer and hash_b64 is the base64 encoding of the hash. MetaObjects built using QMetaObjectBuilder do not yet support the hash. That will need to be added at a later point. Task-number: QTBUG-142186 Change-Id: Ifafc7df2202decf48e8a1a45e652c2f61c5cea64 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* moc: Add the hash of a ClassDef to json outputOlivier De Cannière6 days3-0/+186
| | | | | | | | | | | | | | | | | | | | | | | | Cpp code generated by qmlcachegen relies on stable metaobject layouts. They will, however, inevitably change in a incompatible way every now and then. This renders the cache files compiled with a previous version and stored on a user's machine invalid and unsafe to use. There is currently no mechanism to invalidate the cache files if a meta object breaks compatibility, by adding a signal for instance. To address this, we can record hashes of the meta objects a compilation unit relies on and invalidate it when a mismatch is found at runtime before executing it. We then fall back to other mechanisms to run the code. This first step adds the logic to compute the hash of a metaobject to moc and adds it to its json output. The hashes are of the form <hash_revision>$<base64_hash> Task-number: QTBUG-142186 Change-Id: Ifdd56b6259874024341a2b2623d088a45816b0a1 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QRM(A): Allow initializing a raw nullptr with an objectVolker Hilsheimer7 days1-6/+9
| | | | | | | | | | | | The ownership mess is not a problem if there's nothing stored at the position yet, and it allows gradually populating a row of raw object pointers. Hook newly inserted objects up to the autoConnectProperties mechanism. Add test case. Change-Id: Ie029a2a358e6a1ed5f24869039be9c2ad542dff9 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* Implement a backend of QIORing for WindowsMårten Nordheim7 days2-1/+16
| | | | | | | | | | | | | | | | | | | | | Using the IORing API on Windows to provide asynchronous I/O operations. Some parts supplemented by using some blocking API where we don't have an option (yet). Currently that just includes the 'stat'/size operation as well as Open and Close. Though with Close we schedule a flush and close the handle ourselves once the callback is invoked. The API is quite limited so far, but sufficient for what we have now. The implementation can be extended later as needed. The Vectored I/O operations are not actually vectored unfortunately, the Windows API requires page-aligned memory and sector-aligned file offsets, which makes it really impractical to provide generically. For a very limited time: limit the configure options to Windows 11. Task-number: QTBUG-136763 Change-Id: Iee57a23358a71ab6bfd007ff15b760b65ea76406 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* tst_qurl: deduplicate data in test rows for tst_QUrl::resolving()Thiago Macieira7 days1-1/+1
| | | | | | | | | | | Amends commit 4b1547adc9b195e6acc90471fc48dec7ee0c429d, which added these two lines. Clearly a copy & paste error. Pick-to: 6.10 6.8 6.5 Task-number: QTBUG-120396 Change-Id: I9c70b99776af7f26f11efffdc1dac60c2267d12c Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* QMetaProperty: Introduce VIRTUAL, OVERRIDE attributesDmitrii Akshintsev7 days2-0/+50
| | | | | | | | | | [ChangeLog][QML] VIRTUAL and OVERRIDE attributes will be used for the expanded override semantics in QML. See QTBUG-98320 for the details. Task-number: QTBUG-98320 Change-Id: I56826a6b9158c0beeb58ad1564a58c22f15027bf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* a11y - Send ObjectDestroyed for interfaces without objectsEven Oscar Andersen8 days1-0/+16
| | | | | | | | | Interfaces without an object calls deleteInterface directly, issue ObjectDestroyed events also in this situation. Task-number: QTBUG-141125 Change-Id: I0dc7ff5e45a5fe61af01957eb4c8088cc2e64e17 Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* QVectorND: do not assert when deserialization yields NaN or ±∞Marc Mutz8 days1-0/+77
| | | | | | | | | | | | | | | | | | These types happily hold NaNs and infinites, if you know what you're doing, and so we can stream such objects out. We cannot then refuse to stream them back in again. [ChangeLog][QtGui][QVector2D/QVector3D/QVector4D] Fixed a bug in the QDataStream operator that could lead to an assertion failure (program termination) on reading back previously streamed out objects that contain NaN or infinity values. Amends 7a738daa97436478a21b5dd31ba2312b2cb2df41. Pick-to: 6.10 6.8 6.5 Fixes: QTBUG-142431 Change-Id: I790d7fbc46e5bd48a2cbd7e8a26d9c90c5fe05b9 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QRMA: hook inserted objects up to auto-connectVolker Hilsheimer8 days1-0/+91
| | | | | | | | | | | | | | | | Auto-connecting properties is enabled in models where all item data is backed by the same QObject subclass. When assigning a new row, an entire branch of rows in a tree, or assigning a fresh range as the children of a row, then the new items need to be connected. Some of these items might be nullptr, in which case we have so far stopped the connection loop early (by returning false from the helpers). Fix that to only stop early if a connection failed (i.e. if role names and properties in the objects are not aligned), but continue if we encounter a nullptr entry in the item data. Change-Id: I2c4b5e5beedc7b38c40ee459c2e0437568b9b087 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* Add QRangeModelAdapter: C++-style access to the range while talking QAIMVolker Hilsheimer8 days6-27/+2752
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a QRangeModel represents a C++ range, then the C++ range must no longer be modified directly, as clients of the model won't be notified about data or structural changes. Ignoring this (documented) warning might end up with views not presenting the data correctly, or even result in crashes as the model cannot update QPersistentModelIndex instances. Modifying the range through the QAbstractItemModel API is ok, but clumsy, as it requires dealing with QModelIndex and QVariant for basic operations. QRangeModelAdapter provides an easy, type safe, and data-structure aware API for reading and also modifying a range that a QRangeModel operates on. This includes an interator API for rows, and - unless the range is a list - columns. Dereferencing row iterators yields a row reference type from which a row can be accessed for reading, or that a new row can be assigned to. Dereferencing a const column iterator yields an item; dereferencing a mutable column iterator yields a reference type that a new item value can be assigned to. Since QRangeModel itself is not a template class (so we don't know the type of the range anymore once it has been created), we have to create the adapter from the range (and optional protocol), which then implicitly creates the model. Constructing the adapter implicitly constructs the model, which is owned by the adapter. QRangeModelAdapter is a value type, using std::shared_ptr for the model so that all copies of the adapter operate on the same model. To be able to set entire multi-role objects as items, introduce a new Qt::ItemDataRole enum value, Qt::RangeModelAdapterRole. This is very similar to Qt::RangeModelDataRole, but QML has specific requirements that QRangeModelAdapter doesn't have, and we want to pass items back and forth without modifying their value category - ie. an item that is a shared_ptr<Object> is not useful for QML (which needs an Object *), but a C++ user expects to get a shared_ptr<Object> from a call to at(), and also expects to be able to set such an item. The code has room for de-duplicating some logic in follow-up commits. [ChangeLog][Core] Added QRangeModelAdapter for C++-style access to a range used in a QRangeModel, while implementing QAbstractItemModel protocol. Change-Id: I3f2f94cb51b850100590fbe2c9a7c9dabbec59bd Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* QRM: don't use std::applyVolker Hilsheimer9 days2-0/+36
| | | | | | | | | | | | | | std::apply only works for types compatible with std::get, but it doesn't consider get() in terms of ADL. So we can't use it to call a function on each element in a tuple-like row type with get() in its namespace. Instead, we roll our own helper template using an index sequence + ADL-compatible get() usage. Amends f9bb6c8d900205375c70bb33f359ce0250212460 Change-Id: Ic0858f95f1dcc6333b09336189f5adde7309ef75 Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
* Remove operator[] from meta-association iteratorsUlf Hermann9 days1-9/+0
| | | | | | | | Most of them are not random access and operator[] makes no sense then. Amends commit 8d359d61c16641d523e4189a7d473b6126b11011. Change-Id: I724aaf98e14114d0fd1cb5bce5fdc2ed4690dae0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Fix waitForBytesWritten() -> readyRead() -> write from user codeAndreas Hartmetz9 days1-0/+47
| | | | | | | | | | | | | | | | | | | | | | waitForBytesWritten() can emit signals, most importantly readyRead(), *before* even writing data. Anything can happen in slots connected to these signals - which includes writing out some data, which can make a subsequent attempt to write data in waitForBytesWritten() fail(*), so waitForBytesWritten() fails. Recognize when anything invoked from the current call wrote out some data and return success instead. It is not possible to deal correctly with all shenanigans in signal handlers, but this seems quite reasonable. Also fix QAbstractSocket build with QABSTRACTSOCKET_DEBUG defined. (*) for at least two reasons: nothing to write anymore or OS write buffer full Pick-to: 6.10 6.9 6.8 6.5 Change-Id: Ibf4de93d5e7dc2f88b675de410b216674faa20ad Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Core: Add operator[] to our meta-iteratorsUlf Hermann10 days1-4/+84
| | | | | | | | It's required by std::random_access_iterator_tag. Fixes: QTBUG-140181 Change-Id: Icb9c72395ea5c1a26069ac66d969c98fb9a58407 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Include variable axes in QFont::toString()Vlad Zahorodnii10 days2-11/+50
| | | | | | | | With this change, variable axes can be saved and loaded from settings. Task-number: QTBUG-141412 Change-Id: I0744d05cc38ac47d89f3e4314311906c28c0ec63 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Core: Provide non-broken metacontainer iterablesUlf Hermann10 days1-83/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QSequentialIterable and QAssociativeIterable are incapable of providing operator[] on their iterators because the references used by those iterators are not actually stable when the iterator is modified. The only way to fix this in a binary compatible way is to provide a complete set of new iterables and iterators. These are implemented in qmeta{association|sequence}.h and exposed through QMeta{Association|Sequence}::Iterable. In order to give users a convenient way to include those, we instruct syncqt to regard qmeta{association|sequence}.h as header to use in order to provide QMetaSequence and QMetaAssociation. These headers are the natural choice anyway. qmetacontainer.h still has to hold the (now incomplete) declarations for QMetaSequence and QMetaAssociation so that we remain source compatible. The new iterables offer a more consistent set of accessor methods and deprecate some of the old accessor methods. It makes little sense to add or remove a value from/to an iterable at an unspecified place. The new sequential iterable offers the more familiar append/prepend and removeFirst/removeLast methods. Finally, the new iterables warn when taking a slow code path that synthesizes operations not avaible on the actual container using iterators. There generally is a reason for those operations to not be available and we shouldn't second-guess the choices made by the authors of the container. For now, we have to keep those code paths intact to remain compatible with QSequentialIterable and QAssociativeIterable. Task-number: QTBUG-140181 Change-Id: I2f4c32716951fa023ae1fb8028d1a87e4c85c3a0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Schannel: Don't access empty list of CommonName for local certificateMårten Nordheim10 days3-2/+64
| | | | | | | | | | | | | | | | I accidentally wrote the code under the assumption that the local certificate will have some sort of CommonName, but that is not necessarily the case. This made it impossible to use a certificate without one. Amends 94f0ff704ead631114ecd2e10ba0839dad1aae10 Pick-to: 6.10 6.8 Fixes: QTBUG-142324 Change-Id: Idfac0b50f3f2abd36b39c7687c9fce2b259c3806 Reviewed-by: Mate Barany <mate.barany@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* tst_qxp_is_virtual_base_of: guard a MSVC versionGiuseppe D'Angelo10 days1-1/+1
| | | | | | | | | | | | Follow the rule of always guarding compiler versions when working around bugs; the test actually passes since MSVC 19.40 (at least). Amends 35878fa924d0598b1cdec5ba358e8488f6774676. Task-number: QTBUG-138246 Pick-to: 6.10 6.8 Change-Id: Id2d6eed4605ef3568ede1185827556b0ebd08fb5 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* tst_qxp_is_virtual_base_of: fix a test towards ambiguous basesGiuseppe D'Angelo10 days1-0/+6
| | | | | | | | | | | | | | | | | | | | | | | If a derived class inherits from the same base class both virtually and non-virtually, our implementation of the is_virtual_base_of trait cannot properly detect this due to the ambiguity, and will answer "false". On the other hand the version shipping in C++26 will correctly answer "true" (there *is* a virtual inheritance path). Amend the test to take this into account. Practically speaking, this behavioral difference isn't a cause of concern: this trait is used to guard conversions of pointers from derived classes towards base classes. That implies that the inheritance is not ambiguous (otherwise the pointer wouldn't be convertible to begin with). Amends 35878fa924d0598b1cdec5ba358e8488f6774676. Task-number: QTBUG-138246 Pick-to: 6.10 6.8 Change-Id: I5b115a826202d1fb6c793678d4660c847c1a7c71 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* wasm: remove manual dead key translationLorn Potter11 days2-405/+0
| | | | | | | | | | | | Dead keys are now handled through QWasmInputContext. This removes the duplicated and previous method of dead key handling. Remove deadkeytranslator auto test, as it was testing the dead key translator class being removed. Change-Id: Ibada7ba873ff109d5ad2837a8d2fba354b7eb8c2 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Even Oscar Andersen <even.oscar.andersen@qt.io>
* QList: add missing Q_CHECK_PTR in the constructors and in reserve()Thiago Macieira11 days1-0/+33
| | | | | | | | | | | | | Because QArrayDataPointer doesn't. QString and QByteArray constructors do this. resize() already has the macro because it uses QArrayDataPointer::reallocateAndGrow(). squeeze() is untestable. Pick-to: 6.10 6.8 Fixes: QTBUG-142345 Change-Id: I8e7898aed09364f20d1efffdc7ed70a2c152005c Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Add QIORing backend for QRandomAccessAsyncFileMårten Nordheim11 days1-6/+16
| | | | | | | | | | | | | | | | This adds a backend for QRandomAccessAsyncFile to use the recently introduced QIORing. Since all uses of of QRandomAccessAsyncFile expects signals to be emitted after returning control to the caller, and QIORing may complete anything synchronously, we emit signals only after returning to the event loop. This could probably be optimized later to be a direct emission when it's not technically needed, but is not a priority right now. Task-number: QTBUG-136763 Change-Id: I8acfa7f716e5625da498cc4b6fbe493ebd783f99 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* QIORing/Linux: handle >2gib reads&writesMårten Nordheim11 days1-5/+0
| | | | | | | | | | | | | | | | | Linux internally truncates any read and write at a limit of 'MAX_RW_COUNT', which is slightly less than 2 GiB, for a few reasons. We will work around it by reading or writing some segments at a time, re-issuing another read/write operation whenever one completes until completed, EOF if reading, or an error occurs. Note that this MAX_RW_COUNT also applies to readv and writev, which means we would need a similar mechanism there to handle this. This is to be done in a follow-up. Task-number: QTBUG-136763 Change-Id: I9bcb75587ae5e84cb80ea3950a569f60c4906617 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Introduce QIORing to abstract io_uring on LinuxMårten Nordheim11 days4-0/+291
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat low level code, intended as a low level abstraction. The QIORing interface would also be used for Windows' IORing, developed at the same time as the io_uring version. There is some shared code and helper functions, but a lot of the code in some way touch the platform specifics, so without yet more abstractions quite some code is left as unique. The fiveGiBReadWrite test case is currently EXPECT_FAIL because of the MAX_RW_COUNT limit on Linux (and its inability to report >2GiB results). Either we have to document this in the public-facing parts, or we need to work around / iron over the issue. To be done in a follow-up patch. We only ever notify the kernel of the work to be done after returning to the event loop, unless the ring is full. Then we notify the kernel right away in hopes it will manage to clear up some space to queue more. We, ourselves, are not actually limited by the kernel ring buffers as we keep a queue (in the form of a std::list) of pending tasks. The reason why it's a std::list is that it guarantees stable references, and that lets us use the pointer-to-task as the 'user_data' of the submitted work, so we can easily access the task again when the kernel adds it to the completion queue. Task-number: QTBUG-136763 Change-Id: I9cb80a2b96a49f2a557bef3b0ad6d367d76f5ab8 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* JNI: Allow clients to opt into their own exception handlingVolker Hilsheimer14 days3-1/+578
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Detect whether the return type of a call is similar to std::expected. This indicates that the caller wants to handle exceptions explicitly, so in case of error, we pass it through the the std::expected-like value. We still clear the exception state. The caller is responsible for freeing the jthrowable local reference. For this to work, we have to propagate errors through to the outer-most function. This includes allowing QJniObject to create QJniEnvironment instances that don't implicitly return a clean environment in the destructor. As long as we can call checkAndClearExceptions() in the public functions (unless the caller opts in), this should not break any existing code that expects QJniObject to implicitly clear exceptions. Add tests for all overloads to make sure that exceptions (from wrong class or method names, and thrown in methods) are caught. Add "Impl" helpers that do not handle exceptions if instantiated accordingly, and call those if we have to maintain compatibility in public functions while also enabling opt-in handling for modern APIs. Add tests that show that we can now handle exceptions ourselves for all public QJniObject APIs. If possible, we build the test with C++23 so that we can use std::expected; otherwise, try to use tl::expected by downloading the header-only implementation from github; and failing that, use a minimal implementation of a type that could be used instead and makes the test pass. Fixes: QTBUG-93800 Fixes: QTBUG-119791 Task-number: QTBUG-92952 Change-Id: I1cfac37ac9af8fd421bc0af030a1d448dd0e259e Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* tst_QAtomicScopedValueRollback: add a check for atomic<shared_ptr>Marc Mutz2025-11-281-0/+29
| | | | | | | | | | | | | | | | | Unlike the non-atomic QScopedValueRollback (which has a moveOnly() test to catch such mistakes), QAtomicScopedValueRollback was missing some std::move()s in the implementation. While std::atomic<unique_ptr> is not a thing™, and we thus can't add a moveOnly() check here, atomic<shared_ptr> is, so use that to test. This won't flag missing move()s, because shared_ptr is copyable, but a check of the class for non-trivial payload types was missing, and this adds that. Pick-to: 6.10 6.8 6.5 Change-Id: Ib0ef06be9ef1a6a66564373ff74bdff35dd7b285 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QFlatMap: remove STL-compatibility guard macroMarc Mutz2025-11-281-1/+0
| | | | | | | | | | The macro has been silently active since 6.5, with no way to disable it, so remove it now, after two LTS releases have been released with this new default. Pick-to: 6.10 Change-Id: Ibc12fa59707a75eb9e4a452471a83e9df206a7b6 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* tst_q23_expected: fix GCC -Wformat-zero-lengthMarc Mutz2025-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | GCC warns if a format string is statically known to be empty. Since we mark up printf-style QTest::addRow() using the resp. attribute, GCC warns here, too: tst_q23_expected.cpp:23:19: warning: zero-length gnu_printf format string [-Wformat-zero-length] 23 | QTest::addRow("") << false; | ^~ Instead of using the old newRow(), add some content to the data tag instead. It cannot be left unmentioned that this test doesn't test ... very much. I hope we don't use this component in production code, yet... Amends 4e9f4d5d02e29b4522540b8f9b9b01b7e57a6b54. Pick-to: 6.10 Change-Id: I50ebb074997e034506c6602ff7602ad392b745be Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Tim Blechmann <tim.blechmann@qt.io>
* wasm: Refactor PromiseEven Oscar Andersen2025-11-283-0/+550
| | | | | | | | | | | | | | | | | | | | | | | | Switch from a function based implementation to making Promise a object. Maps straightforward to a javascript promise, except for this: We need to do cleanup when the promise has been fully processed. We do this by adding a final handler. However, the handlers are called in the order they are added, so the final handler we add in the constructor will be executed too early. We solve this, in a non optimal way, by adding a final handler after each then, and catch, handler. This makes the interface easy to use, even if it is suboptimal Fixes: QTBUG-142138 Change-Id: I6be3f102e838467cc98f4a9825fd5f6fe0e1e1a2 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* wasm: Remove promise manual testEven Oscar Andersen2025-11-283-521/+0
| | | | | | | It will be replaced by an auto test Change-Id: Ie7bc9acba6080fd191e31e61ce378023003b599c Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-12 18:42:12 +0000