Community
Participate
Working Groups
Build ID: I20080330-1350 Steps To Reproduce: 1. Select the identifier Proto on LINE 4. 2. Pick the "Navigate>>Open Declaration" menu item. The request fails. See in the status bar this complaint: "Current text selection cannot be opened in an editor" ------------ Foo.java ----------------- import bug.Bug; import bug.Bug.*; class Foo extends Bug implements Proto //LINE 4 {} --------------- bug/Bug.java --------- package bug; public class Bug{ protected interface Proto{}; }
ICompilationUnit.codeSelect returns an empty array here.
Ayush, please take a look.
Created attachment 161089 [details] proposed fix v1.0 + regression tests This happens because in Scope#findDirectMemberType(char[], ReferenceBinding) (called from CompilationUnitScope) , we try to find the "enclosingReceiverType" which is returned as null, and so when we check for visibility of Proto via ReferenceBinding#canBeSeenBy , we only check the current package for it. Had we called Scope#findDirectMemberType(char[], ReferenceBinding) via the ClassScope of the extending class, we'd have correctly found the enclosingReceiverType, but in this case we are in a CompilationUnitScope. We need to consult the types in the CompilationUnitScope, and in case any of them extends the class which contains the protected interface, we need to call ReferenceBinding#canBeSeenBy and check for visibility. This is what the above fix does.
Slightly modified patch.
Created attachment 161200 [details] Proposed fix + regression test
Ayushman, if you agree, I'll release for M6.
Created attachment 161201 [details] Proposed fix + regression test Same patch with a small change in the ResolveTests suite.
Yup, looks good.
Created attachment 161314 [details] Proposed fix + regression test Minor change in the for loop.
Released for 3.6M6. Regression test added in: org.eclipse.jdt.core.tests.model.ResolveTests#testInterfaceX
Just curious... I was wondering what's the motivation behind taking a separate local variable to hold types.length?
(In reply to comment #11) > Just curious... I was wondering what's the motivation behind taking a separate > local variable to hold types.length? To hoist the loop invariant code to outside the loop.
(In reply to comment #12) > (In reply to comment #11) > > Just curious... I was wondering what's the motivation behind taking a separate > > local variable to hold types.length? > To hoist the loop invariant code to outside the loop. It is a coding style I am using a lot. When the size of the array/collection doesn't change during the iteration, I prefer to extract it right away to prevent the size to be retrieved at each iteration. Initializers are run only once, but the increment is run for each iteration. Just a matter of taste.
Verified for 3.6M6 using I20100309-0809
Part of the change made via this bug has been reverted via bug 520874. An alternate fix has been provided, which is explained in bug 520874, comment #5.
