Community
Participate
Working Groups
Title: Code assist failure due to error in method signature Description: If a method signiture contains an invalid return or parameter type, the method will not show up as a valid selection in code assist. Steps to reproduce problem: 1. Create a Java project. 2. Create a package named 'jane.javapackage1' in the project from '1'. 3. Create a class named 'Class1' using the following code: package jane.javapackage1; public class Class1 { public static void hello(String arg) { } } 4. Create another class named 'Class2' using the following code: package jane.javapackage1; public class Class2 { public static void main (String[] arg) { Class1 c = new Class1(); // TYPE LINE HERE c. } } 5. In 'Class2', go to the end of "c." and press CTRL SPACE to invoke code assist. Notice that hello is on the list. 6. Now change the signature of the 'Class1.hello(...)' method to the following: publicy static void hello(String arg) Do CTRL SPACE again after "c." - the 'hello' method is there. public staticy void hello(String arg) Do CTRL SPACE again after "c." - the 'hello' method is there. public finaly static void hello(String arg) Do CTRL SPACE again after "c." - the 'hello' method is there. public static voidy hello(String arg) Do CTRL SPACE again after "c." - the 'hello' method is NOT there. public static void hello(Stringy arg) Do CTRL SPACE again after "c." - the 'hello' method is NOT there. The 'hello' method should be displayed in the code assist even through there is an error. 'Stringy' and 'voidy' might be classes that have not been defined yet. Workaround: None.
The codeassist engine is unfortunately sensitive to errors in enclosing method or type signatures. This limitation is to be removed at some point (would be nice for 2.0). One approach would be for the completion method body to be associated inside an extra initializer (or static initializer if method was static). This wouldn't solve the bogus type hierarchy case, and might add some limitations due to using initializers... We should investigate type checking the completion method when its binding isn't there, this might be a better solution.
Changed the behavior of the type solver to no longer avoid method with signature problems. A few null checks needed to be added down the road (return value secret variable management etc...) and it will benefit the entire Java tooling. Fixed.
Fixed
This was opened against 1.0. Is there a fix for 1.0 or did the fix get put into the 2.0 stream only?
With the fix below, it is now possible to code assist in a method with a defective signature. However, it is still not possible to code assist and find a method with a defective signature (undefined argument type). Is this within reach? example: void foo(Undefined x) { } void x() { f|-> doesn't discover foo
This report was originally opened against 1.0. Is this fix for 1.0 or 2.0? I would expect this to have been moved to a 2.0 fix.
Per the originator of this defect in our system: Tested in Eclipse 2.0 m5 driver. This issue has improved but there are still problems finding a method with code assist that has invalid return or parameter types. For example, public static voidy hello(String arg) public static void hello(Stringy arg) This issue is not completely addressed yet.
We do not plan to address finding incorrect methods (our compiler doesn't either). What we rather support is performing inside bodies of method with incorrect signatures.
