Bug 18175 - Quickfix false positives for non-public classes
Summary: Quickfix false positives for non-public classes
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 2.0 F3   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-29 10:04 EDT by Jared Burns CLA
Modified: 2002-06-06 04:36 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jared Burns CLA 2002-05-29 10:04:25 EDT
Build 20020528

1. Make a compilation unit named Foo.java
2. In Foo.java, define a class named Foo1:
class Foo1 {
	public static int X= 1;
}
3. In another compilation unit in the same package, make a reference to 
Foo1:
public class Hello {
	public static void main(String[] args) {
		System.out.println(Foo1.X);
	}
}
A quickfix error is shown which states that Foo1 cannot be resolved. 
However, this code *does* compile.
Comment 1 Martin Aeschlimann CLA 2002-05-30 05:24:19 EDT
can't reproduce.
If you type some spaces, does the quickfix error disapear?
Comment 2 Martin Aeschlimann CLA 2002-05-30 06:01:44 EDT
*** Bug 17104 has been marked as a duplicate of this bug. ***
Comment 3 Philipe Mulet CLA 2002-05-31 16:57:28 EDT
Need testing during TP#2
Comment 4 David Audel CLA 2002-06-05 12:58:56 EDT
Foo1 is a secondary type in the Foo.java compilation unit. That't why quickfix 
can not resolve this type. The file Hello.java can be compiled because Foo.java 
is already compiled but if Foo.java is not compiled before then the compiler 
produce the same error as quickfix.

The current behavior is correct.

Closing.



Comment 5 Jared Burns CLA 2002-06-05 14:11:56 EDT
The error remains even after the compiler has run and successfully compiled 
the classes.

Close the report if you won't fix the bug, but the behavior is NOT correct.
Comment 6 Philipe Mulet CLA 2002-06-06 04:36:06 EDT
The behavior is acceptable given that secondary types are not actively found 
(would need parsing everything eagerly).

The build state isn't used by the tooling which is only based on sources (you 
can decouple it from building). 

As said earlier, an incremental compilation might show the same limitation, if 
the secondary type hasn't been fed to the compiler upfront (javac behaves in 
the same way).
Comment 7 Philipe Mulet CLA 2002-06-06 04:36:32 EDT
Won't fix