Added support for resolving case:
enum E
{
val1,
val2 = val1, // val2-4 are not resolved
val3,
val4
};
Task-number: QTCREATORBUG-13932
Change-Id: I122c5eb0b0397d6c02bc3db0a5c1ea1c28c5c6e7
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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: I492792bb9e5655c55795e938031efc557c9a462f
Reviewed-by: Thomas Hartmann <Thomas.Hartmann@digia.com>
1. Extends lexer so digit or string can be followed by underscore '_' and
alphanumeric defining literal.
2. Extends parser so it accepts operator"" _abc(...) user-defined literal
definition.
3. Adds Token::Flags.userDefinedLiteral bool flag field representing if token
carries user-defined literal.
4. Adds C++11 auto tests case with: 12_km, 0.5_Pa, 'c'_X, "abd"_L, u"xyz"_M
5. All optional suffix scanning methods now return boolean if the suffix was
found.
6. Adds C++ Lexer tests for user-defined literals with C++11 feature enabled.
This change however does not make QtCreator understand user-defined literal
semantics, e.g. properly resolve type when applying custom literal operator.
Change-Id: I30e62f025ec9fb11c39261985ea4d772b1a80949
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Dysfuncional for a while and mostly replaced by tst_dumper.
Change-Id: I8266f2a680be23bd37d29233b91ce5a9a151163b
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
...in order to stop memory intensive parsing for invalid code.
Parsing the test data/snippet "hard" led to a memory consumption of
about 5.5MB and this could easily get up to hundreds/gigabytes by adding
some more "if_<bool_<true>,\n" lines. With the caching, we are at about
1.0MB, even if more lines are added.
The "memory consumption" was measured with valgrind-massif. The stated
numbers are the reported peaks.
Task-number: QTCREATORBUG-12890
Change-Id: Ie7eb00cfc7915552d29bb27410a6b13a486f486e
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
This reverts the changes
commit beac7b9539
C++: Fix highlighting after "invalid code"
commit 78ab287fc6
C++: Stop parsing a declaration after two tries
which were a work around for QTCREATORBUG-12890.
A follow-up patch provides a proper fix.
Task-number: QTCREATORBUG-12890
Change-Id: I2650a8e41c8ff1180cad9f069e463fc51bd2f1b1
Reviewed-by: Erik Verbruggen <erik.verbruggen@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: I919da493d0629b719d328e5e71c96a29d230dfd1
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: hjk <hjk@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: I6fbe13ddc1485efe95c3156097bf41d90c0febac
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@theqtcompany.com>
Instead of starting LLDB through a Python script this now starts
LLDB directly. This did not work a while ago but seems fine nowaday.
Change-Id: I20e915070cd6addf260817c311f4160d010aa861
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
Also, in contrast to the 5 previous times this piece of code has been
broken and fixed, this time add an elaborate comment about the problem
and a test case to check for future regressions.
Change-Id: I2babf7c6e98d7ab12ee53362229f30f6d9e5d7d5
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Write the full command to a temporary file for easier re-use.
Un-ignore the first stop, this does not seem to be needed in
the new async setup.
In some cases LLDB is not able to extract the even the top most
frame of the stopped thread (happened 2 out of 100 runs of the
QDateTime dumper). It's unclear why. For now just report the fact.
Change-Id: I76a63bc288f1ae6f5bd9b9604a47f051912b93d7
Reviewed-by: hjk <hjk@theqtcompany.com>
For plugins that don't live in the main repo.
Change-Id: Iebe4b05bfb60f86531ec82a4ae555fdfaac39ead
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
cca10304 made dumper detection lazier, the bbsetup needs now to
be trigger separately.
Change-Id: I7f78c5e4b3a6981dbd1c292654a48eac0b5b58e7
Reviewed-by: hjk <hjk@theqtcompany.com>
In the struct _Wrap_alloc (see test code) the rebind struct has
_Wrap_alloc as parent. However, within rebind the typedef of type
_Wrap_alloc has rebind as parent.
We will refactor that in master by introducing a "parent iterator"
class checking for cycles, so the client code looks less noisy.
Task-number: QTCREATORBUG-13703
Change-Id: I7b6cf819ea869139d2403e15ba085d8fba19763e
Reviewed-by: Cristian Adam <cristian.adam@gmail.com>
Reviewed-by: Przemyslaw Gorszkowski <pgorszkowski@gmail.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
Clang 3.5 runs out of memory when trying to optimize
tst_Dumpers::dumper_data. So don't optimize.
This is a backport of 58c694577f.
Change-Id: Ia81aa6e491e132ee04bb51e9d443e836b5a7635a
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Clang 3.5 runs out of memory when trying to optimize
tst_Dumpers::dumper_data. So don't optimize.
Change-Id: Ic81aa6e491e132ee04bb51e9d443e836b5a7635a
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>