qt/qtdeclarative.git/tests, branch wip/figmastyle

Merge remote-tracking branch 'origin/dev' into figmastyle

2024-09-16T15:15:26+00:00

Change-Id: I35b7b9edd6c68dcf0ba757e6da0c955c8d9d9f39

QtQml: Re-use memory-cached compilation units across engines

2024-09-11T13:11:32+00:00

Since we've eliminated all engine-specific data from these compilation
units, we can now do so without fearing crosstalk between the engines.
By not re-compiling the CUs we also do not create duplicate property
caches which can otherwise show up in inconvenient places and make
otherwise equal types mismatch.

Pick-to: 6.8
Fixes: QTBUG-128789
Change-Id: Ia8a6fefb9a1455f6139265aa3708036adea902f6
Reviewed-by: Fabian Kosmale

Android: Update QML in Android service test to use multiple views

2024-09-11T13:11:31+00:00

Adds a second QML view and modify the Android UI to provide controls for
the second QML view.

Modifies service QML loading code to load the second QML view in a second
QtQuickView, and link controls together.

Modifies QML views to fit content on half a screen, by removing
unneeded text.

Task-number: QTBUG-128552
Change-Id: I10f2897ba2fa8b2bd29fbca28e63df08d290a201
Reviewed-by: Assam Boudjelthia

QtQml: Never clear all executable CUs from the QQmlEngine

2024-09-10T21:11:53+00:00

Since the executable CUs are used as entry points for marking by the GC,
dropping them from QQmlEngine means their strings, lookups, regexes etc
won't get marked anymore. If, however, the CUs are still referenced
elsewhere, their inner objects will still get used, despite having
potentially been swept by the GC.

Also fix the documentation of clearComponentCache() to clarify that it
does in fact not clear all components.

Pick-to: 6.8
Fixes: QTBUG-128638
Fixes: QTBUG-128782
Change-Id: I96480914733c399c18778202ae8dca7e332c3a85
Reviewed-by: Fabian Kosmale

Tests: Fix various CMake warnings

2024-09-10T13:51:06+00:00

Add NO_GENERATE_EXTRA_QMLDIRS where applicable, make output directories
and module URIs match, and avoid setting QTP0004 to OLD since that just
generates a different warning. Also, explicitly include some .js files
in the qmldir, even if that means re-evaluation on each import.

Pick-to: 6.8
Change-Id: Ia03445ed7df85aa4d2032ba51675bab7501ad55b
Reviewed-by: Fabian Kosmale

Android: Replace Qt snapshot maven, with release maven repo

2024-09-10T13:18:55+00:00

This change replaces the 0.1 SNAPSHOT versions with
1.+ version which means 1.0 and above.

We should also remove Qt maven repository URL so the
plugin can be fetched from mavenCentral.

Task-number: QTBUG-128417
Pick-to: 6.8
Change-Id: Id1006b64f6bf3f0d13d03a4f26b441236aa77cc7
Reviewed-by: Assam Boudjelthia 
Reviewed-by: Rami Potinkara

qmlls: use .qml from source folders

2024-09-10T10:01:36+00:00

Previously, qmlls (like all the other tooling) was only working on the
build folder for imports. This leads to bugs like QTBUG-127661 where
go-to-definition jumps to the build folder qml file.

This commit changes the Dom to use a "best of both worlds" approach:
import .qml files from the source folder but load the rest (qmldir,
qmltypes, ...) from the build folder.

Add a flag to QQmlJSImporter that enables the build-folder-path-to-
source mapping, and use it in the DomEnvironment::SemanticAnalysis's
importer.

In the qqmldomastcreator, load the implicit import directory from the
build folder instead of the source folder, and explicitly load qmldirs
of that implicitly imported directory to make the implicit directory
import actually do something.

In DomEnvironment, map files from the build folders (for example loaded
via a qmldir from a build folder) to their source folders before loading
them..

Finally add a test to make sure that go-to-definition jumps to the
source folder instead of the build folder qml file.

Pick-to: 6.8 6.7
Fixes: QTBUG-127661
Change-Id: I764826a7d3c98d2e34e5af8e3ba6dea1526c593c
Reviewed-by: Ulf Hermann

add util to map .qml from source to build folder

2024-09-10T10:01:33+00:00

Add a helper method qmlSourcePathFromBuildPath in the QQmlJSUtils static
class that maps QML files from the build folder to their source folder,
and vice-versa.

Uses a heuristic for QML modules that do not use "prefer" qmldirs for
each folder that contains QML files.

It will be used in a later commit to translate build folder paths,
encountered during "go to definiton" in qmlls, to source folder paths.

Pick-to: 6.8 6.7
Task-number: QTBUG-127661
Change-Id: I81f4b75a008d773835affb622af7f964b753e5ac
Reviewed-by: Semih Yavuz

qmlls: find and use resource files from .qt/rcc

2024-09-10T10:01:28+00:00

Search for resource files in .qt/rcc instead of only looking in
the .rcc folder, and update the resource file mapper in
setLoadPaths to actually use the resource files.

Amends d0fcb75aab1b5a91260fb378d761257e1f2e4787 to:
 a) work on more sophisticated project structures with
    "prefer"-directives
 b) use resource files for all qmlls modules (previously only the
    linting module was using resource files)

Also move the methods to find .qrc files into qqmljsutils_p.h and add a
new test file.

This patch fixes the spurious warning about SettingsData being not found
and the missing completion suggestion for the SettingsData type in
qml/popups/AdminDialog.qml on Ekke's project attached at QTBUG-126504.
The build folder structure was mimicked in sophisticatedBuildFolder for
the test.

Also change DomEnvironment::semanticAnalysis() to return a value instead
of a reference, and rename SemanticAnalysis::setLoadPaths to
SemanticAnalysis::updateLoadPaths because it will set the loadpaths on
all copies of semanticAnalysis instead of just setting it on the current
one.

Pick-to: 6.8 6.7
Task-number: QTBUG-127661
Task-number: QTBUG-126680
Change-Id: I47299711ced6cb952c4d3c1893495cb17a8eec7f
Reviewed-by: Ulf Hermann

Fix gc interaction when reparenting items

2024-09-10T08:30:44+00:00

QQuickItem has sspecial integration code with the garbage collector, to
ensure that an item which is in the (item) parent hierarchy will not get
collected. However, that breaks down with incremental gc in one specific
corner case:
1. We have an item A which already got fully marked (its custom
   markObjects has already run). The phase in which we mark all object
   wrappers has however not ended yet.
2. We have another item B with child item C, and both of their wrappers
   are not marked yet.
3. The itme parent of C changes from B to A.
4. The gc resumes, but won't ever reach C, because it is only reachable
   from A, which already had been visited.

Note that there is an issue in loadFromModule not correctly setting up
the context, which requires a workaround in the test.

Pick-to: 6.8
Change-Id: Id8d14cd1ea96161d2864f49b43a9369b2f363396
Reviewed-by: Ulf Hermann