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>
Qt Creator extracts file names from the output of external processes in
various places, for instance from compilers during the build. It often
happens that such file names are not absolute, so they cannot be
directly opened in an editor when the user clicks on their
representation in some widget. That's why they are processed by the
FileInProjectFinder facility first.
This patch enhances the FileInProjectFinder to be able to return more
than one candidate for a relative file path, and allows the user to
choose between these candidates where possible. This way, we won't open
a random file anymore when a project contains more than one file with
the same name.
Fixes: QTCREATORBUG-13623
Change-Id: Id19c9eace3e6b3dbde89f6528e6d02b55872d747
Reviewed-by: hjk <hjk@qt.io>
The comment above FileInProjectFinder::findFile() states:
"If all fails, it returns the original path from the file URL."
So if nothing was found in the resource, fall back to this
strategy.
Broken by 55b0cc7814
Fixes: QTCREATORBUG-22044
Change-Id: I09e18aebc6727720d45775ec56f55f9f16d43f86
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Parse the project's qrc files to map a qrc URL to the actual file in the
project, rather than employing a heuristic.
Fixes: QTCREATORBUG-20207
Change-Id: I4fc9e11c20a36e9d477bb3dc43a787d81e067886
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The comment above this function says:
If all fails, it returns the original path
from the file URL.
That broke with 7b0b4c92cd, which caused the auto
tests in QtSupportPlugin::testQtOutputFormatter
to fail.
Fixes: QTCREATORBUG-21792
Change-Id: I9ed66c86e7a165fe198ee3fcf1bf8b72d850a2d5
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Ulf Hermann <ulf.hermann@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>
We want to know how exact the match is, so that we can reject results
that don't fit our needs. We cannot pass an extra fuzzy/exact parameter
to findFileOrDirectory, because we cache the results, and we need to be
able to reuse results obtained from different searches.
Task-number: QTCREATORBUG-21107
Change-Id: I870100f4c0acd0e9b007f076543340b34a25a447
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Some compilers need to know that the destructor is not inline here. It
cannot be inline because PathMappingNode's dtor is not exported.
Change-Id: I37cbf31cf83a8aa571a0a6708e3ad520b035bc53
Reviewed-by: Alexander Shevchenko <sav_ix@ukr.net>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The deployment data is the most reliable information we can get
regarding where a file from the host ended up on the target. Therefore
it is searched first. Since the "directories" found this way may not
actually exist on the host, we return the list of entries rather than
the actual path for those. Files from different host directories can be
deployed to the same target directory, after all. Using the list of
entries, a client can reconstruct children of the directory by appending
an entry to the base path and searching again.
Change-Id: Ia0f72872a4ff6313f1ae8b0f441b67f55be5a456
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
As we add things to the cache, also without a project directory, there
is no reason why we wouldn't use the cache when looking them up.
Change-Id: I9f90cf7b88410513d2ebd0524e7d369fcb4db704
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
cdUp does check for an existing file which is slow
especially at Windows.
Benchmarking this with a project with around 100
files improved time usage inside that method from
6 seconds to 300 ms.
There is still room for improvement because of parentDir
calls cleanPath which is also not that fast.
Change-Id: I57adae1f1f0a82ac702b461758e9d1b89760087b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This simplifies code and reduces the number of conversions between
QString and Utils::FileName.
Change-Id: I47bd86b9ae09b1da37b4e5e604761367ac1ab26b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
- Check the cache first, also for absolute paths in the project
directory. Those paths are not guaranteed to exist and we may have
found the file somewhere else before.
- Cache everything we find and remove entries from the cache if they
have become invalid.
- When finding files in the project directory by absolute path, check if
they exist before indicating success.
- Unify the checking and success handling.
- Pass QString by reference where applicable.
- Avoid double lookups in the cache.
Change-Id: I28e5a2979e0c78e84f42115a64acbd4eb06ffb0c
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This can be used e.g. by profilers that need to match some
on-device path to a local path.
Change-Id: I38e572bfbd7848cfb2e8ba9e275b99bb09692fea
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
Consider having files with the same name in different subdirectories of
your project. The FileInProjectFinder will now choose the best matching
file path, which is the one that has the longest right-aligned common
substring with the path to find.
For the candidates
["/home/jim/MyProject/Resources/qml/1/foo.qml",
"/home/jim/MyProject/Resources/qml/2/foo.qml"]
and the file path to find being "/SomeWhere/Else/qml/2/foo.qml" the
ranks are 8 and 10. Therefore, the second path is chosen.
Task-number: QTCREATORBUG-12908
Change-Id: I6225fd1dce8cc79a90d02ae0a54cdf80f75f45af
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
Only methods as programming functions are affected. Besides renaming
some actions like "Switch Between Function Declaration/Definition" this
mostly touches (api) code comments.
This is a follow-up patch to commit 872bfb7.
Change-Id: Icb65e8d73b59a022f8885b14df497169543a3b92
Reviewed-by: hjk <hjk121@nokiamail.com>
Use \a for all attributes in function descriptions
to avoid QDoc errors. Do not use \param, because
it is not a valid QDoc command.
Do not use \returns as it does not exist.
Do not use \brief for functions. It is not obligatory, so
rather than add them for all functions, let's consistenly leave them out.
Fix typos, grammar and style issues, and punctuation.
Change-Id: Ib8f296f93976265bb93dbeab40c5b47156518122
Reviewed-by: hjk <hjk121@nokiamail.com>
QDoc does some magic with the \class and \namespaces
and \brief commands, so the following wording must be used:
"The xxx class yyy ..."
Change-Id: Id231f30e8464898b776888d5423523de404aae34
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
The \i and \o commands were replaced with \li and
\bold was replaced with \b in QDoc for Qt 5.
The \input command was replaced with \include in the docs.
Change-Id: I257d1bebb8ebc739ca20e0d29fcf0406ecb14534
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Qt Creator's support for Symbian was at its peak in version
2.4.x. Nobody really verified it in Qt Creator 2.5 or 2.6.
It is most likely rotten. Let's remove it!
Also, the Symbian support code was spread throughout the whole
Qt Creator code base. The plugin interfaces evolved in the
meantime and target platforms like Android or QNX have 99% of
their code in separate plugins.
In case anyone wants to revive Symbian support in Qt Creator,
please create a plugin for it.
Change-Id: I56a758a3e2fd5b8c64d9aeb8f63d8e916c4883be
Reviewed-by: Alessandro Portale <alessandro.portale@nokia.com>
This also allows simple setting of breakpoints on failed asserts.
Change-Id: I6dd84cbfaf659d57e39f3447386cebc0221b2b84
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Getting the #include directives ready for Qt5. This includes the
new-project wizards.
Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
