Bug 49994 - Strange matches with start=0, end=1 in type reference search
Summary: Strange matches with start=0, end=1 in type reference search
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.0 M7   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 49774 49966
  Show dependency tree
 
Reported: 2004-01-14 11:23 EST by Markus Keller CLA
Modified: 2004-02-11 12:09 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2004-01-14 11:23:51 EST
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
Comment 1 Markus Keller CLA 2004-01-20 08:57:30 EST
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.
Comment 2 Kent Johnson CLA 2004-01-26 14:06:24 EST
Fred: This is a javadoc problem.
Comment 3 Philipe Mulet CLA 2004-01-30 10:42:24 EST
Should define an ImplicitDocTypeReference to mimic the ThisReference in 
implicit mode.
Comment 4 Frederic Fusier CLA 2004-02-06 14:01:41 EST
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
Comment 5 David Audel CLA 2004-02-11 12:09:45 EST
verified for 3.0M7