d2737bdedb
We want to be able to construct a meaningful list type by surrounding the internal name of the type with QList<>. Usually this works because of the way we auto-register sequential containers for types. Only for the builtins we need to do some special casing. That special casing should happen in the builtins, not in QtQml, though. The generic QList<foo> sequence type is implicitly given for any value type foo these days. There is no need to mention it in .qmltypes. QtQml retains some extra container declarations that are not straight QList<foo> for a value type foo. Everything that's registered by the value type registration anyway is dropped. We keep the aliases QStringList and QVariantList in the builtins because they are really common. Since we now register QVariantList the way it's mandated by the builtins, we also have to handle it correctly in qv4sequenceobject.cpp. In particular, we need to append variants as-is rather than poking into them. As QStringList is an additional builtin now, we need to teach the type resolver about it. Change-Id: I0dfb5b780b27250f36f6886bc4e0926a03c114b4 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> |
||
|---|---|---|
| .. | ||
| script/com | ||
| translations | ||
| CMakeLists.txt | ||
| dummy_imports.qml | ||
| exporterror1.mjs | ||
| idtranslatable-unicode.js | ||
| idtranslatable.js | ||
| importerror1.mjs | ||
| modulewithlexicals.mjs | ||
| testmodule.mjs | ||
| testregister.mjs | ||
| testregister2.mjs | ||
| testregister3.mjs | ||
| translatable-unicode.js | ||
| translatable.js | ||
| translatable2.js | ||
| tst_qjsengine.cpp | ||