Bugzilla – Full Text Bug Listing
| Summary: | [inline] IndexOutOfBoundsException in inline method refactoring with compile error | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ulli Hafner <Knut.Friedhelm> | ||||||||
| Component: | UI | Assignee: | Deepak Azad <deepakazad> | ||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||
| Severity: | minor | ||||||||||
| Priority: | P3 | CC: | daniel_megert, markus.kell.r, Olivier_Thomann, rthakkar | ||||||||
| Version: | 3.6 | ||||||||||
| Target Milestone: | 3.7 M2 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Ulli Hafner
Created attachment 169941 [details]
The file that caused the exception
Could you please provide a small project that contains the attached file + all required files that are needed to be able to use the inline refactoring? As is I cannot invoke the refactoring as the cu contains too many compile errors for types that cannot be resolved. I reproduced it if the only compile error is related to the line:
return getImage(node.hasUnknownAxioms(property));
Moving to JDT/UI. I'll attach a zipped project to reproduce the issue. Created attachment 170003 [details]
Test case.
Import the zipped file as an existing project inside an archive file.
Easier example to reproduce (inline getImage()):
public class Try {
Object getImage() {
return null;
}
Object foo() {
Object o= getImage();
return getImage(o);
}
}
Create the following 2 classes in different files and inline getImage(), Select "All Invocations"
=> Invocation with error in Try is inlined but the one in A is not. This is inconsistent behavior!
public class Try {
Object getImage(Object o) {
return null;
}
Object foo() {
Object o= getImage();
return getImage(o);
}
}
class A {
void foo() {
new Try().getImage();
}
}
Reason : The Java search in TargetProvider.MemberTypeTargetProvider.getAffectedCompilationUnits(...) does not matches invocations with compile errors. The invocations with compile errors get added later on using TargetProvider.InvocationFinder, because invocation with compilation error has the same method binding as the declared method but no indication that there is a compilation error.
I really think that JDT core should indicate the presence of an error on a method invocation. The current API does not do that and according to me that is incorrect.
Created attachment 176108 [details]
fix+tests
Fixed in HEAD.
A method invocation with a compile error has type binding as null. I could use this information to exclude invocations with errors.
. Verified in I20100914-0100. Verified for 3.7 M2 with I20100913-1800. |