The code model failed to parse the noexcept operator which is often
used in noexcept specifiers, e.g.: "void f() noexcept(noexcept(g()));"
Consequently some c++11 headers such as unordered_map, array
and unordered_set could not be parsed and no code completition was
available. I have created the NoExceptOperatorExpressionAST class
which is created whenever a noexcept token is found in an
expression with operator precedence. The noExcept test case
in the cplusplus/cxx11 test now contains a function that
uses the noexcept operator.
Fixed noexcept operator parsing
Added the test requested by Sergey Shambir, which then revealed that
i had not implemeneted the noexpect operator parsing according to the
c++ specification.
As stated here http://cpp0x.centaur.ath.cx/expr.unary.noexcept.html
the noexcept operator is a unary-expression that contains an
expression (and not a constant-expression). This should now be fixed.
Change-Id: Id4a99a43b660bd83e7680274491d99a698b57094
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
For the semantic info document we do not expand function like macros and
because of that certain macro invocations lead to invalid code that we
need to handle, e.g.:
Q_GLOBAL_STATIC(CppTools::SymbolFinder, symbolFinder)
class Foo {};
This change makes parsing Foo in the semantic info document successfully
again, which affects highlighting of that class.
Change-Id: I389265ac64d3f0b8b8f406d38fa58d78820b14ba
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
If we fail to parse a declaration, we rewind, eat the token and look for the
next token that might be a good candidate for a declaration start (e.g. an
identifier). This becomes cpu and memory expensive with super long and invalid
expressions like
typedef b:Ⓜ️:if_< b:Ⓜ️:bool_<
(sizeof(fun((Dummy *) 0, (ThisT *) 0, (b:Ⓜ️:int_<70> *) 0)) ==
sizeof(defined_)) >, b:Ⓜ️:if_< b:Ⓜ️:bool_<
(sizeof(fun((Dummy *) 0, (ThisT *) 0, (b:Ⓜ️:int_<71> *) 0)) ==
sizeof(defined_)) >, b:Ⓜ️:if_< b:Ⓜ️:bool_<
(sizeof(fun((Dummy *) 0, (ThisT *) 0, (b:Ⓜ️:int_<72> *) 0)) ==
sizeof(defined_)) >, b:Ⓜ️:if_< b:Ⓜ️:bool_<
(sizeof(fun((Dummy *) 0, (ThisT *) 0, (b:Ⓜ️:int_<73> *) 0)) ==
sizeof(defined_)) >, b:Ⓜ️:if_< b:Ⓜ️:bool_<
(sizeof(fun((Dummy *) 0, (ThisT *) 0, (b:Ⓜ️:int_<74> *) 0)) ==
sizeof(defined_)) >, b:Ⓜ️:if_< b:Ⓜ️:bool_<
(sizeof(fun((Dummy *) 0, (ThisT *) 0, (b:Ⓜ️:int_<75> *) 0)) ==
sizeof(defined_)) >, b:Ⓜ️:if_< b:Ⓜ️:bool_<
// ...some more crazy lines like this
Therefore, stop trying after two failures by looking for the next semicolon or
closing curly brace.
Task-number: QTCREATORBUG-12890
Change-Id: I6637daeb840dd549d669080775228fa91fc932eb
Reviewed-by: Erik Verbruggen <erik.verbruggen@theqtcompany.com>
For expression statements like "(g(g(g(...(g(0))...))))" we reparsed
quite much again and again for nothing. The high-level trace for this
expression looks like this:
parseCastExpression
parseTypeId
parseAbstractDeclarator
parseAbstractCoreDeclarator
parseParameterDeclarationClause (--> DEEP)
...
parseUnaryExpression
...
parseCorePostfixExpression
parseTypeId (--> DEEP)
parsePrimaryExpression (--> DEEP)
Especially parseTypeId is expensive in this case and it's called two
times, both from the same token (index).
With this patch, we remember for certain ASTs the parse results and
re-use them when needed.
Change-Id: I013d1c064c655636bc94db408097863b5e183fc2
Task-number: QTCREATORBUG-12252
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
A case or a default statement must be followed by another statement.
When a such a case (or default) statement is followed immediately by
another case (or default) statement, then this would create a linked
list, and the parser will recurse to parse such input.
In order to prevent the parser running out of stack space while
recursing, parse this corner case by blocking parsing a labeled
statement as the first statement after a labeled statement.
The advantage is that these statements do not form a linked list, so any
subsequent visitation of the AST won't run out of stack space either.
Change-Id: Id2111a49509132997f5fbe4bb12c92c729ec2522
Task-number: QTCREATORBUG-12673
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
CPlusPlus::Parser::parseAccessSpecifier() is not used anywhere
throughout the QtCreator codebase.
Change-Id: I062a4ae257b9c61f02bf85079feb6d48bd07c49e
Reviewed-by: Erik Verbruggen <erik.verbruggen@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>
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>
This time in the 'new' expression. Changed it to make
new C(1, abc...) and new C{1, abc}
work.
Change-Id: I7232798fd083b653ee04ef9ede386d6536133e16
Reviewed-by: hjk <qthjk@ovi.com>
This will fix a couple more places where brace-init-lists and
pack expansions are allowed but are not currently accepted by
the parser. For example:
foo(abc...);
now parses correctly.
Change-Id: I93710cef35154fea8437329f3174e4a2d56637b8
Reviewed-by: hjk <qthjk@ovi.com>
Means
void foo() const &; void bar() &&;
and the corresponding pointer-to-member declarators
now parse.
Change-Id: Idbf295bd4f51cd5d9e38efcac1940b8cc2e32fce
Reviewed-by: hjk <qthjk@ovi.com>
It'll be reused as the initializer expression for declarators
that are followed by "( expression-list )".
Change-Id: I6c76a76641941874ef1ed21daa7b6e057c6d170f
Reviewed-by: hjk <qthjk@ovi.com>
Thanks to Clang's parser_overflow.cpp which has >16000 nested compound
statements to check exactly the same.
Change-Id: I2b604f8ceb01115d7fe950994e0677a081e99481
Reviewed-by: Christian Kamm <christian.d.kamm@nokia.com>
they are lying. nokia has no copyright on this code. and the double
license in a single file looks weird. that's why we moved it to
3rdparty/, so it is clear it is not nokia's.
Approved-by: legal
