Community
Participate
Working Groups
IProblem#UndefinedType is currently reused for completely different problem cases: class A { private string string; public void m1() { String temp= string; } public void m2() { string= "Hello World"; } public String m3() { return string; // quick fix here } } In the first occurrence, it's for an undefined type (good). In the other cases it's for a variable whose type is undefined. The two situations should use different problem ids. For methods, a similar situation already produces IProblem.MissingTypeInMethod: public string m4() { return m4(); } For fields, I'd expect a new IProblem.MissingTypeInField.
Makes sense. We should introduce a new message "The field {1} from the type {1} refers to the missing type {2}"
Aren't we forgetting the local variable case? Or is that covered somewhere?
(In reply to comment #2) > Aren't we forgetting the local variable case? Or is that covered somewhere? Thats covered. We only complain for local variable once at declaration site. (SingleNameReference line 962)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
