| Summary: | [1.7] Missing type arguments (diamond) of variable declaration prevent variable binding recovery | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | Olivier_Thomann, raksha.vasisht, srikanth_sankaran, stephan.herrmann |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
I'll take a look. Experimenting with the following program, I see the 3.7 compiler's
repair attempts rather misguided/feeble here:
import java.util.ArrayList;
import java.util.List;
public class DiamondErr1 {
List<? extends Number> m() {
ArrayList<> var = new ArrayList<>();
XYZ<> var2 = new XYZ<>();
return var;
}
}
class XYZ<T, U, V> {
}
XYZ<> is repaired to be XYZ<?> which results in the messages around
incorrect arity - which could in fact confuse a user more since
the messages is "Incorrect number of arguments for type XYZ<T,U,V>;
it cannot be parameterized with arguments <?>" - something that does
not correspond to source at all.
Nor does the "Cannot instantiate the type ArrayList<?>" message.
So, from a purely user-visible messages pov, BETA_JAVA7 seems to
do a better job.
Markus, what UI features/capabilities get affected by this ?
Olivier, what would you expect from the compiler AST & bindings ?
The most visible affected UI feature is Mark Occurrences: The connection between the declaration and the reference to "var" is lost. This also means that the Local Rename quick assist doesn't work any more.
I agree that the recovery in 3.7 was also not great, but at least the local variables got proper bindings in the simple case. With multiple type parameters, this also failed in 3.7, e.g. here:
List<? extends Number> m2() {
XYZ<> var2 = new XYZ<>();
return var2;
}
Secondary problems are e.g. that Extract Method on
ArrayList<> var = new ArrayList<>();
does not find anything to return, but that's minor and can be accepted in code that contains syntax errors.
Bindings-wise, I would not expect to get ITypeBindings that return true for isGenericType() here. Such bindings should only show up for a type declaration. In 3.7, I also get a genericType for "XYZ<>", but in BETA_JAVA7, I even get it on ArrayList. Ideally, the recovered binding for XYZ<> would be the parameterizedType XYZ<> or XYZ<?, ?, ?>.
Srikanth, please try to see if you can accommodate Markus with what he reported in comment 3. I am not sure we can do a lot better for the binding recovery. Unfortunately, I don't expect to get to this in 3.7.1 timeframe. Retargetting to 3.8. Don't expect to get to this anytime soon. Will consider for next release. 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. |
BETA_JAVA7 The class below tries to use a diamond in a variable declaration (or just misses the type arguments). In I20110603-0909, this didn't stop the compiler from recovering a variable binding for the SimpleName 'var' (with type ArrayList<?>). In BETA_JAVA7, only the VariableDeclarationFragment gets a binding, but the SimpleNames don't. Furthermore, the type is now a recovered type 'diamond.ArrayList'. The old inferred type was better. This is broken for both 1.5 and 1.7 compliance. package diamond; import java.util.ArrayList; import java.util.List; public class DiamondErr1 { List<? extends Number> m() { ArrayList<> var = new ArrayList<>(); return var; } }