Bug 62869

Summary: [navigation] 'Go to Next Annotation' doesn't find next error
Product: [Eclipse Project] JDT Reporter: Markus Keller <markus.kell.r>
Component: CoreAssignee: Olivier Thomann <Olivier_Thomann>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert
Version: 3.0   
Target Milestone: 3.0 RC1   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Markus Keller CLA 2004-05-19 07:08:17 EDT
200405190010

In the configuration below, 'Go to Next Annotation' doesn't find the error after
jumping to the warning. 'Go to Previous Annotation' however correctly cycles
through both Markers.

- set 'Prefs > Java > Compiler > Style > Undocumented empty block' to Warning
- check 'Errors' and 'Warnings' in 'Go to Next Annotation' toolbar button menu
- Ctrl+. -> correctly jumps to "Empty block should be documented" (local class)
- Ctrl+.
-> expected: jumps to "Type mismatch: ..."
-> was: stays on first annotation.

public class Klazz {
	public Runnable getHoverUpdater() {
		class Lokal {
			
		}
		return new Object();
	}
}
Comment 1 Dani Megert CLA 2004-05-19 07:20:41 EDT
not critical for 3.0 M9
should fix for 3.0 since it blocks to go to other annotations.
Comment 2 Dani Megert CLA 2004-05-25 09:35:51 EDT
The endPosition (85) of the problem reported by J Core is off by one (too long)
- it points to '\r'. This causes the real selection to be smaller than the
annotation and hence we can no longer navigate.
Comment 3 Philipe Mulet CLA 2004-05-25 10:13:18 EDT
Olivier - pls investigate and let me know.
Comment 4 Olivier Thomann CLA 2004-05-25 10:19:15 EDT
I am investigating.
Comment 5 Olivier Thomann CLA 2004-05-25 11:02:35 EDT
The error is reported using bodyEnd + 1 for the end position. I believe that
removing this + 1 should be good enough. I will check if bodyEnd includes the
closing '}' or not. If not, then the right fix is to scan for the '}' starting
at bodyEnd position and then removing one to the resulting position.
Comment 6 Dani Megert CLA 2004-05-25 11:05:52 EDT
Sounds good. The only real problem for us is if it contains partial line delimiter
Comment 7 Olivier Thomann CLA 2004-05-25 11:10:24 EDT
Understood. To clarify, the end position we want includes the '}', but it should
not go further. The following '\r' should clearly not be included.
Comment 8 Olivier Thomann CLA 2004-05-25 11:17:39 EDT
For a type declaration, bodyEnd is the position we want. But for a method
declaration, we want bodyEnd + 1. Ideally we want to scan the position of the
'}' in order to handle unicodes properly.
Comment 9 Olivier Thomann CLA 2004-05-25 11:31:49 EDT
Changing the end position to bodyEnd in the type declaration case instead of
bodyEnd + 1 fixes it. It also works with unicode.
The problem with unicode remains in case of a '}' written as unicode for the
method declaration. The only way to fix it would be to scan the source again.
Not sure this is necessary. Reporting a position inside a unicore character
should not be a problem.
Comment 10 Olivier Thomann CLA 2004-05-25 13:17:42 EDT
Fixed and released in HEAD.
NegativeTest>test392 is updated to reflect the changes.
Comment 11 Olivier Thomann CLA 2004-05-28 15:40:36 EDT
Verified in 200405281200