The function `getValueProvider` is defined in `IssueSeveritiesProvider`
for replying the value provider instance.
This function seems to be defined as protected in order to be overriden.
But is it not called from the rest of the code of
`IssueSeveritiesProvider`. This PR fixes this issue.
Signed-off-by: Stéphane Galland <galland@arakhne.org>
Since now Flaky is also part of .xtext.testing, I copied the tests for
Flaky from .junit4.tests project
Signed-off-by: Lorenzo Bettini <lorenzo.bettini@gmail.com>
When using huge models, the getContents() call takes really big runtime.
Shorten runtime by only asking it for much faster isEmpty().
Signed-off-by: Michael Keppler <michael.keppler@gmx.de>
This annotation was still present in .xtext.junit4, so why not copying
that into the new .xtext.testing and then later deprecate the one in
.xtext.junit4?
Signed-off-by: Lorenzo Bettini <lorenzo.bettini@gmail.com>
This change adds a default method
boolean containsURI(String containerHandle, URI candidateURI)
to IAllContainersState, so that implementations can introduce
a faster algorithm that leverages the internals data structures.
Signed-off-by: Moritz Eysholdt <moritz.eysholdt@typefox.io>
This fix prevents exceptions such as "IllegalArgumentException:
Comparison method violates its general contract" by not sorting the list
of methods at all. Since the method selection algorithm scans the
complete list of methods, the order of the list does not impact the
algorithm's outcome.
The fix does not change the precedence of methods since the
implementation of compare(method1, method2) is kept the same.
However, this bug taught us that compare(m1, m2) is not suitable to
establish a total order among a list of methods and that
compare(m1, m2)==0 && compare(m2, m3)==0
does NOT imply compare(m1, m3)==0.
Example:
m1(A a), m2(B b), m3(C c), class A{}, class B{}, class C extends A{}
This observation required another change: When scanning the list of
methods for candidates, it does not suffice to compare the current
candidate with the last best candidate. Instead, it is needed to compare
the current candidate with all best candidates, because
compare(currentCandidate, lastBestCandidate)==0 does NOT imply compare()
to return 0 for the other best candidates.
When calling compare(m1, m2) among the best candidates it is always
expected to return 0, meaning the candidates are unrelated (e.g.
independent inheritance hierarchies of their parameter types) or equal.
see https://github.com/eclipse/xtext-core/issues/238
Signed-off-by: Moritz Eysholdt <moritz.eysholdt@typefox.io>
