Until now std::vector::at() was used to access the elements. This is
handy for debugging since an exception is thrown for invalid indices,
but it does not stop Qt Creator from crashing because exceptions are not
caught.
This is especially a problem for the parser, which has to look ahead via
LA(n), which accesses TranslationUnit::_tokens.
With this patch, explicit bounds checking is done before accessing the
elements and thus calls to
std::vector::at() // bounds checking, throwing out_of_range
were replaced by calls to
std::vector::operator[]() // no bounds checking, not throwing out_of_range
Measuring the parse time for the Qt Creator project shows that there is
no slowdown. In both cases, with and without the patch, about 15s are
needed on the authors machine.
Task-number: QTCREATORBUG-10453
Change-Id: I32b12a526ff7199bcadfc21a3deb5354063a3e3b
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
MEMBER was added in Qt5.
Task-number: QTCREATORBUG-10068
Change-Id: Ic6c15a0e5ee8981ab98e4c12fc1521dc281b731f
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
...otherwise they add up and subsequent tests checking for the error count will
fail:
FAIL! : tst_AST::objc_try_statement_1() Compared values are not the same
Actual (diag.errorCount): 5
Expected (0): 0
Loc: [/home/nikolai/dev/creator/qtcreator-master/tests/auto/cplusplus/ast/tst_ast.cpp(1400)]
...
Change-Id: I8b4356331e95dceb1e99bb26e6ebf4591d70a08c
Reviewed-by: David Schulz <david.schulz@digia.com>
No semantic analysis yet, but this prevents the parser from generating
bogus diagnostics.
Task-number: QTCREATORBUG-9309
Change-Id: I2ec575a8474cd51bfa97b17678d3da71ab8dcd7a
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
This test is marked as failing, because the bug is still there. To be
fixed when we re-use the generated token stream of the preprocessor as
input for the parser.
Task-number: QTCREATORBUG-9799
Change-Id: I454a9939aa188a6ff934a11699232f39c828bc7b
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
C++ standard defines that 'try' should be before optional ctor
initializer, so wrong order changed. Added documentation to
parseTryBlockStatement and new test.
Task-number: QTCREATORBUG-9064
Change-Id: Id19cdc53c034cb1232ae27e0bfe36d85b7ad0452
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
... and adjust INCLUDEPATH accordingly.
while i'm at messing with include statements, also re-order the include
blocks according to policy and sort them within bigger blocks.
Change-Id: I7762abfd7c4ecf59432b99db2f424e4fa25733a5
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
When a constructor is defined with a single, unnamed argument of a custom type without
extra type specifiers (const...), then the constructor was not identified as such.
There was an heuristic in case the constructor was in the class definition, but not if the
the constructor was defined later.
Examples:
class Arg;
class Other;
class Foo {
Foo(Arg /*arg*/); // working
Foo(const Arg /*arg*/); // working
Foo(int /*arg*/); // working
Foo(Other /*arg*/) {} // working
};
Foo::Foo(Arg /*arg*/) {} // used not to work, fixed
Foo::Foo(Arg arg){} // working
Foo::Foo(const Arg /*arg*/) {} // working
Foo::Foo(int arg) {} // working
Change-Id: I741e4ba62672ddc99a837fdcdc27996fba5ae6c7
Reviewed-by: hjk <qthjk@ovi.com>
