Bug 303830 - "X cannot be resolved or is not a field" erroneously reported
Summary: "X cannot be resolved or is not a field" erroneously reported
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.6 M6   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-24 18:18 EST by Luke Hutchison CLA
Modified: 2010-03-10 15:03 EST (History)
4 users (show)

See Also:


Attachments
Proposed fix + regression test (3.12 KB, patch)
2010-03-08 14:20 EST, Olivier Thomann CLA
no flags Details | Diff
Proposed fix + updated regression tests (9.22 KB, patch)
2010-03-08 15:09 EST, Olivier Thomann CLA
no flags Details | Diff
Proposed fix + updated regression tests (10.05 KB, patch)
2010-03-08 15:14 EST, Olivier Thomann CLA
no flags Details | Diff
Proposed fix + updated regression tests + new regression test (9.89 KB, patch)
2010-03-08 15:51 EST, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Hutchison CLA 2010-02-24 18:18:31 EST
Build Identifier: I20091217-0819

The following code reports "myList cannot be resolved or is not a field" whereas it should report something like "length is not a field of type ArrayList".  All of myList.length is underlined, but probably just the .length part should be underlined:

	ArrayList<String> myList = new ArrayList<String>();
	int len = myList.length;

It is a much more confusing message when myList *is* actually a field, and you thought you were using an array but you're actually using an ArrayList...

Reproducible: Always
Comment 1 Dani Megert CLA 2010-02-25 02:55:10 EST
I cannot reproduce this using 3.5, 3.6 M4 or I20100223-0800. In all those builds I get the following expected error reported:
"myList.length cannot be resolved or is not a field"
Comment 2 Olivier Thomann CLA 2010-03-08 13:54:44 EST
Reproduced using I20100307-2000
Comment 3 Olivier Thomann CLA 2010-03-08 14:20:12 EST
Created attachment 161335 [details]
Proposed fix + regression test

Patch under testing.
Comment 4 Olivier Thomann CLA 2010-03-08 14:28:40 EST
If testing is successful, I will target 3.6M6.
Comment 5 Olivier Thomann CLA 2010-03-08 15:09:47 EST
Created attachment 161350 [details]
Proposed fix + updated regression tests

Updated existing regression tests.
Comment 6 Olivier Thomann CLA 2010-03-08 15:14:22 EST
Created attachment 161352 [details]
Proposed fix + updated regression tests

Same patch with copyright updates.
Comment 7 Olivier Thomann CLA 2010-03-08 15:38:43 EST
Targetting M7 as it needs more testing.
Comment 8 Olivier Thomann CLA 2010-03-08 15:51:55 EST
Created attachment 161359 [details]
Proposed fix + updated regression tests + new regression test

A NPE was possible with previous patch. This should fix it.
More testing is expected.
Comment 9 Olivier Thomann CLA 2010-03-08 23:29:32 EST
Released for 3.6M6.
Updated existing regression tests.
Comment 10 Frederic Fusier CLA 2010-03-10 02:53:00 EST
Verified for 3.6M6 using I20100309-0809 build.
Comment 11 Srikanth Sankaran CLA 2010-03-10 03:39:01 EST
Actually, I was not able to reproduce this either.
I observe the same behavior as Dani per comment#1
which was reasonable in itself.

Further more all the existing regression tests
that have been modified as a part of this patch
also indicate that the old message was reasonable.

That said, the new message and range look correct
too.

Verified for 3.6M6 using build I20100309-0809
Comment 12 Olivier Thomann CLA 2010-03-10 15:03:03 EST
The "problem" was that the compiler is reporting the error on the second part of the qualified name, but the problem message and positions don't properly reflect this.
The change is minor and doesn't remove anything in the compiler. The problem message and positions are just more narrow to report the problem against the appropriate part of the qualified name.
We had such changes in the past for other cases and we decided to fix them on a case-by-case basis.