We checked the command line from the project manager for "-std=X" and
friends to figure out the language version to use. However, if such a
flag was not provided, we assumed the latest version we support. This
could conflict with the actual version of the compiler and its
predefined macros.
Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the
predefined macros of the toolchain. The MSVC compiler is an exception to
this, as it does not seem to properly set the value - check for
_MSVC_LANG if possible, otherwise simply assume some versions as before.
While at it, add also support for C17/C18 and the upcoming C++2a.
Task-number: QTCREATORBUG-20884
Task-number: QTCREATORBUG-21188
Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
pos was -1 for a value that should have been appended as
last element to the list. Unfortunately, list->insert
treats -1 as prepending in front of the list, which lead
to incorrectly sorted lists.
The function got broken during the review process of
the introducing commit 758544c058.
Change-Id: I693e4d79b0d493deeac0ea8781d637fe50d008b8
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
As a first step of creating a generic base for the 3 existing
implementations.
Change-Id: I2456db74cb635316f97a247e2a2b6bdb34931440
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The possibly intented flexibility e.g. to have different project types
share the same idea of a common context was never used, in all cases
we had a 1:1 relation ship between project ids and ids that were used
as context. This led to oversights like the one fixed in 60fb35a2.
This patch here uses the project id unconditionally as context and
drops all context ids. If we'll ever have the situation where the
original flexibility was needed, Project::projectContext() could be
made virtual and overridden were needed.
Also, the context was never modified for any given project, so the
updating machinery is not needed.
Change-Id: I3f7fac0ed5e4704e126558987c48577f26082dfd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Most other signatures look like {...}RunConfiguration::initialize(Core::Id),
make this here the same, even if the Id is unused (or, rather always
the same) so we can use a virtual function in the base RunConfiguration
at some time.
Change-Id: I5d3d4a7bf856bb0cc31f8e26bc0e5a80fd1a4066
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The idea is to massage the setup in a way to make implementation
of new configurations less error prone by identifying recurring patterns
and sharing repetitive code that tends to be forgotten (see Android cloning).
The former two lines of constructors (owner-and-id, owner-and-source)
are split into a simple, shared, constructor and new setId() and
copyFrom() functions.
The change is mostly mechanical, some multiple calls to fromMap
have been removed, though, some consts added.
Otherwise, to keep the patch small it temporarily introduces two
helper templates in IRunConfigurationFactory. Also, setId() signatures
have not been unified yet. These won't be needed in the final setup.
Change-Id: I8c0734496caae744a9883fe6d92c1d8f8e0234ea
Reviewed-by: hjk <hjk@qt.io>
qmake from Qt4 does not provide C++ standard and
clang can't properly compile Qt4.8.6 and earlier
with c++1z. Behavior in this commit mimics qmake
from Qt5 which also provides c++11 as a default
standard.
Task-number: QTCREATORBUG-16441
Change-Id: I3d29891d6e47f2367f2b3b2bf4be4d86661924e9
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
That should save some memory per node, and since creator has a lot of nodes
(e.g. opening the LLVM project adds about 1 000 000 nodes) this should be
noticeable:-)
Calling update inside ProjectTree::currentNode() and rename it to
findCurrentNode() to make sure it is an still existing pointer.
Also, try to reduce the somehow more expensive currentNode() calls
and sprinkle some const around that usage.
Change-Id: I6a7c5db01a71d53d39544d3013cad557d5b96cdc
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Get rid of duplicated code to do such signaling in derived Project types.
Change-Id: I26914a1d751d72ee65c15a7943e0e7f34978f042
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Unify the handling of displayName with a proper changed signal across
all projects.
Change-Id: I7e503528854b85f6f38de4b0943775f82a0d6123
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Handle the generation of the list of files in a project globally, based
on the project tree.
Creator now has the concept of TreeManagers which can enrich the project
tree with additional data (e.g. the files found in a resource file), which
the project does not necessarily know about. So use that tree to find
the files that belong to a project instead of implementing similar features
in each project.
Change-Id: Ia375a914a1f2c0adaa427f9eda834eec2db07f68
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Marco Benelli <marco.benelli@qt.io>
Remove unused code from project node, access own members
directly, etc.
Change-Id: Icbffb4d3328757ffe3aa756ca1448fefba9bb00a
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Also, rename buildTree() to addNestedNodes(), it's really
adding things, not recompletely (re-)building the subtree.
Use it whenever possible to avoid intermediate lists of items
to insert.
Change-Id: I5fde41e5b164a8a292410bd381a85f5efadf3471
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Create an initial project tree with a ProjectNode and a FileNode for
the project file itself.
Fix the Projects to not implement their own tree before they have
better data.
Change-Id: I147ccd5603d22d1d60880a97f30fd8c271eac88c
Reviewed-by: hjk <hjk@qt.io>
Do not update the existing project tree anymore: Start a fresh one
and throw the old one away.
Change-Id: Ifabe293b6ca668b0672516a6d81acd5346d98fe5
Reviewed-by: hjk <hjk@qt.io>
Can be done generically when creating projects. The only wart is
the use from BaseQmakeProjectWizardDialog::writeUserFile.
Change-Id: Ie98c9f88ec142e82443e204a0075e3ae9e163752
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Do not call makeEmpty() as part of buildTree(). That makes it
impossible to combine buildTree with manual tree setup.
Change-Id: If0a0d9432fe39870917a6ba31594e8dcd6d31868
Reviewed-by: hjk <hjk@qt.io>
Before
commit 8c90998fff
CppTools/ProjectManagers: Reduce ui blocking when loading projects
the displayName was set in the ProjectPartBuilder constructor. Now this
needs to be done explicitly.
Change-Id: I67655a3a5b8052344084e467bb08efd07ab86ab4
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
${AnyProject}::updateCppCodeModel() did two potentially not that cheap
operations in the ui thread:
(1) Querying the MimeDatabase for the mime type for the source files of
the project. In 99.9% of the cases no files need to be read for
this as the file extension will resolve the type. The expensiveness
comes from the sheer number of files that can occur.
(2) Calling compilers with the "(sub)project's compiler command line"
to determine the macros. While the caches avoid redundant calls,
the number of the unique compiler calls makes this still a
ui-freezing experience.
These two operations are moved into a worker thread. For this, the
expensive compiler calls are encapsulated in thread safe lambdas
("runners") in order to keep the "mutexed" data minimal. The original
API calls of the toolchains are implemented in terms of the runners.
While adapting the project managers, remove also the calls to
setProjectLanguage(). These are redundant because all of the project
managers already set a proper value in the constructor. Also, currently
there is no need (client) to report back detection of C sources in
project parts. This also keeps CppProjectUpdater simple.
There is still room for improvement:
* Run the compiler calls in parallel instead of sequence.
* Ensure that the mime type for a file is determined exactly once.
Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We don't need two IDs for C++ and the QmlJS ID should look the same as
as the others.
Change-Id: Ib9747f6b36a90bb652951d85eec69666615670c4
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Now that the generic manager can use data from the target or the build
configuration for expanding entries in its projects files it is
important that it reacts to changes of these entities. A change in the
build configuration can change the include directories or even compile
flags stored in the project configuration and hence the C++ code model
needs to be updated to reflect such changes.
The code is based on the qmake's project manager which has similar
functionality as far as I understood. The only difference is that the
generic manager won't attempt to refresh its state in the background (as
it simply can't do that right now) so the ui will be blocked for a bit.
Change-Id: I0a85e1ff0deeb876a7934b9a193a5d0f020047c7
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This adds the ability to use macro's provided by various parts of
QtCreator inside the .includes or .files file. In particular the build
directory of the current build configuration or Qt variables of the
current kit (accessible through the active target's macro expander) can
be useful but I suspect its possible to find other use-cases as well.
Fall back to the project's own macro expander if there's no active
build target to allow this to happen some day, even if that expander does
not have many useful variables.
Change-Id: Ic3b7b744b5d0ae24247ad929b73d7c72abfb8bb3
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This missing project files(*.files, *.includes, *.config) in "Project"
tree is a regression.
Change-Id: Ib7380b1627a0f31045a25bc152352f5d2c82342a
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
toAdd is a QSet, so insert does nothing if directory is already
in the set.
Change-Id: Ic7d593414bef95a84f624c39208e29b0ec8c01f1
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
* Use nullptr instead 0
* Remove QLatin1{String|Char} where possible
* Use C++11 list init and auto
* Add some const as drive-by-change
Change-Id: Ife4c9c7b0869bcf2c864b88b8061ac6b7c3f33c0
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
The generic manager looked up entries from the .includes and .files
configuration files in the process (i.e. QtCreators) environment. In
particular for the .includes file this is a problem, since it makes it
impossible to use environment variables specific to a particular build
environment.
In my case I'd like to access the QTDIR variable added by QtCreator to the
build environment to provide the generic manager with the Qt include
directories. Of course this is different when working with two kits that
have different Qt versions associated and hence its not possible to
hardcode a particular path in the .includes file.
This will break existing files that use the generic-manager-specific
syntax for environment variables ($$(VARNAME)) as the BuildEnvironment
uses the platform's native way to refer to such variables.
Change-Id: I1a684db82fdbfd163b6a215f9591c8e4bb57b25c
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
No need to require the project managers to do this. Also, it is easy to
forget.
Change-Id: I96f7a5e5547418678af9653e5753c372f0880e5a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use class enum to shorten the FileType to quint16. This frees up a couple
of bytes per FileNode and we can have many of those.
Change-Id: I3a9ae25059690fefa15305a4268269647d6dc1c9
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We relied on the CppModelManager to tell us whether a project was reparsed
after a kit change. While this worked, it was not guaranteed that the project
is really finished (and ready for e.g. building) after pushing new ProjectInfos
to the CppModelManager.
Rely on the projects telling when they are finished with parsing. This is more
accurate and future-proof.
The introduced signals in Project and SessionManager are (at the moment)
only for tests.
Change-Id: I1b368ec4585ffa8755eb28fac6d187cce31243ee
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
