Community
Participate
Working Groups
I20060807-2000 In ContextInformationPopup (org.eclipse.jface.text.contentassist), double-click (or CTRL-Shift-B) in the constructor creates a class load breakpoint instead of a line breakpoint. The class was a binary, required plug-in in my workspace.
From some investigation it seems that when the classfile is opened and parsed, constructors from inner types have the enclosing type prepended as a parameter for the inner constructor. Meaning that when we ask for the elementAt(our_source_range) we are asking for the original constructor (without additions), which returns as not found, since the mapping holds the modified version. This then leads to the smallest enclosing type being returned, yielding ultimately a class load breakpoint being created. The code that prepends types as additional params is SourceMapper#enterAbstractMethod CC'ing Frederic for comment.
This is clearly a bug in JDT/Core model... Another scenario which does not involve JDT/Debug: 1) Open ContextInformationPopup 2) In Outline view expand inner class ContextFrame and double-click on its constructor => nothing happen although we should jump to constructor declaration in the editor 3) Still in Outline view, double-click on inner class => cursor correctly jumps to inner class declaration in editor The additional parameter is a synthetic one added on inner class constructor. But it sounds really strange as it seems correctly handled for other kind of inner class. For example, I didn't get this problem for ZipFileInputStream inner file of ZipFile in rt.jar...
Darin, Is there any specific reason for setting the target to 3.3 M2?
We didn't fix it in M1, so M2 seems like the next likely candidate. You can adjust accordingly.
Created attachment 47702 [details] Proposed patch Synthetic argument is only needed when inner class is not static => add corresponding test in Sourcemapper.enterAbstractMethod. That's why there's no problem with ZipFileInputStream: it's not a static class... I'll add corresponding regression test when I'll be back from vacation. Jerome, could review the fix please? Thanks
It would be better to avoid calling an operation that populates the model (namely getFlags()). Instead we should store TypeInfo.modifiers in a stack on the SourceMapper and reuse this modifier.
Created attachment 51149 [details] New proposed patch Added typeModifiers field (int[]) which stores type modifiers while descending in member types depth...
Released for 3.3 M3 in HEAD stream. Test case added in AttachSourceTests#testBug153133()
Verified for 3.3M3 with 20061030-0800
