| Summary: | [1.5][compiler] NPE in computeCompatibleMethod | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ed Willink <ed> | ||||
| Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | darin.eclipse, john.arthorne, kent_johnson, martinae, Mike_Wilson, thanson | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.2 RC5 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Ed Willink
Could you please try with 3.2 RC4 ? This would indicate a method with null return type:
protected final MethodBinding computeCompatibleMethod(MethodBinding method, TypeBinding[] arguments, InvocationSite invocationSite) {
TypeBinding[] genericTypeArguments = invocationSite.genericTypeArguments();
TypeBinding[] parameters = method.parameters;
TypeVariableBinding[] typeVariables = method.typeVariables;
if (parameters == arguments
>>>>>>>> && (method.returnType.tagBits & TagBits.HasTypeVariable) == 0
Please provide steps to reproduce, then reopen. Reproduced using RC4. A workspace that reproduces the bug may be found at /download.eclipse.org/technology/gmt/umlx/temp/UMLX.Workspace3.2RC4.zip it uses Windows XP SP2 latest updates Java 1.5.0_06 EMF 2.2.0RC2a GEF 3.2RC2a EMFT 1.0RC2 (at most ocl needed) Load workspace and let auto-build fail. Reproduced issue at: NodeElementGraphicalNodeEditPolicy.java Took the workspace Imported draw2d and gef plugins Auto recompilation found it. Looks bad. We are trying to tiebreak between a method and a problem method... (ambiguous) Problem occurs at msg send: linkEditPart.getViewer() where receiver type is: GLinkElementView<capture-of ?,capture-of ?> Problems come from interface lookups, which aren't checking that the found method is a valid one, before attempting to tiebreak. There are 3 instances of this issue. Given this is a regression introduced in RC2, and it was found in about 2 weeks; I would be enclined to address it into RC5. The fix is simple enough, simply an omission when rewriting #findMethod(...), and doesn't change the logic. I will attach a patch, and ask Kent to review it, since he owns this code. +1 for 3.2RC5 Tim - pls cast your vote for addressing it in 3.2RC5 Kent - pls review the patch Martin - pls vote Created attachment 41871 [details]
Proposed patch
Patch adding 'method.isValidBinding()' in 3 places, where interface methods are being considered for merging.
Testcase inferred from provided workspace:
public class X {
void bar(GLinkElementView<?,?> g) {
g.getViewer();
}
}
abstract class GLinkElementView<M,CM> extends AbstractLinkView<M> {}
abstract class AbstractLinkView<M> extends AbstractConnectionEditPart implements ILinkViewElement, IModelChangeListener {
@Override
public SheetViewer getViewer() { return null; }
}
abstract class AbstractConnectionEditPart extends AbstractGraphicalEditPart implements ConnectionEditPart {}
abstract class AbstractGraphicalEditPart extends AbstractEditPart implements GraphicalEditPart {}
abstract class AbstractEditPart implements EditPart/*, RequestConstants*/ {
public EditPartViewer getViewer() { return null; }
}
interface ILinkViewElement extends INodeViewElement {
public ISheetViewer getViewer();
}
class SheetViewer implements ISheetViewer {}
interface ISheetViewer {}
interface EditPart {
EditPartViewer getViewer();
}
interface ConnectionEditPart extends GraphicalEditPart {}
interface GraphicalEditPart extends EditPart {}
interface EditPartViewer {}
interface IModelChangeListener {}
interface INodeViewElement {
public ISheetViewer getViewer();
}
Added GenericTypeTest#test0987&0988 + LookupTest#test072 Patch looks good. Mike - pls vote for this one. +1 Darin - will you vote for this one ? +1, regression should be addressed John - pls cast your vote +1 Excellent, got enough votes now. Released for 3.2RC5 Verified with I20060519-0010 for 3.2RC5 |