Summary: | Error does not go away after it is resolved | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Jonathan Camilleri <camilleri.jon> | ||||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | amj87.iitr, daniel_megert, darin.eclipse, markus.kell.r, Olivier_Thomann | ||||||
Version: | 3.4.2 | ||||||||
Target Milestone: | 3.6 M2 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows Vista | ||||||||
Whiteboard: | |||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 286845 | ||||||||
Attachments: |
|
Description
Jonathan Camilleri
2009-05-14 07:48:50 EDT
Error was due to incorrect syntax. Basically, I had not included the variable in the declaration, eg: Integer .. = 0; So it would be helpful if the following conditions could be caught: 1. imports statement is missing 2. variable declaration is incorrect or incomplete. It would be helpful if the error messages / resolutions are more specific; I trust you're aware :) Agree that the compiler's error message is misleading, especially because Integer doesn't need an import. Here's a simple test case: public class Test { public void foo() { Integer 3; } } Moving to JDT Core. As a matter of fact it is the first time I had to look up the package name (or whatever it is called...in .NET I called them namespaces) in the Java API. The only thing we can do here is to improve the error message. javac reports that Integer cannot be resolved, but as a variable name. HelperClass.java:16: cannot find symbol symbol : variable Integer location: class HelperClass for (Integer = 0; i < arrayOfMethods.length; i++) { ^ HelperClass.java:16: cannot find symbol symbol : variable i location: class HelperClass for (Integer = 0; i < arrayOfMethods.length; i++) { ^ HelperClass.java:16: cannot find symbol symbol : variable i location: class HelperClass for (Integer = 0; i < arrayOfMethods.length; i++) { ^ 3 errors This is more helpful for the user. We get "Integer" as a name reference. So maybe we could try to rephrase the error message to be less misleading. Kent, any suggestion ? For the type case, we have: {0} cannot be resolved to a type For the field case, we have: {0} cannot be resolved or is not a field but in the case of a name reference, we don't know what it is supposed to be. A field ref, a variable ref, a type ref. Created attachment 142822 [details]
draft patch
Were you thinking about s.t. along these lines?
----------
1. ERROR in HelperClass.java (at line 17)
for (Integer =0; i < arrayOfMethods.length; i++)
^^^^^^^
Integer cannot be resolved to a variable
----------
2. ERROR in HelperClass.java (at line 17)
for (Integer =0; i < arrayOfMethods.length; i++)
^
i cannot be resolved to a variable
----------
3. ERROR in HelperClass.java (at line 17)
for (Integer =0; i < arrayOfMethods.length; i++)
^
i cannot be resolved to a variable
----------
3 problems (3 errors)
That's the output with the attached draft patch.
I ran org.eclipse.jdt.core.tests.compiler.regression.TestAll
which signaled 79 changes, most of which are obvious and look
like the intended improvement.
Apart from the infrastructure tests in CompilerInvocationTests
two cases might deserve a closer look:
- do we want the new wording also for annotations?
see org.eclipse.jdt.core.tests.compiler.regression.AnnotationTest
- I couldn't find an easy way to distinguish variables vs. expected constants.
See org.eclipse.jdt.core.tests.compiler.regression.EnumTest.test026()
Thanks Stephan. This looks much better. As far as annotations go, in this case, javac refers to it as a variable : public class X { @Ann(m=Object) private int foo; } @interface Ann { String m(); } X.java:2: cannot find symbol @Ann(m=Object) ^ symbol: variable Object location: class X 1 error Dani, If we add a new ProblemId called UnresolvedVariable (used instead of UndefinedName in some cases), will that be a problem for quick fix ? Kent, it's not a problem but we have to make sure that we update the code in the UI to register the corresponding quick fixes for that new problem id. Best is to file a bug against JDT UI when you make that change. Created attachment 143041 [details]
Proposed patch and testcases
Released in HEAD for 3.6M2 (In reply to comment #9) > If we add a new ProblemId called UnresolvedVariable (used instead of > UndefinedName in some cases) [..] Could you please give an example where UndefinedName is still issued now? I tried to produce one, but I couldn't. If it's really not used any more, then we don't need the new problem ID at all and could just adjust the error message. Here are 2 : GenericTypeTest.test0252(GenericTypeTest.java:7656) GenericTypeTest.test0584(GenericTypeTest.java:18189) > Here are 2 :
Thanks. For those who don't have the compiler tests, it's as simple as this:
channels.get(0); // 'channels' could be a type or a variable
Verified in I20090818-0800.
Verified for 3.6M2 using build I20090914-1800 |