cmake creates a consistent uri structure in the build directory.
We use that as import path, but when we find a type in them we should
refer back to the original file, as editing those is dangerous because
any edit are lost with the next build.
To find the original file we use the qrc, as the qrc path is mostly
the same of as the uri path.
It is possible to add prefixes which would make an exact match fail,
so we compare the paths from the right to the left and find the
longest match.
To acheive this:
* QrcParser keeps a reversedResources, so the match from right can be
done efficiently, and provides a longestReverseMatches method
* the model manager keeps a list of all common prefixes of the
application paths (build directories), and identify all files in
build directories
* the method fileToSource identifies the files in the build directory
and tries to find the corresponding source file, warning if he
cannot find it
* fileToSource is used for follow Symbol and find usages
We could use fileToSource much more aggressively, to use to in editor
content for the files in the build directory, increasing the
consistency, but that is a more dangerous change for later.
Fixes: QTCREATORBUG-27173
Change-Id: Iea61b9825e5f6e433a7390cf2de9564b792458a5
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
We don't have a PluginManager instance when running the autotests.
Change-Id: Ib36ea2bb58e500a2ad4b601cedfb8d426fda7e4e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
We need to search application directories as well since the new
QML Module API will generate modules there.
Task-number: QTCREATORBUG-24987
Change-Id: Ie67233ffece692c62921db13c49ae8cc2184422f
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
* Implicit conversion of size_t to int
* Comparing bool with operator >
Change-Id: I4bc5bef57bfa0125b1c82953a7a2cfc24066bc8c
Reviewed-by: hjk <hjk@qt.io>
If we keep the copy of the snapshot around while it's being modified, we
trigger the copy-on-write mechanism. That is expensive, and destroying
the snapshot afterwards is also expensive.
Task-number: QTCREATORBUG-25899
Change-Id: I9b7e26baf63a4b47c85457e5657fee971a6ce132
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
this is needed (among other things) for
* null coalescing
* shebang support
Change-Id: I1b37fd86593f143de8b39c0daf433831a8785568
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Currently, in d'tor of ModelManagerInterface, when joinAllThreads()
has finished, we were setting the g_instance to nullptr. However,
just after the joinAllThreads() has finished and before setting
the g_instance to nullptr some other thread could still add a
new future and this thread could potentially still assume that
instance() will return valid pointer.
The fix is to make joinAllThreads() and setting the g_instance to
nullptr in an atomic way. We ensure, that when there are still
pending futures, we don't clear the instance, but call joinAllThreads()
again for them.
The implementation is similar to what we do in test_joinAllThreads().
Change-Id: I99dc341228aee710a958a0fbc6c5ec1fbe132e7f
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Add ModelManagerInterface *ModelManagerInterface::instanceForFuture()
method. If the returned instance is not null, it's guaranteed
that it will be valid at least as long as the passed QFuture object
isn't finished.
Use instanceForFuture() in Link c'tor, as it's called from
non-gui thread.
Change-Id: I7e5ee6ad27e8f71cc0cef7fd9a91b710e2f8f662
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Synchronize all the running futures on shutdown. It's enough
that all threads started by runAsync() just finish, without the
need for delivering the results of these futures to onFinished
handlers.
Fixes: QTCREATORBUG-25350
Change-Id: Iac5ae3834bb02ef0a77b063c59097471ec7e757d
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
The idea in this approach is that we only collect those futures,
which have resulted from runAsync. The assumption is that
all tasks associated with those futures may sooner or
later finish, without the need to call qApp->processEvents().
OTOH, we don't collect fake futures coming from Utils::onFinished,
as these requires the spinning event loop in order to deliver
the onFinished signal.
So, the new joinAllThreads() method waits for all collected
futures to finish. We also _do_ want canceled and not finished
futures to finish, since even when they are canceled,
they may still be running and using the internals
of possibly destructed ModelManager. This means, we are only
waiting for other threads to be finished, without reporting
their results to e.g. onFinished() handlers.
Some tests require that all onFinished handlers are also processed.
In order to achieve this, we create a loop inside
tst_joinAllThreads() method and we call joinAllThreads(), so
it will wait for all pending queue to finish, and then we call process
events, in order to let finished futures propagate their results
to their respective onFinished() handlers.
Some handlers may have stared another threads when being processed,
so we may expect that some new futures will appear.
So, after processing the events we check if any new events
appeared, and in this case we repeat the loop.
Otherwise, we finish synchronization.
Amends: 96c860159b
Task-number: QTCREATORBUG-25350
Change-Id: I5e44150c55f6be00445a5695938482d948990c94
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
QUL uses module mapping for theming of QtQuick.Controls: during
code-generation the compiler is pointed to the Controls implementation
it should use. This is done by rewriting any import of QtQuick.Controls
with the given module name. The CMake build scripts will write a file
for each target to the directory "qml_module_mappings" in the build dir,
and those files will contain the mappings used.
Fixes: QTCREATORBUG-25356
Change-Id: I3f74897836dde7717b03bd6dffa46dcc0689ffdd
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
The defaultProjectInfo in the model manager is used as fallback for
cases where no applicable ProjectInfo is found. There were a couple of
places where this should have been used, but wasn't. This showed when
adding a autotest that only used a defaultProjectInfo with no projects
defined.
Change-Id: If446212dbbdff02fbf1f220d401405d5f99d2de6
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
It is possible to import components of different paths to fill
a module.
Take further paths into account when looking up types.
Fixes: QTCREATORBUG-24405
Change-Id: I8d6bf0a324ea9c0d1fe9d91b40857f91f00dd662
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
We do it wherever possible. Some places can't be fixed
since they still rely on dynamic introspection
(mainly QQuickItem cases).
Change-Id: Ia00b4a04d8b995c9a43b7bf2dbe76a60364bb8ca
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The QML import paths weren't scanned for modules when the code model was
reset.
Task-number: QTCREATORBUG-24082
Change-Id: If818ebf4ef123529e5fe8de40e6b5d0154c84680
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Added ModelManagerInterface::projectVContext() method to return just
the context of the project the file belongs to and nothing more.
To make this possible, fixed caching the file-to-project relationships
and removed automatically adding the currently active project to
list of projects the file belongs to in allProjectInfos().
Task-number: QDS-1495
Change-Id: I949c0202d0280264b6856562a2e7abc2f93d13c0
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Previously a single QML import path would not be scanned. This did not
usually happen to users, as there's almost always more than one path.
But it could lead to unexpected behavior in tests that explicitly
controled import paths.
Change-Id: I015f44f183ad484c333ab7a4e5e98b87098620a7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Tests often want to wait for all async tasks to finish before
progressing.
Change-Id: I61738df730ca341b5c9d227569d961cd1991b296
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Philip Van Hoof <philip@codeminded.be>
The condition was always false, since projectInfoForPath always returns
an empty project member. This meant the the fallback builtins that ship
with Qt Creator were used, instead of the builtins that shipped with the
Qt version.
Change-Id: I9c3bf949d0046bcf687c913e32ddac95734f6c43
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
app.qmltypes is being added as a new convention to Qt 5.15. These files
are to be found next to application binaries, and contain the QML types
those application register themselves, in contrast to QML types
registered from plugins loaded via the regular import mechanism.
lib.qmltypes works the same way, in principle, for libraries. This
change only adds it to the possible names for qmltypes files, though.
Change-Id: I1d7c5835c8c3e988d214c5cdb949ca677b48dfc5
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The special ctor wasn't used anywhere, the default ctor can be replaced
by inline initialization, maybeAddPath is only meaningful in the model
manager and the language compatibility check should definitely not
pretend to be a general rule either.
Change-Id: I11cf25fe1c696550d33b56ce57316100321d564b
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
The reasoning in 1b4766e26c did not take into account that the scope
of QT_NO_JAVA_STYLE_ITERATORS may change over time, as done with
f70905448f6 in Qt base.
Change-Id: Ib1966ff26c4d36d5f62e149d6b45baa4aecf825d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We'd like to make use of it in a more general context, and it's not
directly related to QML.
Change-Id: I025ec67829f85544667684cdb8c99d1ee4c18197
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
QT_INSTALL_IMPORTS and the used ProjectInfo.qtImportsPath variable
were only used for QtQuick1.
Change-Id: I34da0cfc77effa84f3a7578e7f91fed0768a9bf4
Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This patch removes all references to QtQuick1 in qml library,
plugin, designer, profiler and tests.
Change-Id: Ie286fad96060299caae3ef328330597cf53e90d3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This rids us of the "Issues" about various wizard files when opening
qtcreator.pro
Change-Id: Ib49e87ded791bcc9155e65a77cac523c1f67de56
Reviewed-by: Marco Benelli <marco.benelli@qt.io>
