Bug 276294 - Error does not go away after it is resolved
Summary: Error does not go away after it is resolved
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4.2   Edit
Hardware: PC Windows Vista
: P3 normal (vote)
Target Milestone: 3.6 M2   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 286845
  Show dependency tree
 
Reported: 2009-05-14 07:48 EDT by Jonathan Camilleri CLA
Modified: 2009-09-15 08:34 EDT (History)
5 users (show)

See Also:


Attachments
draft patch (2.63 KB, patch)
2009-07-28 16:38 EDT, Stephan Herrmann CLA
no flags Details | Diff
Proposed patch and testcases (35.59 KB, patch)
2009-07-30 13:18 EDT, Kent Johnson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Camilleri CLA 2009-05-14 07:48:50 EDT
Build ID: Build id: M20090211-1700

Steps To Reproduce:
While typing in Eclipse IDE warns me that Integer cannot be resolved, which reminds me I have to add an 'imports' clause.  It would be a good suggestion to add to the list of suggestions actually.

See code snippet in more information.

It would be helpful if Eclipse tried to guess the package from the java libraries, so it can suggest adding an 'import' clause.

More information:
package homenetwork.bkr.training;
import java.lang.reflect.*;
import java.lang.*;  //after I keyed this in error does not go away

public class HelperClass {
	
	public static boolean isFirstLetterUpperCase (String anystring) {
		return Character.isUpperCase(anystring.charAt(0));
	}
	
	public Method[] removeAt(Integer idx, Method[] arrayOfMethods)
	{
		Integer _idx = 0;
/*Displays 'Integer cannot be resolved...' and a few resolutions.
This does not include the correction of 
..add an import java.lang.*; clause.  

*/
		for (Integer =0; i < arrayOfMethods.length; i++)
		{
			
		}
	}
}

Same code in #276289
Comment 1 Jonathan Camilleri CLA 2009-05-14 09:37:44 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 :)
Comment 2 Dani Megert CLA 2009-05-14 15:26:09 EDT
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.
Comment 3 Jonathan Camilleri CLA 2009-05-14 15:28:33 EDT
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.
Comment 4 Olivier Thomann CLA 2009-07-23 14:07:38 EDT
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.
Comment 5 Olivier Thomann CLA 2009-07-23 14:14:48 EDT
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.
Comment 6 Stephan Herrmann CLA 2009-07-28 16:38:56 EDT
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()
Comment 7 Olivier Thomann CLA 2009-07-29 09:40:23 EDT
Thanks Stephan.
This looks much better.
Comment 8 Kent Johnson CLA 2009-07-29 15:19:29 EDT
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
Comment 9 Kent Johnson CLA 2009-07-29 16:02:08 EDT
Dani,

If we add a new ProblemId called UnresolvedVariable (used instead of UndefinedName in some cases), will that be a problem for quick fix ?
Comment 10 Dani Megert CLA 2009-07-30 02:40:37 EDT
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.
Comment 11 Kent Johnson CLA 2009-07-30 13:18:55 EDT
Created attachment 143041 [details]
Proposed patch and testcases
Comment 12 Kent Johnson CLA 2009-08-17 13:43:04 EDT
Released in HEAD for 3.6M2
Comment 13 Markus Keller CLA 2009-08-19 07:58:11 EDT
(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.
Comment 14 Kent Johnson CLA 2009-08-19 10:55:26 EDT
Here are 2 :

GenericTypeTest.test0252(GenericTypeTest.java:7656)

GenericTypeTest.test0584(GenericTypeTest.java:18189)
Comment 15 Markus Keller CLA 2009-08-19 12:11:26 EDT
> 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.
Comment 16 Ayushman Jain CLA 2009-09-15 08:34:32 EDT
Verified for 3.6M2 using build I20090914-1800