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
Change-Id: Ia88fa4032483cf70f41714bddd688d754bb5451b
Signed-off-by: William Riley <william.riley@renesas.com>
Reviewed-on: https://git.eclipse.org/r/22972
Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com>
IP-Clean: Marc Khouzam <marc.khouzam@ericsson.com>
Tested-by: Marc Khouzam <marc.khouzam@ericsson.com>
Adding IQMakeProjectInfo.updateQMakeInfo():QMakeInfo method to allow
explicit calculation of QMakeInfo at the time of the method call.
Change-Id: I665bedd5e095d1968f0c39ff2abb19c60aac9e14
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/23800
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
Tested-by: Doug Schaefer <dschaefer@qnx.com>
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>
Sometimes, index-based checkers (AbstractIndexAstChecker) were skipped
because the indexer was not fully initialized so expected errors were
not getting reported.
Change-Id: Ibb764224f11ae4a867a4aa6b9de2b8ec55e90c55
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Reviewed-on: https://git.eclipse.org/r/23428
Reviewed-by: Nathan Ridge <zeratul976@hotmail.com>
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
To prevent a deadlock between two the workspace and QMakeProjectInfo.sync
locks, QMakeProjectInfo class has been rewritten to not call any method
under sync-lock except for IQMakeEnv.init/destroy method.
All methods should allow calling under workspace lock.
Added a new IQMakeEnv2 interface to provide an explicit init method.
Original QMakeProjectInfo has been split to
QMakeProjectInfo and QMakeProjectInfoManager.
This change is fully backward compatible.
Change-Id: I880f22dd9bd999af1d3f47e4a3c4c0ab216b4ad2
Signed-off-by: David Kaspar <dkaspar@blackberry.com>
Reviewed-on: https://git.eclipse.org/r/23270
Tested-by: Hudson CI
Reviewed-by: Andrew Eidsness <eclipse@jfront.com>
Reviewed-by: Doug Schaefer <dschaefer@qnx.com>
IP-Clean: Doug Schaefer <dschaefer@qnx.com>
