This patch adds preliminary support for C++11 user defined litrals:
* Syntax support
* Type deduction in expressions
* Template literal operators
* String literal concatenation
I made quite a few changes in CPPASTLiteralExpression so that it more
closely follows the spec when parsing numbers. And I'd like some
feedback on the changes I made to CPPSemantics with regards to
template literal operators.
There are also some questions I have marked in comments, which I would
appreciate an answer to.
Change-Id: I242ecb8f5706f516a4c891fea268a668e5e4a694
Signed-off-by: Richard Eames <eclipse@naddiseo.ca>
Reviewed-on: https://git.eclipse.org/r/24367
Reviewed-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
Tested-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
to cdt-file-types-list (as defined in c++ standard section 17.6.1.2)
Change-Id: Idbbba12655a72b24cd28aab71d9a613320a7e70c
Signed-off-by: Lukas Felber <l.felber@gmx.ch>
Reviewed-on: https://git.eclipse.org/r/24854
Tested-by: Hudson CI
Reviewed-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
Tested-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
Adds a -exclude option to list directories and files that are to be
excluded from the pre-built PDOM so we don't get header files that
users don't get suggest optional headers.
Adds a -exclude option to list directories and files that are to be
excluded from the pre-built PDOM so we don't get header files that
users don't get suggest optional headers.
Change-Id: I4e06ccda2207f9955bb743006af8cf947c5d67f3
A pretty simple and kludgy fix to the problem, but if we detect that
we are adapting a binding that we are just in the middle of adapting,
we bail and return null. Added Andrew's JUnit that reproduces the
problem in case someone wants to try a better solution.
Change-Id: Ib4a85c161be6aee073fee7ac0501464b70020fac
Reviewed-on: https://git.eclipse.org/r/24396
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
Reviewed-on: https://git.eclipse.org/r/24409
Tested-by: Hudson CI
testCPathEntries verifies the presence of the default path entries.
testPathEntryContainer modifies the path entries. Because the same
project is being used, if testPathEntryContainer executes first,
testCPathEntries fails. By creating and deleting the project every
time, the problem is fixed.
Also, removed some unnecessary code than seemed copy pasted but not actually used.
Change-Id: Ifcd06d3a133f29b5ce9e2e0fdee34e9493377625
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/23756
Tested-by: Hudson CI
Reviewed-by: Sergey Prigogin <eclipse.sprigogin@gmail.com>
It appears this class was not written to with random test ordering in
mind. This should fix some of the intermittent test failures.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
This happens when constructor EvalBinding(IBinding binding, IType type,
IBinding templateDefinition) is called with a null binding. A binding
can be null for example when TypeMarshalBuffer.unmarshalBinding returns
null. Instead of returning null, unmarshalBinding can return a
ProblemBinding and the assumptions that the binding in EvalBinding is
not null can be maintained.
Change-Id: Icebf875e059f2962cc2ddd91d3b79c51b88eddac
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/18064
