Summary: | [1.5] Wrong method binding | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | David Audel <david_audel> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | frederic_fusier |
Version: | 3.0 | ||
Target Milestone: | 3.1 M4 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
David Audel
2004-11-29 11:25:55 EST
Another strange binding. public class Test { public <U> Test(U u) { } void bar() { new <String>Test(null){}; } } The binding of "new <String>Test(null){}" is a MethodBinding instead of ParameterizedGenericMethodBinding Problem comes from the fact we picked an exact match. First scenario comes from the fact that Scope#computeCompatibleMethod was incorrectly optimizing out the scenario where signature thought it had no mention of generics (though it still had type variables to substitute). Note that this problem had no incidence on compiler functionning as the signature did not contain any invalid information. Other scenario works fine with correction, also checked: public class X { public <U> X(Object o) { } void bar() { new X(null){}; } } Fixed. David - pls add regression tests using selections to expose binding natures. tests ResolveTest1_5#test0058() and and test0060 updated. Comment 1 doesn't use a ParameterizedGenericMethodBinding. It is still using a MethodBinding. I double checked that the offending binding in comment#1 is truly a ParameterizedGenericMethodBinding. Frederic - pls double check Create test cases comment 0, comment 1 and comment 5 in self-hosting workspace and use debugger in resolveType() method of MessageSend (comment 0) and QualifiedAllocationExpression (comment 1 and comment 5). I confirm that inheritedBinding is now well computed with this bug fix (ie. it is a ParameterizedGenericMethodBiding for all these test cases). Verified for 3.1 M4 using build I200412142000. Note however, that even if inheritedBinding is well computed with this bug fix, for comment 5 test case, it is not persisted in constructorCall.binding of ConstructorDeclaration in anonymousType.methods array... I'll open a new separated bug for this issue. |