Summary: | Valid identifier unrecognized. | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Brian Miller <Brian.Miller> | ||||||||||
Component: | Core | Assignee: | Ayushman Jain <amj87.iitr> | ||||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||||
Severity: | normal | ||||||||||||
Priority: | P3 | CC: | jarthana, martinae, Olivier_Thomann, srikanth_sankaran | ||||||||||
Version: | 3.4 | Flags: | Olivier_Thomann:
review+
|
||||||||||
Target Milestone: | 3.6 M6 | ||||||||||||
Hardware: | PC | ||||||||||||
OS: | Windows XP | ||||||||||||
Whiteboard: | |||||||||||||
Attachments: |
|
Description
Brian Miller
2008-06-04 13:46:47 EDT
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. |