Community
Participate
Working Groups
HEAD, follow-up to bug 301113 comment 2: package x.y.z; public class Test { public void method() { class LocalClazz { public String speak() { return "hello"; //set bp here } } } } The key I get from IType.getKey() is: Lx/y/z/Test$LocalClazz; (The IType is coming from ITypeRoot.getElementAt(..)). From bug 301113 comment 3: IType#getKey() does not specify that it doesn't work for unresolved local ITypes (with IType#isResolved() == false). Debug has a workaround (i.e. can live without a fix for 3.6).
The problem is that the key is different between a resolved type and an unresolved type. When the type is resolved, its key comes from the corresponding binding. When the type is not resolved, its key is computed and the way it is computed returns a different value for local types.
Using: CompilationUnit unit = SharedASTProvider.getAST(type.getTypeRoot(), SharedASTProvider.WAIT_YES, null); ASTNode node = unit.findDeclaringNode(type.getKey()); is wrong as type.getKey() is not a binding key. It is only a java element key when the element is not resolved. Would not a org.eclipse.jdt.core.dom.NodeFinder be used to retrieve the corresponding ASTNode?
(In reply to comment #2) > [..] is wrong as type.getKey() is not a binding key. It is only a > java element key when the element is not resolved. That is not spec'd in IType#getKey(), which is why I've opened this bug. We can also close this by saying that the method only returns a binding key if the type is resolved. > Would not a org.eclipse.jdt.core.dom.NodeFinder be used to retrieve the > corresponding ASTNode? No, we don't want to find the corresponding node, but the *declaring* node.
(In reply to comment #3) > > Would not a org.eclipse.jdt.core.dom.NodeFinder be used to retrieve the > > corresponding ASTNode? > > No, we don't want to find the corresponding node, but the *declaring* node. Sorry, for bug 301113, that would definitely be a better solution with even better performance, since IType#getNameRange() shouldn't be too expensive and we can use the shared AST again.
(In reply to comment #4) > Sorry, for bug 301113, that would definitely be a better solution with even > better performance, since IType#getNameRange() shouldn't be too expensive and > we can use the shared AST again. Exactly what I had in mind :-). I'll try to provide a patch for this.
Created attachment 165863 [details] Proposed fix
Released for 3.6M7.
I guess we have the same problem in IField and IMethod, so the Javadoc should also be adjusted there.
Created attachment 165905 [details] Complement
Verified for 3.6M7 through code inspection
Verified.
