Bug 130926 - The source editor generates false error indicators...
Summary: The source editor generates false error indicators...
Status: RESOLVED DUPLICATE of bug 36032
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M4   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-08 11:17 EST by Theo CLA
Modified: 2006-03-14 12:10 EST (History)
0 users

See Also:

Attachments
a plugin project (5.07 KB, application/x-zip-compressed)
2006-03-14 10:55 EST, Theo CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Theo CLA 2006-03-08 11:17:57 EST 
Hi there,
I have a couple of default package scope classes in a separate file.
When this file is open in the IDE everything is fine.
If I close it Eclipse indicates the usages (import statements, declarations of instances) of these classes as errors.
These errors are shown in the source editor only, but not in the Package Explorer.
Also, the whole application obviously finds and uses these classes correctly.
javac does not find anything wrong about them as well.
Project / Clean... does not help...
I tried that file both with and without a dummy public class in it, its the same
I use : Version: 3.1.0 Build id: I20050627-1435
Regards,
Theo
Comment 1 Olivier Thomann CLA 2006-03-12 20:15:48 EST 
Could you please provide a reproducable test case and your compiler settings?
compliance? source level? target platform?

Are you using secondary types (i.e. non-public types defined in a compilation unit) ?
Can you reproduce with latest integration build?
Comment 2 Theo CLA 2006-03-14 10:55:06 EST 
Created attachment 36237 [details]
a plugin project
Comment 3 Theo CLA 2006-03-14 11:02:12 EST 
Hi, I put together a scaled-down version of the prj I've been 
working on when I noticed the problem. It should be easily
reproducible now. 
What else,...it doesn't depend on the compiler compliance level.
Yes, there are secondary types ( non-public types defined in a
compilation unit).
Haven't tried it with other builds.
Cheers
Comment 4 Olivier Thomann CLA 2006-03-14 11:02:53 EST 
This is a consequence of using secondary types.
See bug 36032 and bug 118789.
This has been fixed in 3.2M4.
Please try out with a buid >= 3.2M4 and let us know if you can reproduce.
Closing as duplicate of bug 36032.

*** This bug has been marked as a duplicate of 36032 ***