aboutsummaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Reflect Pane.content{Width,Height} through implicitContent{Width,Height}Tor Arne Vestbø2024-12-181-3/+15
| | | | | | | | | | | | | | | | | | | | | When a Pane does not have an explicit content size set, we pick up the content size from the implicit content size, so the two are in sync. However, if an explicit content size is set, we were failing to reflect this through the control's implicit content size, which means that any client of Pane can not treat it as a plain Control, reading its implicit content size to do layouting. We now keep the two values in sync, even when an explicit content size has been set. As a drive-by this also fixed a bug in QQuickPane::resetContentWidth() where we would unset hasContentHeight instead of hasContentWidth. Pick-to: 6.9 Change-Id: If24b15bef51d3841932d2bf6d645087ccca677a9 Reviewed-by: Mitch Curtis <[email protected]> Reviewed-by: Richard Moe Gustavsen <[email protected]>
* Defer safe area update to geometry change on size or position changeTor Arne Vestbø2024-12-181-13/+8
| | | | | | | | | | | Now that we are not relying on itemTransformChanged for our own updates of safe area margins we can apply the logic to defer the update to itemGeometryChanged more broadly. Pick-to: 6.9 Change-Id: Ibb7e19c5b8aeaf04e4e5803c50cefae612729b04 Reviewed-by: Mitch Curtis <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* Remove safe area change listener on all items on destructionTor Arne Vestbø2024-12-182-0/+25
| | | | | | | | | | | | | | | We listen to transform changes on the item we're attached to, but also to geometry changes on any item that affects the transform of the attached item. During destruction of the safe area the geometry change items may still be alive, which would end up with a crash if they try to notify the dead safe area of changes. We now track the items we listen to, and remove ourselves before the safe area is destroyed. Pick-to: 6.9 Change-Id: I9cc5197b9dabcbb40a23c6094c7989fe480b349d Reviewed-by: Fabian Kosmale <[email protected]>
* Update safe areas without going through itemTransformChanged if possibleTor Arne Vestbø2024-12-183-4/+18
| | | | | | | | | | | | | | | | | | When the QWindow's safe area margins change, or additional margins are set on a QQuickSafeArea, we need to propagate this to any affected safe areas. Doing it via itemTransformChanged worked, because we were already hooking into that to detect when an item is moved, but was making it hard to reason about whether the transform change could be deferred until the corresponding geometry change. We now use an explicit function to update safe areas, which also works in paint order, as opposed to itemTransformChanged which delivers in reverse paint order (a bug, that will hopefully be fixed). Pick-to: 6.9 Change-Id: If2e033dfa0306ff5980b43e9a1e5721d7ec0e3da Reviewed-by: Mitch Curtis <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* Defer reporting of safe area margins for an item until its completionTor Arne Vestbø2024-12-183-0/+10
| | | | | | | | | | | During application startup the size and position of an item has not yet been determined, which means that its safe areas will be wrong, so we defer computation of the first safe area update until the item is completed. Pick-to: 6.9 Change-Id: Icc4dd75684a732eaf2a3de3eb0e622318749a197 Reviewed-by: Mitch Curtis <[email protected]>
* QtQml: Avoid potential gc issuesFabian Kosmale2024-12-1825-73/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicitly constructing a value from a ReturnedValue muddies the responsibility for ensuring that the gc can find the object. With this change, we disable the implicit conversion. The expectation for lifetime management is now: - If a ReturnedValue is stored on the C++ stack, it must be put into a QV4::Scoped class (or there should be a comment why not doing so is safe). Passing a ReturnedValue to a function should no longer be possible, unless the function takes a ReturnedValue, in which case the expectation is that it stores the value in a place where it can be seen by the gc, before doing anything that could trigger a gc run. Using Value::fromReturnedValue can still be used to pass a Value on, but in that case, the expectation is that there is a comment which explains why this is safe. - If a QV4::Value is obtained from a function call, it ought to be stored in a ScopedValue, too. We currently can't enforce this easily, so this should be checked during code review. A possible way forward would be to disallow returning Values, but that would be a larger change, and is deferred to the future. - If a functions has a QV4::Value parameter, it's the callers' responsibilty to ensure that the gc can find it. Pick-to: 6.9 6.8 6.5 Fixes: QTBUG-131961 Change-Id: Iea055589d35a5f1ac36fe376d4389eb81de87961 Reviewed-by: Ulf Hermann <[email protected]>
* QV4::Value: introduce undefined helper methodFabian Kosmale2024-12-181-0/+5
| | | | | | | | | | | | A value storing a primitive like undefined is completely safe. Having a helper method to create it eases porting (usafe) code which directly accepted QV4::ReturnedValue as a parameter to a variant taking a QV4::Value. Pick-to: 6.9 6.8 6.5 Task-number: QTBUG-131961 Change-Id: Ib1c27d45706faa570edc175245e9f34b4ceabcc8 Reviewed-by: Ulf Hermann <[email protected]>
* HeapValue: Introduce set overload taking ReturnedValueFabian Kosmale2024-12-181-0/+3
| | | | | | | | | | | | In general, methods should not take a ReturnedValue. However, set leads directly to a write through the WriteBarrier, so it's safe. Adding the overload now helps to prepare for next commit which removes the implicit conversion from ReturnedVaule to Value. Pick-to: 6.9 6.8 6.5 Task-number: QTBUG-131961 Change-Id: I3fe2fbfbc1893190840bc8e48637eec3ae43ce46 Reviewed-by: Ulf Hermann <[email protected]>
* FluentWinUI3: Show focus frame when focus reason is from arrow keysDoris Verria2024-12-181-5/+5
| | | | | | | | | | | | | | | | | | We don't have a Qt::FocusReason enumerator value that represents the focus reason being arrow keys, so for cases that an item gains focus due to arrow-key navigating, the focus reason will be OtherFocusReason. The FluentWinUI3 style only draws the focus frame when the focus reason was Tab/Backtab to avoid drawing it for focus reasons other than keyboard focus, but it should draw it for when focus shifts due to arrow keys too, so include Qt::OtherFocusReasons in the conditions. Also, reset the focus frame when we can't find a focus object AND when the focus reason is none of the above in order to avoid showing the frame around an item that lost focus because of another reason. Fixes: QTBUG-130328 Pick-to: 6.8 6.9 Change-Id: I6cbc13124a0e672bf453896bafd0ba1d8656449e Reviewed-by: Mitch Curtis <[email protected]>
* Focus frame: Don't delete focus frame whenever new focus item is nullDoris Verria2024-12-182-2/+8
| | | | | | | | | | | | | | | | | | When we didn't find a new target focus item we would destroy the focus frame object and recreate it the next time a new valid focus item is found. This can be expensive due to cleanup and reallocation calls, and it can also lead to a crash during parent destruction because the focus frame gets deleted as part of the parent item's destruction, potentially triggering changes in the focus object that result in another attempted deletion of the focus frame. Instead, in case of an invalid new focus item, we should just set the focus frame's target item to null when calling moveToItem. This will handle that case by making the frame invisible and setting its parent to null. Pick-to: 6.9 6.8 Change-Id: Icf46af0ce3c79bab09343a2262688fb33ed8a4d9 Reviewed-by: Richard Moe Gustavsen <[email protected]>
* FocusFrame: Remove the kludge with the invisible root itemJan Arve Sæther2024-12-183-62/+50
| | | | | | | | | | | Now when we call setTransparentForPositioner(true) on the focus frame, there is no need to keep the root item with size(0,0). The only purpose of having that item was so that layouts would ignore the focus frame. Pick-to: 6.8 6.5 6.9 Change-Id: I6224dced83c054b573eb682997e238a0cf1f4776 Reviewed-by: Jan Arve Sæther <[email protected]> Reviewed-by: Doris Verria <[email protected]>
* QQuickMaterialTextContainer: don't explicitly create a brushVolker Hilsheimer2024-12-181-1/+1
| | | | | | | | | Rely on the implicit construction, and allow for an optimized QPainter::drawBrush(QColor) to not create a brush at all. Pick-to: 6.9 6.8 Change-Id: I9a18c72f85afb1383ce9f2056830f02330cf2897 Reviewed-by: Eirik Aavitsland <[email protected]>
* QQmlPropertyMap: code tidiesGiuseppe D'Angelo2024-12-171-1/+1
| | | | | | | `validKeyName` just uses the input parameter, so it can be `static`. Change-Id: Ib54949b04c490599db87055f4e6b458a274479f8 Reviewed-by: Ulf Hermann <[email protected]>
* QtQml: Generalize the global/illegal namesUlf Hermann2024-12-1714-154/+145
| | | | | | | | | Instead of passing them around everywhere, use the ones we statically know and only validate them when creating a new engine. Task-number: QTBUG-131721 Change-Id: I7fb93d15eb6e4194c46249727bcf7a48f5dce730 Reviewed-by: Fabian Kosmale <[email protected]>
* QtQml: Fix some coverity warningsUlf Hermann2024-12-171-4/+4
| | | | | | | | | Make temporaries const and remove dead code. Coverity-Id: 470750 Coverity-Id: 470763 Change-Id: I04552ecd9a908de0f70241c5c93bba6912063113 Reviewed-by: Semih Yavuz <[email protected]>
* QtQml: Simplify type loader thread life cycleUlf Hermann2024-12-178-96/+59
| | | | | | | | | | | | We don't have to keep the thread object around at all while the thread is not running. Just deleting and re-creating it tremendously simplifies things. Furthermore, we can now create it on demand the first time it's needed. This way we gain the ability to determine whether it's still safe to initialize values the thread will later read without locking. Task-number: QTBUG-131721 Change-Id: I702c563ac744387e1be82364b3e87874741d89f4 Reviewed-by: Fabian Kosmale <[email protected]>
* QtQml: Reverse the roles QQmlThreadPrivate "main" and "thread" objectsUlf Hermann2024-12-171-16/+17
| | | | | | | | You should not move a QThread into itself. Luckily, we already have a separate object for the "other" thread. Just move that one instead. Change-Id: Iae5443fee12d752bce98f5dbf6751166efeb73f6 Reviewed-by: Fabian Kosmale <[email protected]>
* Use MAP_JIT on all Apple platformsUlf Hermann2024-12-171-5/+4
| | | | | | | | | | | | ... and make it actually compile. ... and set the flag for JIT pages being prepared. We are clever enough not to make them executable right away. Pick-to: 6.9 6.8 Task-number: QTBUG-131957 Change-Id: I07dc6a9c8ec7d0881d73fc5bd44a6059f66dd2eb Reviewed-by: Fabian Kosmale <[email protected]>
* QtQml: Revert to old executable memory detection for macOS on x86Ulf Hermann2024-12-171-0/+21
| | | | | | | | | | | | | | | Since we cannot figure out what exactly has to be done to prevent the JIT from crashing, we perform a partial revert of commit 912af1e8b4c1f62802a3e0a4b428bb4e9f4d2c90, only for this platform. The bug fixed by the original change is specific to linux. Therefore this doesn't cause any real harm. Pick-to: 6.9 6.8 Fixes: QTBUG-131957 Change-Id: Ic3baf32aae1f0f2feb9abc34b9f43a5db867165b Reviewed-by: Tor Arne Vestbø <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* Software Renderer: Ensure flushing of previously dirty regionsAndy Nichols2024-12-171-1/+9
| | | | | | | | | | | | | | | | | | Previously, if an opaque item was moved completely behind another opaque item between frames, the previous region occupied by the item might not be flushed. This occurred because, when subtracting the obscured region from the node’s dirty region, the dirty region could become empty. In such cases, the node would mark itself as no longer dirty, resulting in no flushing for the next frame. This could cause the old position of the item not to be cleared properly. To address this issue, additional logic has been added to ensure that the previous dirty region is still flushed, even in this edge case. Fixes: QTBUG-132192 Pick-to: 6.9 6.8 6.5 Change-Id: Iad45ddeeb65e70090e8368d94245b13692017fd1 Reviewed-by: Eskil Abrahamsen Blomfeldt <[email protected]>
* ColorInputs: Move validators from global scope to the scope they're usedOliver Eftevaag2024-12-161-18/+19
| | | | | | | | | | | | | | | The coverity complains about GLOBAL_INIT_ORDER. By making them static and moving these validator objects to the function where they're used, they should be initialized lazily during the first repopulate() call, instead of at program startup. Coverity-Id: 470767 Coverity-Id: 470766 Coverity-Id: 470761 Coverity-Id: 470749 Pick-to: 6.9 Change-Id: Ice9bfb7a02901b82a2d91ce8f93bbe5866c90ac7 Reviewed-by: Volker Hilsheimer <[email protected]>
* QQuickItem: add trailing comma to ItemChange enumVolker Hilsheimer2024-12-161-1/+1
| | | | | | | | Amends 9062ba372a32536d97a6ff6a5605544a8c82f48e. Pick-to: 6.9 Change-Id: I97ccb24261d2d434e8fc7e524b4d2c3b190c4a15 Reviewed-by: Tor Arne Vestbø <[email protected]>
* Doc: fix linking warningsVolker Hilsheimer2024-12-164-7/+8
| | | | | | | | | | | | We can't link to a signal that's not explicitly documented, we can only link to the property it belongs to. Member functions in a different scope use '::', not '.'; and properties don't have parenths. Pick-to: 6.9 Change-Id: I5c87ab5dbd97e4612a032d7adf7248d23af05c6f Reviewed-by: Andreas Eliasson <[email protected]>
* QQuickListViewPrivate::fixup: fix potential use-after-freeVladimir Belyavsky2024-12-141-8/+13
| | | | | | | | | | | When using the StrictlyEnforceRange highlight range mode, call updateHighlight() _before_ calling snapItemAt(), because if we do that later, the item returned by snapItemAt() might be destroyed as soon as updateHighlight() calls applyPendingChanges() internally. Fixes: QTBUG-129231 Pick-to: 6.9 6.8 6.5 Change-Id: I5d1dbac4730238302187d16476dd0c4aea614e13 Reviewed-by: Jan Arve Sæther <[email protected]>
* doc: explain how to pass documentation path to qmllsSami Shalayel2024-12-131-0/+18
| | | | | | | | | | Document how documentation path can be passed to qmlls, via commandline option or via .qmlls.ini files. Pick-to: 6.8 6.9 Change-Id: Ib9cada804688bb63eb628a736c81540ef0f9ec4f Fixes: QTBUG-131953 Reviewed-by: Ulf Hermann <[email protected]>
* doc: explain how to pass import paths to qmllsSami Shalayel2024-12-131-2/+23
| | | | | | | | | | Document how import paths can be passed to qmlls, via commandline option, environment variable or via .qmlls.ini files. Pick-to: 6.8 6.9 Change-Id: I365accfb1062cd08aff7cd5f9b3679aa4c4f7d9f Fixes: QTBUG-130800 Reviewed-by: Ulf Hermann <[email protected]>
* qmlls: wait for exit-notification before shutdownSami Shalayel2024-12-132-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LSP states that qmlls should only shutdown after having received an "exit" notification. Previously to this patch, qmlls would shutdown right after receiving the shutdown request, without waiting to receive an exit notication (that is supposed to be send from the client to the server after the shutdown request). Amends 9aa5abbda76db44b7ead30c221675183285b420c that fixed qmlls not being able to shutdown by making it shutdown correctly. Add a new enum value WaitingForExit to RunStatus that describes the state between receiving a shutdown request and before receiving the exit notification from the client. Use it to make sure that qmlls waits for the exit notification and that qmlls does not read again from stdin after the exit notification was received. Also don't exit qmlls on QLanguageServer::shutdown when the shutdown request gets processed but rather on QLanguageServer::exit when the exit notification has been received. This is required for QTCREATORBUG-31897 to avoid qt creator complaining about qmlls returning 1 when it is restarted, despite qmlls having done a graceful shutdown. Also make the tst_lifecycle code reusable and write tests for the linux/macos case (where the shutdown and the exit notifications are read in two parts) and for the windows case (where sometimes both shutdown and exit are read in the same block from stdin). Pick-to: 6.8 6.9 Task-number: QTCREATORBUG-31897 Change-Id: I0cd663a351027e100469e273b4bb21f47b817a49 Reviewed-by: Ulf Hermann <[email protected]>
* QtQml: Update global namesUlf Hermann2024-12-132-15/+15
| | | | | | | | | These are the actual global names as present in the global object. We should use the same ones everywhere. Change-Id: I4fb42f609b656019db5169fd4ea2b243feab18d6 Reviewed-by: Sami Shalayel <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* doc: link to qmllint warning pageSami Shalayel2024-12-122-1/+5
| | | | | | | | | Add links to the qmllint warning page from the qmlls and qmllint page. Fixes: QTBUG-118054 Pick-to: 6.8 6.9 Change-Id: I9b1ab65b6c1590e42d2063cfb51362697047dee8 Reviewed-by: Ulf Hermann <[email protected]>
* qmllint: add an "error" logging categorySami Shalayel2024-12-123-20/+33
| | | | | | | | | | | | | | Add support for a critical error category in qmllint called "error", so that the qds plugin can show errors for unsupported components for example. Add a test. The error category makes qmllint return -1. Simplify a bit the logic of the "success" bool in lintFile() by making it a LintResult and returning it. Change-Id: Ide6a6a265f1aeede0fcbc35d9e4d0abe3f5c2aa3 Reviewed-by: Fabian Kosmale <[email protected]>
* qmlls: fix go to definition going to build folderSami Shalayel2024-12-121-20/+4
| | | | | | | | | | | | | | | | | | | Amends b1ff6073a7247c921e20cd98b2e3297e7368681b that does not find resource files of QML Modules that are not the main QML Module: use all available .qrc files in the build directory when doing operations like "go to definition". Also search for hidden folders, because .qrc files tend to be nested inside of .qt or .rcc folders. Add a test when going to the defition of a QML file defined in a different module. Pick-to: 6.8 6.9 Fixes: QTCREATORBUG-31881 Fixes: QTBUG-131920 Change-Id: I751e2cd2d1a9867459226e4f884eb1da5c1f9436 Reviewed-by: Fabian Kosmale <[email protected]>
* QmlCompiler: Use correct static_metacall on DefineObjectLiteralUlf Hermann2024-12-121-3/+4
| | | | | | | | | | | When constructing a value type, we cannot just assume that the most-derived type holds all the properties. We may encounter properties from base types. Resolve those via QMetaProperty. Pick-to: 6.9 6.8 Fixes: QTBUG-131980 Change-Id: I8e1773ccb42f86b96457c990ae5bc6486ae1acdc Reviewed-by: Fabian Kosmale <[email protected]>
* Remove a lie from the documentation about property initialization orderJan Arve Sæther2024-12-121-4/+4
| | | | | | | | | | | | | | In most cases, the behavior that was described is not the observed behavior anymore (today, the first MyWidget would normally get the focus). This has been the case since at least 5.15 This is because QML doesn't guarantee which element order it will initialize properties. It has been like this for a long time. Maybe the documentation was written before that. Pick-to: 6.5 6.8 6.9 Change-Id: Ibe4ead198e39e16ac2cfb3b841f4f0697172690a Reviewed-by: Fabian Kosmale <[email protected]>
* Update palette change to the popup content item placed within item viewSanthosh Kumar2024-12-122-2/+9
| | | | | | | | | | | | | | | | | | | | | The popup content item has not been updated with the changed palette in all the cases. For instance, when the popup has been configured as part of the list view, it has not been considered as the child item of the window but the content item and in those cases the change in the   palette has not been updated to the item configured within the popup.   This is because we update the palette of the popup content item only if its child of the window. For other cases, we still set the palette to the popup through (updateChildrenPalette), but the popup doesn't propagate this to the content item. This patch ensures that the popup updates its palette to its content item whenever its palette has been changed. Fixes: QTBUG-128462 Pick-to: 6.9 6.8 6.7 6.5 Change-Id: I4eacb8c8e2b1ae95bb938bc2e72b8a4f48125023 Reviewed-by: Oliver Eftevaag <[email protected]>
* QQuickWindowContainer: Give focus to embedded window on FocusIn eventDoris Verria2024-12-122-0/+18
| | | | | | | | | | | | | | | | | | | When the QQuickWindowContainer gains focus from a tab key event, the focus would remain within the QQuickWindowContainer item and it would be impossible to tab focus from the container item to the embedded window's children or from the parent window to embedded window. This happened because the window and its content item are not children of the window container item, hence not its prev/next in the tab focus chain. To fix, give focus to the embedded window on a focusIn event by calling requestActivate() and make sure to determine the right focus item to give focus to in case the focus reason was from a tab/backtab key event. Fixes: QTBUG-132071 Pick-to: 6.9 Change-Id: I5ea9cacaca7dce85285817978396e7297bc54baf Reviewed-by: Tor Arne Vestbø <[email protected]>
* QQuickTableView: Fix crash when selecting uninitialized TableViewMohammadHossein Qanbari2024-12-122-5/+44
| | | | | | | | | | | | | | | | | | | | This patch addresses an issue where TableView would crash when attempting to select cells without an initialized delegate. The problem occurred because the selection rectangle calculation did not account for empty columns or rows. The fix includes the following changes: - Validate selection rectangle to ensure non-zero width or height. - Check loaded rows/columns before change current index on key event. A new test case is added to verify that selection works correctly when the TableView delegate is not initialized. Some tests are just added to verify no crashes happen. Pick-to: 6.8 6.9 Change-Id: I5060976c721d3625d016f7dc88d94b7277e2d0cb Reviewed-by: Richard Moe Gustavsen <[email protected]> Reviewed-by: Mitch Curtis <[email protected]>
* QtQml: Print property cache creator warnings as categorized logsUlf Hermann2024-12-122-3/+8
| | | | | | | | | | | | | Funneling them back through the type loader and engine is not worth the effort. Those warnings should be rather rare, and we want to delete the code that produces them as soon as possible anyway. Amends commit 36478e252f0c4fff1553a611619aa32d1f79efb5. Pick-to: 6.9 6.8 Task-number: QTBUG-131721 Change-Id: I2d64efd56c7e359f2950097444d2fef0fe5e663d Reviewed-by: Sami Shalayel <[email protected]>
* QtQml: Sort the global, "illegal" namesUlf Hermann2024-12-121-42/+42
| | | | | | | When adding to them, we want to be able to see what we're doing. Change-Id: I563999d8371ff7bd60ca5ad8e7663fd3fe2f4fca Reviewed-by: Sami Shalayel <[email protected]>
* QtQml: Fix some type loader threading issuesUlf Hermann2024-12-128-71/+147
| | | | | | | | | | | | | | | | | | | | | | | | We need to make sure not to concurrently access the "waiting" lists in the type loader and engine threads. In clearCache() we just temporarily shut the type loader thread down so that we can drop all the blobs without locking. In trimCache() we can know that the waitingFor list is empty and therefore the blob to be dropped cannot interfere with other blobs anymore. This requires the status member to follow acquire/release semantics and the operation on the waitingFor list to precede the setting of the status member. We also avoid some nonsensical state changes in order to simplify the logic. Finally, when detecting a cycle, we need to break the cycle before setting the status. To reflect the insights about trimCache and clearCache, acquire the lock when calling trimThread from the engine, but do not acquire the lock for clearCache. Task-number: QTBUG-131721 Change-Id: Ib1cd974e5284f3e7e1f14dca31bddae2ea9de1b9 Reviewed-by: Fabian Kosmale <[email protected]>
* QtQml: Initialize ExecutionEngine members inline where possibleUlf Hermann2024-12-122-25/+18
| | | | | Change-Id: Ie343db2be7d3bdd15e5967f14f810bea03831923 Reviewed-by: Sami Shalayel <[email protected]>
* QtQml: Add missing begin/end namespace to qqmltranslation.cppUlf Hermann2024-12-121-0/+4
| | | | | | | | Amends commit e9dc0ac68134bc6a9cc6522eaca6d893ee10b86d Pick-to: 6.9 6.8 6.5 Change-Id: I4c28e1e6dc6716454f5d973c36960ef360f8fb40 Reviewed-by: Sami Shalayel <[email protected]>
* QtQml: Add some consistency to QV4::RegExpUlf Hermann2024-12-1217-113/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The RegExp JIT should behave the same as the V4 JIT. In particular, it should honor the same JIT call threshold and not second guess any manually set thresholds. To do this we need to store the match count in 32 bits. In turn we can store the 5 flags we may have in 8 bits. To make this safe, pass typed flags to the initialization functions. Also, consider the flags when calculating hash values. Finally, in the init() function, we don't need to initialize members to zero, since that is already guaranteed by the memory manager. And we can delete the flagsAsString() method since it's unused. This requires shuffling some #includes into the places where they actually belong. [ChangeLog][QtQml] The JavaScript regular expression engine now honors QV4_JIT_CALL_THRESHOLD for its own JIT. If QV4_JIT_CALL_THRESHOLD is not set, it uses the JIT after 3 interpreted matches for any regular expression, rather than the previous 5. Matching a regular expression on a string longer than 1024 bytes counts as 3 matches. This is to retain the default behavior of JIT'ing regular expressions right away when encountering long strings. Task-number: QTBUG-131957 Change-Id: I269ccea55d34b191ef18d7cd5fccd4cad8aec7cd Reviewed-by: Sami Shalayel <[email protected]> Reviewed-by: Fabian Kosmale <[email protected]>
* qmlls.ini: quote pathsSami Shalayel2024-12-111-2/+5
| | | | | | | | | | | | | | | Quote paths with (") as the windows list separator (;) actually introduces a comment in a .ini file, making QSettings ignore everything but the first inmport and build paths on windows. Also make sure that any (") in file paths are escaped with a backslash. Adapt tests. Pick-to: 6.8.1 6.8 6.9 Fixes: QTBUG-131296 Change-Id: I2702cb49ce6505008b02ec77304c0dacd2f6ffa5 Reviewed-by: Fabian Kosmale <[email protected]>
* doc: hint qmlls users about possibly invalid qmlls setupSami Shalayel2024-12-111-0/+6
| | | | | | | | | | Document that a failed module import might be caused by a incorrectly setup qmlls, and that QT_QML_GENERATE_QMLLS_INI should be set to ON. Pick-to: 6.8 6.9 Task-number: QTCREATORBUG-31897 Change-Id: Ic72788b18e06d7353def467c4f72593021f955a2 Reviewed-by: Ulf Hermann <[email protected]>
* qmlls: hint to QT_QML_GENERATE_QMLLS_INI on import failuresSami Shalayel2024-12-111-3/+14
| | | | | | | | | | | Append a hint to each "Failed to import" warning message that QT_QML_GENERATE_QMLLS_INI might need to be enabled by the user in CMake. Pick-to: 6.8 6.9 Task-number: QTCREATORBUG-31897 Task-number: QTCREATORBUG-31823 Change-Id: I0a00281bf492ca0298de130d50cb8c3582f03274 Reviewed-by: Ulf Hermann <[email protected]>
* qmlls: put import warnings on the correct lineSami Shalayel2024-12-113-4/+6
| | | | | | | | | | | | | | | | | | In qmllint, the import warnings are printed right after the "warnings occurred while importing" warning despite them having no sourcelocation. This warning gets a default sourcelocation when used in qmlls which points to the first line of the file, so the "Failed to import" warning ends up an the first line of a file, and not on the same line as the "warnings occurred while importing" warning. This is confusing for users. Modify a test to expect that the "Failed to import" warning has a valid sourcelocation, so that it is shown on the correct line in qmlls. Fixes: QTBUG-131958 Pick-to: 6.8 6.9 Change-Id: Ia0c327b82e89cd0a003d05b4c3efe693fb3b3ed7 Reviewed-by: Ulf Hermann <[email protected]>
* qmlls: fix weird formulated warningSami Shalayel2024-12-111-2/+2
| | | | | | | | This warning pops up all the time in the qmlls logs and has weird formulations and a typo. Change-Id: Ib8b40c3dedf0ce73d05a23b4b687817b901b7cc1 Reviewed-by: Fabian Kosmale <[email protected]>
* qmlls: add qt importpaths in .qmlls.ini generationSami Shalayel2024-12-111-0/+5
| | | | | | | | | | | | | | | | Add the Qt default importpaths when generating .qmlls.ini files. This allows to properly support qmlls when using the --bare option when the Qml path obtained by QLibraryInfo is invalid, for example on boot2qt. Amends 74af384dcfea16de572048d24f575582a5f1ce4c that did add the import path passed in CMake via qt_add_qml_module to the .qmlls.ini file. Also fix the indentation in the test, and the weird QString placeholders. Fixes: QTBUG-131365 Pick-to: 6.8 6.9 Change-Id: I762f9e3f810c10e33b719a7dc04d7edbb3eacd5b Reviewed-by: Ulf Hermann <[email protected]>
* DialogsQuickImpl: Implement ColorInputs as a custom controlOliver Eftevaag2024-12-1114-719/+480
| | | | | | | | | | | | | | | | | | ColorInputs might as well be a real custom control, instead of a half-baked one. This also makes the ColorDialog much more responsive when resizing it. If we refactor the module in the future, we'll also likely need each style to be self-contained to one module each. This patch ensures that ColorInputs.qml is no longer shared between all styles. Pick-to: 6.9 Fixes: QTBUG-106246 Task-number: QTBUG-104091 Change-Id: I6c8a687a798f015dce47cc94a10266227899db0f Reviewed-by: Mitch Curtis <[email protected]>
* Store the index mapping for VariantAssociationObject in an ArrayObjectLuca Di Sera2024-12-112-34/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `VariantAssociationObject` is an object in QV4 that is used to convert C++ provening `QVarianMap`/`QVariantHash` objects. As a `ReferenceObject`, `VariantAssociationObject` implements a read/write-back behavior, allowing the original data that an instance of it is produced from to remain synchronized with the instance and viceversa. Furthermore, elements stored in a `VariantAssociationObject` can themselves instantiate a read/write-back relationship to subparts of the `VariantAssociationObject` instance itself. The infrastructure for read/write backs recognizes subparts/properties of an object that needs to be read/wrote-back to based on naked integer indexes. Thus for an association-like entity we have to generally keep track of a mapping from those indexes to a property key to ensure that a read/write-back is performed on the correct element of a `VariantAssociationObject`. Currently, this mapping is stored in an heap allocated `std::vector`, with the heap allocation being required due to triviality constraints on types that are stored in managed memory, as JS-side types are in QV4. To avoid the double indirection that an heap allocated `std::vector` produces, instead allocate on JS managed memory as an `ArrayObject` which should reduce the level of indirection and is expected to provide faster access. Furthermore, previously the mapping was allocated and populated on instance construction. In practice, we only need to map keys that are accessed and from which a derivate `ReferenceObject` providing read/write-back behavior to an instance of a `VariantAssociationObject` can be created. Thus, avoid paying the allocation and population cost on object creation and segregate it to element access, so that is payed on demand when actually required. Change-Id: Ica696f43ef96c95c372ac0e2e1eafd0dc16d2f56 Reviewed-by: Ulf Hermann <[email protected]>
generated by cgit v1.2.3 (git 2.25.1) at 2025-05-31 02:32:21 +0000