Bugzilla – Full Text Bug Listing
| Summary: | [compiler] NPE in Scope.getTypeOrPackage | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Szymon Ptaszkiewicz <sptaszkiewicz> | ||||||||||||||||||
| Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||||||
| Severity: | major | ||||||||||||||||||||
| Priority: | P3 | CC: | daniel_megert, jarthana, Olivier_Thomann | ||||||||||||||||||
| Version: | 3.1 | Flags: | john.arthorne:
pmc_approved+
|
||||||||||||||||||
| Target Milestone: | 3.6.2+ | ||||||||||||||||||||
| Hardware: | All | ||||||||||||||||||||
| OS: | All | ||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||
Created attachment 188773 [details]
Project for reproduction
Simple step to reproduce: paste the following into the Package Explorer:
----------%<----------
package a;
public class B {
}
package external;
public class Lib {
public static void m() {
}
}
package a.B;
import static external.Lib.m;
public class C {
public void main() {
m();
}
}
----------%<----------
Broken since 3.1. This is an error case. That code should not compile and we detect properly the name collision cases. I think when the current package cannot be se because the package name collides with a type, the import of the corresponding unit declaration should not be resolved. I'll investigate a fix for this. I see two ways to fix this issue: 1) When a package name collides with a type name, we report the error and we initialize the package of the unit scope to the default package to prevent further secondary errors like this NPE. 2) We don't call: CompilationUnitScope#faultInTypes(); if the corresponding unit is tagged with errors (ignoreFurtherInvestigation is set to true). Both ways will fix this issue (NPE). The actual code should not compile. I would favor (1) as we have many cases where we don't check if the unit scope package binding is null. Srikanth, your call. Created attachment 189015 [details]
Proposed fix for 3.6. maintenance
Created attachment 189022 [details]
Proposed fix + regression test
Same patch for HEAD with some cleanup.
Created attachment 189028 [details]
Proposed fix + regression test
Updated patch for 3.6 maintenance with a regression test.
Note that whatever we do, the unit is not resolved as the package binding resolution caused it to be tagged as ignoreFurtherInvestigation. So what can be done with this unit is very limited. Created attachment 189068 [details]
Revised patch for HEAD.
Agree with the fix.
Slightly deeper changes for HEAD eliminating a few more redundant null checks.
For 3.6.x stream, we can retain the patch already posted.
Released in HEAD for 3.7 M6. Srikanth, do you intend to release this for 3.6.x as well? Verified for 3.7M6 using build I20110301-1537. Please reopen if the fix is required in 3.6.x. Yes, it is required for 3.6.x I'll release in 3.6 maintenance. John, we need PMC approval to release this to 3.6.2+. Thanks. Created attachment 190559 [details]
Updated patch
Revised patch for 3.6 maintenance with appropriate bundle version changes.
Created attachment 190560 [details]
Updated patch
Same patch with copyrights update.
FYI, I have added the 3.6.2+ target milestone to bugzilla. Released last patch in 3.6 maintenance. |
Created attachment 188771 [details] .log Build id: I20110118-0800 If package name collides with a type name and there is static import inside, then you get NPE. If the static import is commented out, then NPE is not thrown. Log is attached. You can reproduce the problem using the following code: //------------------------------ package a; public class B { } //------------------------------ package external; public class Lib { public static void m() { } } //------------------------------ package a.B; import static external.Lib.m; public class C { public void main() { m(); } } //------------------------------