Community
Participate
Working Groups
I20040113 In a project with the following class in package p, search for references to type 'AbstractTextEditor' finds a strange inexact match: /** * Header comment. */ package p; public abstract class AbstractTextEditor { /** * @see #restoreSelection */ protected void rememberSelection() { } public void close(final boolean save) { new Runnable() { public void run() { AbstractTextEditor.this.toString(); } }; } } Expected: finds one reference in run() Was: finds also a potential reference to a non-existent JavaElement in p/AbstractTextEditor.java, start=0, end=1
Changed summary from 'Strange inexact match in type reference search'. Bug 49774 has an example where an EXACT_MATCH with start=0, end=1 is found.
Fred: This is a javadoc problem.
Should define an ImplicitDocTypeReference to mimic the ThisReference in implicit mode.
Fixed. Now type reference search will not find the implicit type of following Javadoc see references: /** * Header comment */ public class X { int field; public X() {} /** * @see #foo() * @see #field * @see #X() */ void foo() {} } Note that this problem only occured when there was a Javadoc at the beginning of the class. For example, it didn't happen in following similar Y class: public class Y { int field; public Y() {} /** * @see #foo() * @see #field * @see #Y() */ void foo() {} } [jdt-core-dev internal] New class was created for implicit type reference: ImplicitDocTypeReference. This node store name of main type (necessary for constructor references) and position of member (ie. of '#'). MatchLocatorParser in checkComment does not try to match type references if receiver (or type) is null or if it is an implicit reference (isThis() true). Test cases added in jdt.core.tests.model.JavaSearchJavadocTests
verified for 3.0M7