According to QUIP-18 [1], all test files should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I26d72e8de04d4c7c57b3b7838af5d033265de5ba
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The density of Q_FOREACH uses is high here, too high for this author,
unfamiliar with this code, to tackle in a short amount of time. But
they're concentrated in just a few TUs, so pick a different strategy:
Mark the whole module with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too). Created QTBUG-115808 to keep track of
this.
Task-number: QTBUG-115808
Change-Id: I29c377f939e3d747e3ce72c224c4ee722df7a95d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8:
auto QtContainerClass = anyOf(
expr(hasType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))))).bind(o),
expr(hasType(namedDecl(hasAnyName(<classes>)))).bind(o));
makeRule(cxxMemberCallExpr(on(QtContainerClass),
callee(cxxMethodDecl(hasAnyName({"count", "length"),
parameterCountIs(0))))),
changeTo(cat(access(o, cat("size"), "()"))),
cat("use 'size()' instead of 'count()/length()'"))
a.k.a qt-port-to-std-compatible-api with config Scope: 'Container',
with the extended set of container classes recognized.
Change-Id: Idb1f75dfe2323bd1d9e8b4d58d54f1b4b80c7ed7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Previously each test would include and build sources from the shared
folder. Now we make those sources a library, build it once, then have
each test link to it instead.
We also take the opportunity to move some helpers that qtquickcontrols2
had added into the quicktestutils library where it makes sense, and
for the helpers that don't make sense to be there, move them into
quickcontrolstestutils.
We add the libraries to src/ so that they are internal modules built as
part of Qt, rather than tests. That way we can use them in a standalone
test outside of qtdeclarative.
Task-number: QTBUG-95621
Pick-to: 6.2
Change-Id: I0a2ab3976fdbff2e4414df7bdc0808f16453b80a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We want to be able to load modules directly from the resource file
system, no matter if we build statically or dynamically. It's limited by
the need to load plugins, of course, but as most plugins are optional an
application can easily go this way and never include any plain QML files
in an application bundle.
Pick-to: 6.2
Change-Id: I94657a43b47e442722a83e1fb306680aa50b1bc3
Reviewed-by: Maximilian Goldstein <max.goldstein@qt.io>
This allows us to associate different qmldir files for the same module
with one another. Typically there is one qmldir file in the resource
file system and one in the QML import path. We cannot load plugins for
the latter, but usually we have already loaded any plugins we need. Now
we can detect this.
This requires us to construct a proper URI for implicit imports. The
easiest way to do this is to just use the URI from the qmldir if
available.
Modules with versions encoded in their paths and modules with multiple
plugins cannot be resolved by URI only. These continue to be keyed by
path. However, as we do not generate such modules, we will not
automatically get two instances of those, and we won't have to fall back
from one to the other.
Pick-to: 6.2
Change-Id: Ic79add936d263a8e559fd998fca15a6ae160952e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The function does not play well with optional plugins as we don't need
to load those from any specific location. You also don't need this
function. There is exactly one place in qtdeclarative where it is used
and there it just provides a poor replacement for qmldir entries.
[ChangeLog][QtQml][Important Behavior Changes] The internal function
QQmlExtensionPlugin::baseUrl() has been deprecated. You don't need it
if you properly specify your module in the qmldir file.
Change-Id: I131c45e069e9c10744a0ad6126604a2600a6d93d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* warn and assume case unsensitivity if pathconf fails (on FAT32 for
example)
* adjust library name for debug compilation
Change-Id: I2ec45d5da35974b61c6e316738a59f2962532aed
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Was causing an error with the latest qtbase. Switch to
QByteArrayLiteral.
Change-Id: I2370ccca5ac245a7d6678cc6888217d4757f562d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This message adds very little extra value, and it complicates the tests
that check for specific errors.
Change-Id: I58553a8cbc56c3333c8e9815518cca5fa01fdde1
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If a plugin does nothing but load the library that provides the types,
we can skip the plugin loading by linking the library directly. State
that in the qmldir file, and evaluate it when loading the module.
Task-number: QTBUG-84639
Change-Id: I2097237866a50f66c55e4653ad119fe10e18a893
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
We don't need two mechanisms to do essentially the same thing.
QQmlTypeLoader::Blob::addImport() had an "optimization" to never check
for qmldir files of locked imports. This meant the first time you
imported a module with a plugin that locked the module you could use the
qmldir file to load additional .qml files afterwards. The second time
you imported the same thing, you couldn't. As this is not a great
example of consistent behavior, we drop this optimization and always
allow the qmldir files of plugins that lock the module to specify
additional QML files.
As a side effect of this, additional plugins listed in a qmldir file can
also now be loaded after the module has been locked by some other means.
However, any qmlRegisterFooBar() called from the module will be
prevented.
Change-Id: Idabb2bd5f75fc85b62f42625173672b4ae84382e
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
There is no reason why we wouldn't want to find those. Failure to do so
leads to duplicate creation of singleton objects.
Fixes: QTBUG-76514
Change-Id: If2fdfbd933229518136ae0d19474bbaebfbb8cff
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Michael Brasser <michael.brasser@live.com>
- Signedness of integer comparison
- Unused parameters and variables
- Ignored return values of QTest::qWaitForWindowExposed() (nodiscard)
- float to int conversions
Change-Id: Ibece620d3c980a5af3b7717486c841d8072ed8af
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Also added QtQml import for Component.onCompleted.
Change-Id: Ic54a7827c82b8dfd7a1b2f36af4d944bae54bdec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This enables us to drop the QML dependency from a number of tests. This
is desirable because we want to test that we didn't do any incompatible
changes to the debug framework.
Change-Id: I937dd45d3079eac15c200c9d68bb4c911f61afc0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
From now on we prefer nullptr instead of 0 to clarify cases where
we are assigning or testing a pointer rather than a numeric zero.
Also, replaced cases where 0 was passed as Qt::KeyboardModifiers
with Qt::NoModifier (clang-tidy replaced them with nullptr, which
waas wrong, so it was just as well to make the tests more readable
rather than to revert those lines).
Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
During the registerTypes() callback in a QML module plugin we only allow
types to be registered that match the module URI specified in the
qmldir.
We can observe in QtQuickControls 2 that sometimes we need to register
types outside of the namespace of the module itself. QQC2 is in
QtQuick.Controls but the module has internal types that are in
QtQuick.Controls.impl.
Types are intended to be registered once in the virtual registerTypes()
function. However as we don't allow for the registration of .impl to
happen in registerTypes(), QQC2 works around this by registering the
types in initializeEngine(), during which the namespace restriction is
not in place.
This workaround means that every time an application creates a
QQuickView (and thus new QML engine) and loads a QML file that imports
QQC2, we end up calling initializeEngine(), as opposed to
registerTypes() that is called only one single time in the application
process. As a consequence each time this happens we and up calling
qmlRegisterTypes() with the same times and leak memory this way, as
qmlRegisterType*() is supposed to register a new type and return a new
type id that can be passed to qmlUnregisterType.
To solve this this patch lifts the restriction on namespaces for
registered types during registerTypes(). The real world case of QQC2
shows that the restriction is limiting and also easy to work around.
With the restriction lifted QQC2 can now register all types once in
registerTypes() instead.
[ChangeLog][QtQml][Important Behavior Changes] QML module plugins used
to be limited to type registrations in the primary module namespace in
the virtual registerTypes() function. Module authors worked around this
limitation by placing necessary internal type registrations into
initializeEngine() that may cause memory leaks. Therefore this
restriction has been moved and types in any (non-protected) namespaces
can be registered in the registerTypes() function.
Change-Id: I5baf9718a0b0a591f6eb6d7e2dc83e13b204800d
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
When importing modules - in the QML loader thread - with plugins we keep
globally track of the Qt plugins that we have loaded that contain QML
modules, to ensure that we don't call the engine-independent
registerTypes() function on the plugin multiple times. After
registerTypes() we may also call initializeEngine() on the plugin for
the engine-specific initialization, which - as a QQmlEngine is provided
as parameter - must happen in the gui thread. For that we issue a
thread-blocking call that waits until the gui thread has woken up and
processed the event/call.
During that time the global plugin lock is held by that QML loader
thread.
If meanwhile the gui thread instantiates a second QQmlEngine and
attempts to issue a synchronous type compilation (using
QQmlComponent::CompilationMode::PreferSynchronous), then gui thread is
blocking and waiting for its own QML loader thread to complete the type
compilation, which may involve processing an import that requires
loading a plugin. Now this second QML loader thread is blocked by trying
to acquire the global plugin registry lock
(qmlEnginePluginsWithRegisteredTypes()->mutex) in qqmlimports.cpp.
Now the first QML loader thread is blocked because the gui thread is not
processing the call events for the first engine. The gui thread is
blocked waiting for the second QML loader thread, which in turn is stuck
trying to acquire the lock held by the first QML loader thread.
The provided test case triggers this scenario, although through a
slightly different way. It's not possible to wait in the gui thread for
the plugin lock to be held in a loader thread via the registerTypes
callback, as that also acquires the QQmlMetaType lock that will
interfere with the test-case. However the same plugin lock issue appears
when the first QML engine is located in a different thread altogether.
In that case the dispatch to the engine thread /works/, but it won't be
the gui thread but instead the secondary helper thread of the test case
that will sit in our initializeEngine() callback.
This bug was spotted in production customer code with backtraces
pointing into the three locations described above: One QML loader thread
blocking on a call to the gui thread, the gui thread blocking on a
second QML loader thread and that one blocking on acquisition of the
plugin lock held by the first.
Fortunately it is not necessary to hold on to the global plugin lock
when doing the engine specific initialization. That allows the second
QML loader thread to complete its work and finally resume the GUI
thread's event loop.
Change-Id: If757b3fc9b473f42b266427e55d7a1572b937515
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This is particularly useful for keeping the versions of related modules in
sync. For example, when QtQuick.Controls introduces new types or revisions
and bumps up the minor version, qmlRegisterModule() can be used to make the
same version available for QtQuick.Controls.Styles in case it doesn't have
new types or revisions to register.
[ChangeLog][QtQml] Introduced qmlRegisterModule() that can be used to
make a certain module version available, even if no types or revisions
are registered for that version.
Change-Id: I5ec457465cd778bb0adda55771d195f69cd4b31a
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
For example, the QML Engine is now able to locate QtQml.Models 2.x
in both of the following target/installation paths:
- QT_INSTALL_QML/QtQml/Models.2
- QT_INSTALL_QML/QtQml.2/Models
This is required for QtQuick Controls 2. The target path of the module
is QT_INSTALL_QML/QtQuick/Controls.2. The built-in styles are installed
as sub-directories to be able to locate them from the controls module.
Some of the built-in styles provide their own C++ extensions via style-
specific imports (eg. the Material attached property is imported from
QtQuick.Controls.Material 2.0). The problem is that the QML Engine does
not find the module from QT_INSTALL_QML/QtQuick/Controls.2/Material,
but requires it to be installed outside the main controls module ie.
QT_INSTALL_QML/QtQuick/Controls/Material(.2). This makes it a) hard to
locate the styles from the main controls module, and b) conflicts with
the target path of QtQuick Controls 1.
[ChangeLog][QtQml] Made the QML Engine capable of locating QML sub-
modules from within a versioned parent module path. For example,
QtQml.Models 2.x can be either in QT_INSTALL_QML/QtQml/Models.2 or
in QT_INSTALL_QML/QtQml.2/Models.
Change-Id: I2fe4bbdd6d04dd1e80cbe9b3e7e02617658a0756
Task-number: QTBUG-52556
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
From Qt 5.7 -> tools & applications are lisenced under GPL v3 with some
exceptions, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new GPL-EXCEPT header instead of LGPL21 one
(in those files which will be under GPL 3 with exceptions)
Change-Id: I04760a0801837cfc516d1c7c02d4f503f6bb70b6
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
This allows us to do blocking operations that interact with the test
server in the main thread. The threaded server is used in tests that
don't explicitly require asynchronous operation.
Change-Id: Ibcb28e79a1114cb9cfb812e86aae0a1af71c569e
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Use character literals where applicable.
Change-Id: Ib0e618752fbc762a73a0a91c43efab61ef2c9687
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
Replace hard-coded server ports with dynamically allocated ports.
Change-Id: Iab8f9a88343a9f2c49af3cd700c954c13c3bf121
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9
Reviewed-by: Iikka Eklund <iikka.eklund@theqtcompany.com>
This allows QtQuick.Controls 1.x and 2.x imports to co-exist even
if they are two different plugins with the same module directive.
Change-Id: Idee302439e3c2fd6813ba2f41b69144fbae7902c
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Use this to print the error message when listening fails, and switch to always
stack allocating TestHTTPServer instances for easier cleanup.
Change-Id: I63b2bd38963b66611dc08a5c322615d91a91e675
Reviewed-by: John Brooks <john.brooks@dereferenced.net>
Reviewed-by: J-P Nurmi <jpnurmi@digia.com>
Reviewed-by: Lorn Potter <lorn.potter@jollamobile.com>
Include unistd.h for _PC_CASE_SENSITIVE
Change-Id: I0c57d7d84fa4c7379502dbf95fd22476724d5fa3
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
It gives different error message based on the case sensitivity of
the file system on Mac.
Task-number: QTBUG-32652
Change-Id: I52415126e63978c9f80b7652e0116e0e07703fd8
Reviewed-by: Liang Qi <liang.qi@digia.com>
Use the correct identifier for the OS X operating system.
Change-Id: Iff433d312c7c808ddce13466be3db628cf3a9890
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
A C++ analog to the protected qmldir syntax, this is also a potential
performance improvement because we can avoid some file system accesses.
Change-Id: I41781a6cc72aa65bd2d397800345ea16ef442e90
Reviewed-by: Antti Piira <apiira@blackberry.com>
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
Mark incorrectPluginCase() as expected failure on OS X 10.8
Task-number: QTBUG-32652
Change-Id: I8fd2c0ceacabfc74defe84fc6538b268145c5110
Reviewed-by: Simo Fält <simo.falt@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>