Community
Participate
Working Groups
EclEmma maps coverage data to JDT Java model elements down to IMethod level. Collected coverage data comes with fully resolved binary method signatures. To map those to source methods unresolved IMethod signatures must be resolved (only if methods are overloaded and the plain name is ambigous). For this EclEmma implements utility to resolve method signatures: https://github.com/eclipse/eclemma/blob/master/org.eclipse.eclemma.core/src/org/eclipse/eclemma/internal/core/analysis/SignatureResolver.java While fixing bug 512756 we came up with a new corner case which does not resolve properly: // S resolves to java.lang.Comparable public class ScopeSample<S extends Comparable> { // This has no influence on the type of S class Comparable { } class Inner { // So S still resolves to java.lang.Comparable void Foo(S param) { } } } When resolving the type parameter S for the signature of method ScopeSample.Inner.Foo() the following happens: EXPECTED The type parameter S must resolve to java.lang.Comparable ACTUAL The type parameter S resolves to ScopeSample.Comparable
Posted a question about this in the JDT mailing list. Maybe there is a better way to resolve method signatures: http://dev.eclipse.org/mhonarc/lists/jdt-dev/msg00887.html
According to JLS 6.3 (https://docs.oracle.com/javase/specs/jls/se8/html/jls-6.html#jls-6.3): "The scope of a top level type (§7.6) is all type declarations in the package in which the top level type is declared." Current implementation uses the type's method body as scope, which is wrong.
Seeing Signature.getTypeErasure(identifier) in your code (and without understanding the details of it), I hazard the guess that you are erasing too early. Perhaps your strategy should be modified to first resolve S to the ITypeParameter of the IType for ScopeScample, and then compute the erasure of it (perhaps directly using its first bound or such). For demonstration: if you first erase S to Comparable and then resolve Comparable in the scope of Inner the actual behaviour should be expected.
As Stephan noted on the JDT mailing list there is open request for a new API to resolve type parameters: Bug 502563
Stephan, I the problem here is that the type parameters of types are resolved in the wrong context: They must not be resolved within the type, but within the parent context of the type. So * For inner classes within the parent type (IType.resolveType) * For top level classes within the package scope Is there an API to resolve types within package scope?
