Only have one constructor. Get rid of implicit conversion from QString
to Abi -- that seems rather non-obvious. Use Abi::fromString(...) instead.
Change-Id: Ic638d3d4022c465123449089b0679197a5eb445d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... after converting the enum-based parser selection to
a string-based system. The upgrade path has been available
for four major Creator versions.
Introduced by 2ff642d8e4
Change-Id: I0c7ef9794f56d9a1a663cc4bd4a7eeacf3847834
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Add a placeholder text to explain the expected format of predefined
macros.
Change-Id: I2852df6802dba9607466e5488b0225ef08a1e142
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Re-read the data from the toolchain after applying it. This makes it
more obvious what e.g. the macro parser did with the input.
Change-Id: I5518c55c66be84dcdc3b1fa8482e04279768e3eb
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
The documentation says predefined macros for custom toolchains are to
be in "KEY=VALUE" format, while the code got accidentally changed to
only accept "#define KEY VALUE" instead.
Task-number: QTCREATORBUG-19714
Change-Id: I073e5b27f6fd5cead25a6406ae1f7cb19a7a03a7
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
The old code model expected the macros as C++ formatted text
("#define Foo 42) but newer targets like the Clang codemodel expect key
value arguments like "-DFoo=42". So instead of parsing the text again and
again we use an abstract data description.
Task-number: QTCREATORBUG-17915
Change-Id: I0179fd13c48a581e91ee79bba9d42d501c26f19f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
To do that, move the existing enumeration-based system to a
string base. MSVC/Windows and Custom/Unix shared the same
enumeration value (3), so we must provide an operating system
aware upgrade path.
Task-number: QTCREATORBUG-16247
Change-Id: I8beeeabc09119fc501933a7287f2f982195363a2
Reviewed-by: Tobias Hunger <tobias.hunger@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>
Enable creation of toolchains for different languages and wire
up the logic in the ToolChain Options Page.
Change-Id: I9fbd95607d30cc1aa10f73d6532338f07f3e2b4e
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
* Add a pure virtual method to get supportedLanguges with
Change-Id: Ida4445ca045c90fb9f7656a661af83e5b6801b30
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
* Add code to toolchains
* Assert that this is the case in the toolchainmanager
Change-Id: I82452689e83279fd9d1afb3140b0070bef9b6cd8
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Trigger ToolChainManager::toolChainChanged signal when something
changes. This was apparently missing in quite a few places of
some of the tool chains.
Change-Id: Ic94c6559e6267f4ff22dc74cc5b0865fb7aeac63
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There have been several requests on the mailing list or the
bug tracker to support parsing warnings for alien compilers
(sometimes slightly modified GCC).
Instead of natively supporting every compiler, users of less
frequently used compilers should use the custom parser to
parse errors and warnings.
The output channel filter for error and warning parser allows
to scan standard output, standard error or both channels.
Also added tests for twisted capture positions.
Task-number: QTCREATORBUG-11003
Change-Id: I5a5bd6f88cf21cde1c74962225067d4543693678
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Consistently use Utils::FileNameList in favor of QList<Utils::FileName>
Change-Id: Iafbb466c882bfd91c25c9e78f107d401bfdb6d55
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
The name is overly generic, particularly with a pathChanged() signal
also present. Rename to "rawPathChanged", which adequately describes the
semantics.
Change-Id: Ia62b8b0a97a794cb6d5ad6b8ce0abcd36b5f5cdb
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
This is the same as ToolChain::typeId(), so it should have the same
name.
Change-Id: Ifd344825be801aff3dab96bfe924a1984a77bbee
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
This copies over the parser, c++11 flags, etc. that were missed in the
existing implementation.
Change-Id: Icbff37b943bb02bf71cdeb1cf01245d9f6e62688
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
That should take a couple of bytes less to store. Make sure this
change is invisible to the configuration files.
Change-Id: If5e73b52493c9164de9e342021d8153d274b350f
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Mostly done using the following ruby script:
Dir.glob('**/*.cpp').each { |file|
next if file =~ %r{src/shared/qbs|/qmljs/}
s = File.read(file)
s.scan(/^using namespace (.*);$/) {
ns = $1
t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m|
before = $1
char = $2
if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/
m
else
before + char
end
}
if t != s
puts file
File.open(file, 'w').write(t)
end
}
}
Change-Id: I1d05d48b23f44e3d589cc2a790803714786b57d2
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
This adds a "Utils" object to the Js runtime offered by the
JsExpander that adds some useful functions.
Mostly file name mangling and finding preferred extension
from the MIME type database.
Change-Id: I907dae7f295167667ac2ae81461bbff16dc98ef4
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Less typing and less cycles than join(QString) where appropriate
Change-Id: I6ebc0e17e4d7fd9845864dd95b7de4ba4dad6906
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Add Utils::transform and anyOf that take a member function pointer.
Remove bestElementOr it's unused.
Use declval<T> in transform's return type, because msvc does evaluate
T() and for types that don't have simple constructor this fails.
Add std::remove_reference since decltype returns a reference for
lvalues.
Change-Id: I22248b226748eeb27af0d300182d574438d7f756
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Replace boolean "autodetect" by an enumeration with a value
AutoDetectionFromSettings indicating whether the Autodetection
originates from a settings file. Enable the "Remove" button for
those cases.
Currently, there is no way to remove toolchains that were once
autodetected and are no longer present. This happens for example
when working in different MinGW environments, which then
clutter up the toolchain options page and dramatically slow
down the options page opening since gcc is launched to query
the flags, etc.
Change-Id: I731168d8694fe56f60d909f9779f83cffa55fd44
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
